Здравствуйте, vdimas, Вы писали:

V>Железо, на котором крутится rsdn — вполне себе "современная ситуация".
V>Причём, мейнстримовая (плюс-минус не так далеко).
Эммм, WhatsApp, ngs.ru, и какой-нибудь likefish.ru тоже являются современной ситуацией.
Причём первых — единицы, вторых — сотни, а третьих — легион.
Рассматривать железо без нагрузки — бессмысленно. А нагрузка у нас в диапазоне от 10^2 до 10^7 пользователей в сутки.

V>Гы. Кластера бывают разные.
С т.з. RDBMS — примерно одинаковые.
V>Обсуждаемые цифры поверх Sun-кластера случились не от дублирования, а от распараллеливания, но ты сейчас напираешь на дублирование.
V>Считай, что был пойман на спекуляции.
Дублирование без распараллеливания и не получится.

V>В сравнении с MySQL — нет.
Спорно.

V>Ну, SQLite может показывать чуть лучшие результаты только за счёт того, что это встраиваемая база.
А также за счёт того, что он принудительно single-user. Что позволяет очень сильно упростить шедулинг транзакций.
V>Еще неплохой результат показывал MS SQL CE, если нарисовать ему ручками свой шедуллер/pipeline, вместо штатных ср-в и без всяких .Net.
Очень может быть. Речь идёт о том, что в таких вырожденных сценариях любые "compact", "express", "light", и "local" версии летают на ура.
Взрослая RDBMS обязана уметь вылезать за пределы коробки, и поддерживать несколько более широкий класс сценариев.

V>Понимаешь, к чему я клоню? ))
Нет пока.

V>Уже при двух join начинается разница.
Ну, в принципе — да. Но надо понимать, что современный ноут — это 16GB памяти, что позволяет достигать 100% cache hit ratio для большинства read-only приложений. Поэтому разница в планах запросов внезапно начинает играть значительно меньшую роль, чем для сценария классической RDBMS, когда данные таки надо доставать с диска.

V>Но так-то да, MySQL так же показывает определённую философию и образ мышления, а именно — сценарии работы с даными бывают РАЗНЫМИ.
MySQL показывает философию "функциональность важнее производительности". MS SQL проектировался как классический корпоративный продукт со стратегическими целями. То есть, к примеру, фича про "исполнение .net кода" — это сразу приоритет 0, и пофиг на стоимость, а фича "хранить json в таблице" идёт где-то в конце списка с пометкой "а это ещё нахрена?".

V>Т.е., серебрянной пули нет. Под разные сценарии хороши разные алгоритмы и разные стратегии хранения информации. MySQL изначально затачивался именно на быструю выборку данных и в этой дисциплине рвёт всех. Поэтому, практически весь современный веб на нем и крутится.
Нет. MySQL затачивался под то, чтобы быть удобным для использования. Затачивание на быструю выборку означало бы развитый оптимизатор — а по факту его допиливали задним числом. Оно означало бы забивание на фичи по модификации — а по факту мы имеем и replace statement, и безтранзакционный движок, и ещё много чего.
Современный веб крутится на нём ровно потому, что MySQL в течение многих лет был единственной бесплатной опцией.

V>ngix, скорее.
Неа. Nginx, конечно же, используется. https://trends.builtwith.com/web-server
Почти так же часто, как Apache. Но надо же понимать, что эти 28% — это фронт-енд, т.е. позади этих nginx по-прежнему стоят apache.
V>Ведь это именно в рамках PHP индустрией был отлажен подход к шаблонизации HTML-страниц, который практически без изменения пошел в JSP и ASP, с точностью до меток начала/конца кода шаблона.
Вообще-то, PHP, JSP, и ASP — это три (ну, ладно, два) разных подхода к шаблонизации HTML-страниц.
При этом синтаксически JSP и ASP гораздо ближе друг к другу, чем к PHP.
Но давайте не будем углубляться в детали этой истории.

V>К тому же, движков PHP существует несколько, в том числе компиллируемых, которые рвут как тузик грелку JSP и ASP.Net.
Отож. Всегда можно найти сценарий, на котором выиграет выбранный движок.

V>В том числе этому способствует гладкая стыковка с нейтивными модулями, писанными, скажем, на С/С++.
V>К тому этому способствует специфика управления памятью — во многих "акселераторах" память убирается только после выполнения запроса или серии их, что идеально ложится на специфику веба. Дотнетный же GC, увы, может начать работу в самый неподходящий момент. ))
Серверный — нет.

V>Похоже, ты не понимаешь, за что ругают PHP.
Во-первых, неважно, за что его ругают. Речь идёт о том, что PHP — это очевидно хреновый выбор для написания веб-приложений.
Какой критерий ни возьми — всегда найдётся кто-то лучше. Особенно это очевидно, если посмотреть в перспективе — нам же надо сравнивать не современный PHP с современным JSP, а, скажем, PHP образца 2000 года с JSP образца 2000 года.
Там вообще всё очевидно — и тем не менее, "народ" проголосовал за PHP.

V>Его ругают за децентрализованность.
В основном его ругают за противоречивость. Семьдесят семь способов сделать любую фигню, и сотни директив конфигурации, которые меняют смысл твоего кода на противоположный.
Именно из-за этого страницы, которые работали годами, внезапно начинают сыпаться, как шифер с крыши под ураганом.
Повторюсь: неважно, какие конкретно претензии к PHP. Важно, что по статистике использования качество продукта оценивать нельзя. Поэтому я предлагаю а) прекратить обсуждение истории и достоинств PHP (а заодно и Apache) и б) прекратить приводить статистические аргументы.