Melkij

0. Определите свои затраты на создание веб-сервиса. Если затрудняетесь, сформулируйте для себя сколько вы хотите на своём сервисе заработать. Обозначим как C.
1. Определитесь, за какое время вы хотите вернуть свои затраты (или заработать) на создание веб-сервиса — T.
2. Самое сложное — прикиньте примерно динамику (функцию) спроса на ваш веб-сервис с течением времени. Обозначим как D(t), где t — время, скажем, в днях. Или хотя бы сформулируйте в виде «не менее 100 тыс. запросов в год».
3. Цена может быть посчитана при помощи следующей формулы:
P = C / (Cумма D(t) от 0 до T)
Плюс можно накинуть маржу 10-20%, на своё усмотрение.
Ещё можно учесть инфляцию.

Hint №1: Расчёты проще всего делать в Экселе.
Hint №2: Поищите информацию на тему cash flow, NPV, приняв за доход платежи за пользование своим сервисом.

Я бы советовал всетаки остаться на убунту, и не потому что он лучше, а просто он очень распространен, на любой его глюк есть 100500 ответов как его исправить, почти все мануалы по настройке любого бреда в первую очередь приводятся для убунты (читай дебиан совместимых дистрибутивов), 60% (если не 80%) ссылок с ответами на всякие вопросы «как в линуксе сделать эту хрень» в основном ссылаются на убунту. В нем проще будет найти решение проблемы незнающему человеку. А потом, когда уже кое как будешь сам справляться с глюками и с головой уйдешь в мир линукса, вполне сможешь выбрать себе другой дистрибутив «по душе», потому как начитаешься про них дофига и больше. Лично я выбрал дебиан, но у него есть один недостаток (как и преимущество) они очень щепетильно тестируют все пакеты, и в итоге он очень стабильный, но пока они тестируют эти пакеты, выходят другие, и почти все в нем немного отстает от последних версий.

Вы всего лишь запустили HTTP сервер на порту, предназначенном для HTTPS. HTTPS сервера в составе 5.4 не анонсировано.

Никак. Встроенный сервер не поддерживает SSL. Да и зачем он серверу, преднозначенному для разработки, а не для продакшена?

Что в итоге отработает быстрее и будет ли это в разы быстрее.
На мой взгляд ни одна теоретическая выкладка не сможет для вашей индивидуальной задачи сказать, что лучше. Только запуск и тестирование покажет правду…

Тут сложно сказать однозначно, есть разные взаимокомпенсирующие эффекты.
С одной стороны, можно избавиться от ненужного больше поля с флагом — это плюс, с другой — придется добавить индекс по полю с таймстампом, которое занимает уже не один байт, как предыдущее — это минус (индекс будет большое занимать памяти). Сами индексы будут работать одинаково эффективно для указаной выборки.

Я бы на Вашем месте создал бы тестовую табличку и сделал бы бенчмарк, заодно по результатам можно и статью на хабр отписать, многим было бы интересно.

Также нетривиален вопрос выбора движка хранения, у innodb будет очень заметным оверхед по месту для хидеров строк, если структура таблицы очень простая и размер строки небольшой.

Надо тестить, в общем…

Индекс по полю с двумя значениями неэффективен изначально.

NOSQL БД не становятся популярными, а занимают свою нишу.

NOSQL никогда не заменит реляционные SQL. Есть направления, в которых NOSQL эффективны, и есть другие направления, в которых SQL эффективна. Сейчас идёт процесс перераспределения сфер применения этих решений.

А почему они становятся популярными: они PRят себя (NoSQL компании как CouchBase, MemDB и т.п.), устраивают мероприятия (каждую неделю в Santa Clara какая-нибудь NoSQL конференция), но по-моему, немного «раздувают». И сейчас, как я вижу, это уже стало небольшим трендом. Но интересно, что до последнего момента Oracle очень консервативно не поддерживал NOSQL(прям как Microsoft с HTML5), а буквально полгода назад они обьявили на конференции в Сан Франциско(open world), что за NoSQL будущее.

По-моему, очень правильно. Чистый С очень близок к аппаратуре процессора, и изучение этого языка поможет правильно поставить мозги программиста, если он хочет разрабатывать высокопроизводительные программы, использующие все ресурсы компа. Кроме того, программирование на Objective C без знания С невозможно, кроме случаев простых приложений, которые можно и на HTML сгавнять.

Честно говоря, ваш пост действительно больше подходит для «Я пиарюсь», думаю, не стоит переносить обратно

В общем случае, принципы построения индексов достаточно просты: индекс (кроме первичного) строится для ускорения запросов. Причем если есть WHERE по двум полям, то будет взят индекс, содержащий оба этих поля (если есть) и не важно сколько их там еще.

Другими словами, один индекс по полям «A, B, C» будет более «полезен» для запроса, содержащего некие условия по полям A и B, чем два отдельных индекса по полям «A» и «B».

Фактически, индексы A,B,C и A,C,D будут одинаковы в части поиска по полю «А». При поиске по полям А,B будет взят первый индекс. При поиске по полям A, C — второй.

В своей работе лично я стараюсь не плодить излишних индексов. Ведь если запросы по полям В, С будут выполняться крайне редко, а сама таблица будет модифицироваться достаточно активно — то построение еще одного индекса принесет приложению больше вреда, чем пользы.

Не бойтесь добавлять слово EXPLAN в тело запроса и смотрите какие индексы он использует. Порой оптимизатор использует fullscan даже при наличии индексов.

а где поставить галочку «для всех следующих 100500 операций»?

Что посоветовать-то? Поставить на все компы бубунту и из репов дотянуть «компоненты денвера»?

У вас там в «Политехе» все такие «Инженеры-программисты»? Какой курс?

Очевидно потому, что пароли были переданы не в post body, а в качестве uri-аргументов.

Браузерами нет, другими клиентами — почему бы и вполне. Как минимум nginx раньше при proxy_pass обращался к бэкэнду по http 1.0.

Если не ошибаюсь, они версии полностью обратно совместимы, т.е. если вы реализовываете правильную работу с http 1.1, то и с http 1.0 все должно работать.

«консервирование» вашего ПК сохранит все его комплектующие в рабочем состоянии на многие года.
Для этого рекомендую обернуть его в герметичную упаковку, при этом очень желательно в вакуумную упаковку, чтобы удалить лишнюю влагу. Поместить его в защищенное от солнечных лучей прохладное место. Во время хранения не подвергать сотрясению и ударам.