Проблема со статьей, на которую вы ссылаетесь, состоит в том, что автор явно не знает, о чем говорит, когда спрашивает, где находится «узкое место»; тот факт, что кто-то имеет больше веб-серверов, чем серверов баз данных, не означает, что «база данных не может быть там, где проблема». То, что обычно подразумевается под «базой данных, является узким местом», - это то же самое, чему научились все, кто когда-либо выполнял профилирование во время выполнения веб-приложения.
Рассмотрим приложение, для возврата полного ответа которого требуется полсекунды. Предположим, вы сели и профилировали его, и обнаружили, что эта половина секунды времени обработки разбивается следующим образом:
- Разбор входящего запроса: 50мс
- Запрос к базе данных: 350 мс
- Отображение HTML для ответа: 50 мс
- Отправка ответа обратно: 50 мс
Если бы вы увидели подобный сбой, когда запросы к базе данных составляют 70% фактического времени работы приложения, вы бы правильно пришли к выводу, что база данных является узким местом. И это именно то, что большинство людей обнаруживают, когда они делают профилируют свои приложения (и, как правило, база данных настолько полностью доминирует во времени обработки, что выбор языка для остальной обработки никому не имеет значения) заметит).
Оказалось, что количество задействованных серверов баз данных не имеет большого значения; известная цитата состоит в том, что такие люди, как автор поста, который вы связали, - это люди, которые слышат, что одной женщине требуется девять месяцев, чтобы родить ребенка, и предполагают, что девять женщин, работающих вместе, могут сделать это за один месяц. С точки зрения базы данных: если выполнение данного запроса занимает 100 мс для данной БД, то добавление большего количества серверов БД не позволит любому из них выполнить этот запрос быстрее. Причина добавления большего количества серверов баз данных заключается в возможности обрабатывать больше одновременных запросов и предотвращать перегрузку вашей БД, а не заставлять отдельные запросы выполняться быстрее.
И оттуда вы попадаете в обычный танец масштабирования приложения: кэширование для сокращения общего времени, затрачиваемого на получение данных или представление ответов, балансировка нагрузки для увеличения количества одновременных запросов, которые вы можете обслуживать, сегментирование и более сложные схемы проектирования баз данных, чтобы не перегружаться под нагрузкой и т. д. и т. д.
Но, вы заметите, ничего из этого не имеет ничего общего с используемым языком программирования, потому что, опять же, количество времени, потраченного или сэкономленного другими факторами, значительно превышает количество времени, полученное или потерянное «быстрый» или «медленный» язык (и, конечно, на самом деле такой вещи нет; от проблемной области и умений программиста зависит так много всего, что вы просто не можете иметь значимого общего сравнения).
Во всяком случае, это становится довольно длинным и бессвязным, поэтому я просто заверну это общим руководством: если вы видите, что кто-то утверждает, что «вы должны встроить язык X, потому что он работает быстрее», это мертвая распродажа. что они действительно ничего не знают о реальной производительности или масштабировании. Потому что, в конце концов, если бы это просто сводилось к «писать на самом быстром языке», они бы рекомендовали всем нам использовать ассемблер:)