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

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

Тю, есть разные сценарии репликации, в том числе поддержванные на прикладном уровне.
Например, из одной "эталонной" базы получают целый парк клонов, куда раскидываются запросы только по чтению, не критичные к актуальности (коих может быть более 90% в средней бизнес-системе). ))


V>>Ну, SQLite может показывать чуть лучшие результаты только за счёт того, что это встраиваемая база.
S>А также за счёт того, что он принудительно single-user. Что позволяет очень сильно упростить шедулинг транзакций.

Э-э-э...
Он как бэ мульти-юзер с простейшей глобальной блокировкой. ))

Но, опять и снова, для read-only это не принципиально.


S>Взрослая RDBMS обязана уметь вылезать за пределы коробки, и поддерживать несколько более широкий класс сценариев.

Но серебрянной пули нет.
Поэтому, грамотный разработчик не просто рисует себе "черный ящик" БД, но планирует основные сценарии по ней, чтобы хотя бы примерно выйти на ожидаемую статистику характеров сценариев.

А способов повышать эффективность всей системы без увеличения стоимости железа на пару порядков — овердохрена.


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

Я там клонил к наличию в природе готовых движков БД в виде библиотечных версий, из которой доступен как SQL-интерфейс, так и низкоуровневый слой, выполняющий операции с таблицами.


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

Даже не знаю что ответить.
Сам же поставил проблематику, сам же ответил.
В реальности-то тоже чаще read-only.
И масштабирование в реальности и вовсе возможно тупое-горизонтальное.
Например, в банке банковские счета с такого-то по такой-то обслуживаются одним серваком, другой диапазон другим и т.д.
Аналогичный трюк работает насчёт позиций на складе — позиции-то де-факто независимые.
Т.е. достаточно клиентскому приложению уметь работать с такой специфической "архитектурой данных" и ву а ля.


V>>Но так-то да, MySQL так же показывает определённую философию и образ мышления, а именно — сценарии работы с даными бывают РАЗНЫМИ.
S>MySQL показывает философию "функциональность важнее производительности".

Не согласен. Я помню самые первые версии MySQL.
На выборку он работал даже еще быстрее, чем сейчас, но умел намного меньше.


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

Откуда ты это берёшь? ))
Удобным УЖЕ был Postgre, бо его SQL хоть как-то близок к стандартному, а в первых версиях MySQL возможности SQL были беднее, чем в современном ему MS Access (Jet DB). Там часто прходилось ломать голову — как же так переформулировать запрос, чтобы этот бедняга его "проглотил". ))


S>Затачивание на быструю выборку означало бы развитый оптимизатор — а по факту его допиливали задним числом.

По факту основной ключ сразу шёл кластерным и это волшебным образом решало кучу вопросов с производительностью, если была более-менее удачная схема хранения данных.

Я же говорю — наличие уже достаточных представлений о происходящем в БД позволило даже в наколенном варианте добиться вполне приемлимых результатов с первых же версий.


S>Современный веб крутится на нём ровно потому, что MySQL в течение многих лет был единственной бесплатной опцией.

Postgre тоже бесплатен и уже был весьма популярным.
Просто нагрузка в вебе даже не 99% на чтение, а 99.99%. ))
Ну вот всякие конструкторы сайтов, скажем, новостных.
Инфа добавляется на сайт крайне медленно, но читается крайне часто.


S>Почти так же часто, как Apache. Но надо же понимать, что эти 28% — это фронт-енд, т.е. позади этих nginx по-прежнему стоят apache.

nginx не требует никаких apache, хотя может с ним работать.



S>Речь идёт о том, что PHP — это очевидно хреновый выбор для написания веб-приложений.

На сейчас да.
А на тот момент и выбора-то не было.


S>Какой критерий ни возьми — всегда найдётся кто-то лучше. Особенно это очевидно, если посмотреть в перспективе — нам же надо сравнивать не современный PHP с современным JSP, а, скажем, PHP образца 2000 года с JSP образца 2000 года.

PHP рвал жабку как тузик грелку.
Тогда ведь JSP в основном на Tomcat крутилась, а это был тормоз из тормозов.
А всякие JBoss были еще тормознее.


S>Там вообще всё очевидно — и тем не менее, "народ" проголосовал за PHP.

Да не очевидно, если по честному.
PHP давал REPL, а нормальный отладчик под JSP был только у J-IDEA, причём вот только-только появился в конце 90-х и за деньги.
В других системах отладка JSP была сущим кошмаром (что в итоге IBM подарила Eclipse сообществу).
Наверно поэтому-то в начале 2000-х был популярен ColdFusion для жабки.
Он был типа как MS Access только для специфики серверного HTML/JS, т.е. "накидать код мышкой" было так же легко.


V>>Его ругают за децентрализованность.
S>В основном его ругают за противоречивость. Семьдесят семь способов сделать любую фигню

Это оно и есть.
Как и в современном JS — все эти бесконечные способы сделать одну элементарную весчь, но каждый способ обязательно модержит в себе какой-нить WTF.

Но индустрия на "этом" работает.

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

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

Тю, есть разные сценарии репликации, в том числе поддержванные на прикладном уровне.
Например, из одной "эталонной" базы получают целый парк клонов, куда раскидываются запросы только по чтению, не критичные к актуальности (коих может быть более 90% в средней бизнес-системе). ))


V>>Ну, SQLite может показывать чуть лучшие результаты только за счёт того, что это встраиваемая база.
S>А также за счёт того, что он принудительно single-user. Что позволяет очень сильно упростить шедулинг транзакций.

Э-э-э...
Он как бэ мульти-юзер с простейшей глобальной блокировкой. ))

Но, опять и снова, для read-only это не принципиально.


S>Взрослая RDBMS обязана уметь вылезать за пределы коробки, и поддерживать несколько более широкий класс сценариев.

Но серебрянной пули нет.
Поэтому, грамотный разработчик не просто рисует себе "черный ящик" БД, но планирует основные сценарии по ней, чтобы хотя бы примерно выйти на ожидаемую статистику характеров сценариев.

А способов повышать эффективность всей системы без увеличения стоимости железа на пару порядков — овердохрена.


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

Я там клонил к наличию в природе готовых движков БД в виде библиотечных версий, из которой доступен как SQL-интерфейс, так и низкоуровневый слой, выполняющий операции с таблицами.


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

Даже не знаю что ответить.
Сам же поставил проблематику, сам же ответил.
В реальности-то тоже чаще read-only.
И масштабирование в реальности и вовсе возможно тупое-горизонтальное.
Например, в банке банковские счета с такого-то по такой-то обслуживаются одним серваком, другой диапазон другим и т.д.
Аналогичный трюк работает насчёт позиций на складе — позиции-то де-факто независимые.
Т.е. достаточно клиентскому приложению уметь работать с такой специфической "архитектурой данных" и ву а ля.


V>>Но так-то да, MySQL так же показывает определённую философию и образ мышления, а именно — сценарии работы с даными бывают РАЗНЫМИ.
S>MySQL показывает философию "функциональность важнее производительности".

Не согласен. Я помню самые первые версии MySQL.
На выборку он работал даже еще быстрее, чем сейчас, но умел намного меньше.


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

Откуда ты это берёшь? ))
Удобным УЖЕ был Postgre, бо его SQL хоть как-то близок к стандартному, а в первых версиях MySQL возможности SQL были беднее, чем в современном ему MS Access (Jet DB). Там часто прходилось ломать голову — как же так переформулировать запрос, чтобы этот бедняга его "проглотил". ))


S>Затачивание на быструю выборку означало бы развитый оптимизатор — а по факту его допиливали задним числом.

По факту основной ключ сразу шёл кластерным и это волшебным образом решало кучу вопросов с производительностью, если была более-менее удачная схема хранения данных.

Я же говорю — наличие уже достаточных представлений о происходящем в БД позволило даже в наколенном варианте добиться вполне приемлимых результатов с первых же версий.


S>Современный веб крутится на нём ровно потому, что MySQL в течение многих лет был единственной бесплатной опцией.

Postgre тоже бесплатен и уже был весьма популярным.
Просто нагрузка в вебе даже не 99% на чтение, а 99.99%. ))
Ну вот всякие конструкторы сайтов, скажем, новостных.
Инфа добавляется на сайт крайне медленно, но читается крайне часто.


S>Почти так же часто, как Apache. Но надо же понимать, что эти 28% — это фронт-енд, т.е. позади этих nginx по-прежнему стоят apache.

nginx не требует никаких apache, хотя может с ним работать.



S>Речь идёт о том, что PHP — это очевидно хреновый выбор для написания веб-приложений.

На сейчас да.
А на тот момент и выбора-то не было.


S>Какой критерий ни возьми — всегда найдётся кто-то лучше. Особенно это очевидно, если посмотреть в перспективе — нам же надо сравнивать не современный PHP с современным JSP, а, скажем, PHP образца 2000 года с JSP образца 2000 года.

PHP рвал жабку как тузик грелку.
Тогда ведь JSP в основном на Tomcat крутилась, а это был тормоз из тормозов.
А всякие JBoss были еще тормознее.


S>Там вообще всё очевидно — и тем не менее, "народ" проголосовал за PHP.

Да не очевидно, если по честному.
PHP давал REPL, а нормальный отладчик под JSP был только у J-IDEA, причём вот только-только появился в конце 90-х и за деньги.
В других системах отладка JSP была сущим кошмаром (что в итоге IBM подарила Eclipse сообществу).
Наверно поэтому-то в начале 2000-х был популярен ColdFusion для жабки.
Он был типа как MS Access только для специфики серверного HTML/JS, т.е. "накидать код мышкой" было так же легко.


V>>Его ругают за децентрализованность.
S>В основном его ругают за противоречивость. Семьдесят семь способов сделать любую фигню

Это оно и есть.
Как и в современном JS — все эти бесконечные способы сделать одну элементарную весчь, но каждый способ обязательно содержит в себе какой-нить WTF.

Но индустрия на "этом" работает.