Если вы разрабатываете веб-приложения для максимальной масштабируемости, то ваше узкое место в конечном итоге сводится к управлению согласованным изменяемым состоянием (то есть частям вашей базы данных, которые требуют некоторой формы транзакционной семантики)
Некоторые моменты, которые следует учитывать:
Статические данные или данные, не требующие синхронизации / транзакций, могут быть дешево скопированы на многих небольших товарных серверах.Ваши NoSQL-решения (CouchDB и т. Д.) Должны прекрасно справляться с этим в сочетании с любым из множества отличных решений для кэширования статических веб-данных.
Возможность локальной обработки ЦП (например, обработка отдельных веб-запросов)легко масштабировать по горизонтали, добавляя больше узлов веб-сервера.Скорость процессора вряд ли будет вашим узким местом в любом случае, учитывая современные скорости процессора - большинству веб-приложений действительно не требуется много ресурсов процессора.
Транзакционное обновление данных, однако, является очень сложной задачей.Прочтите о проблеме византийских генералов , если вы хотите узнать теоретическое объяснение, но в принципе невозможно надежно координировать транзакции в распределенной системе.Вы должны пойти на некоторые компромиссы, основанные на том, что вы цените больше всего (целостность данных, производительность, масштабируемость, отказоустойчивость, стоимость, задержка).
Операционные системы и т. Д. На самом деле не имеют большого значения - накладные расходы очень малы и не влияют на масштабируемость.Идите с тем, что у вас есть навыки и / или вы думаете, что вам будет проще всего управлять.Лично я использую Ubuntu на Amazon EC2 .
Учитывая вид приложений, которые вы просматриваете, я, вероятно, ошибаюсь в решениях NoSQL, поскольку это звучит эффективнообработка больших объемов важнее, чем наличие большого количества транзакционных данных.Вы всегда можете сохранить поле PostgreSQL для ограниченного подмножества данных, для которого требуется семантика транзакций (учетные записи пользователей? Основные справочные данные? Некоторое состояние рабочего процесса?)
Другой (более классический) подход заключается в получении типичного большого-Без базы данных (например, Oracle, DB2) и купить дорогой кластер высокопроизводительных машин баз данных.Затем получите множество дешевых реплицированных веб-серверов, выполняющих большую часть работы и получающих доступ к кластеру базы данных, когда это необходимо для выполнения транзакций.Это может работать очень хорошо до того момента, когда кластер базы данных начинает перегружаться, и в этот момент может стать дорогим узким местом для расширения ..... но, возможно, если вы получаете такую большую нагрузку, вы можете себе это позволить.,Я бы пошел по этому пути, если бы вы создавали, например, приложение для финансовых услуг.
Если вы только делаете прототип или ожидаете небольших загрузок, то вместо дорогостоящего кластера базы данных вы можете использовать единственную стандартную машину PostgreSQL.Это, пожалуй, самый простой / дешевый вариант настройки.И если вы сохраняете минимальный доступ к базе данных (много кеширования, тщательный дизайн запросов), это может занять довольно долгий путь.Просто знайте, что в конечном итоге это станет вашим узким местом, если вы продолжите расти.
ps, о котором вы упоминали, что смотрите на Clojure, если вы еще этого не сделали, тогда я настоятельно рекомендую посмотреть это видео: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey - очень уникальный взгляд на параллелизм, который также дает некоторое представление о проблемах управления транзакционными данными в параллельных средах.