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

V>>Мы говорим о ситуации в современом IT.
S>Ой, это такая размытая штука, эта ваша "ситуация в современном IT".

Железо, на котором крутится rsdn — вполне себе "современная ситуация".
Причём, менстримовая (плюс-минус не так далеко).


V>>Я это не предполагал.
V>>Я предлагал посмотреть на ходовые сценарии и что в них не так.
S>В них много чего не так. Например, хреновая отказоустойчивость некластерных решений.

Гы. Кластера бывают разные.
Там как раз прямое отображение на соотв. уровни raid — т.е. как дублирование данных, так и распараллеливание нагрузки.
Плюс еще комбинации того и другого.

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


S>>>На ноуте и SQLite будет показывать отличные результаты.
V>>Не будет.
S>Будет.

В сравнении с MySQL — нет.


S>У нас, есличо, один проект внезапно вырос со 100 "строк" до 300K "строк" (а это, для нашего продукта, уже объёмы, которые создают телекомы мирового уровня, с десятками миллионов долларов месячного оборота в рамках этого конкретного продукта), оставаясь на SQLite. В котором, к слову, почти все таблицы были устроены как (int id, varchar(max) jsonData).
S>От этой реализации отошли по причинам, не связанным с производительностью

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

Еще неплохой результат показывал MS SQL CE, если нарисовать ему ручками свой шедуллер/pipeline, вместо штатных ср-в и без всяких .Net.

Но! Проекты MySQL и SQLite интересны тем, что показывают — СУБД можно разрабатывать даже "на коленке".
Первые их версии были убоги по меркам современных Oracle/MS SQL/DB2, но были мощнее, скажем, версии Oracle 5.

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

А уже сегодня MySQL поспорит с версий (не побоюсь этого слова) Oracle 7. При этом все "кишки" наружу, все либы есть. Можно использовать классически SQL (фронтенд) через отдельный сервис, либо в виде встраиваемой СУБД, но так же во втором случае можно непосредствено оперировать таблицами, т.е. "дергать" за бэкенд напрямую.
Понимаешь, к чему я клоню? ))


V>>Зависит от сценариев.
V>>Когда надо в основном только отдавать данные, то MySQL на современной технике практически вне конкуренции.
S>Когда надо "только отдавать", да ещё и при select * from mytable where id = ?, справится вообще кто угодно.

Уже при двух join начинается разница.

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


S>>>А пока что речь идёт о том, как бы он круто выиграл забег, если бы ему дали.
V>>Дык, он и выиграл давным давно.
V>>Чуть менее чем весь современный веб опирается на MySql в бэкенде.
S>Это передёргивание. Чуть менее чем весь современный веб опирается на Apache и PHP. Что не мешает быть говном и тому и другому.

ngix, скорее.
И да, PHP для своего времени был прекрасен.
Ведь это именно в рамках PHP индустрией был отлажен подход к шаблонизации HTML-страниц, который практически без изменения пошел в JSP и ASP, с точностью до меток начала/конца кода шаблона.

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

Помимо шаблонизатора, как сам скриптовый язык PHP тоже весьма неплох, особенно с 5-й версии.
По крайней мере рядом с его тогдашним самым популярным современником — Перлом.

Похоже, ты не понимаешь, за что ругают PHP.
Его ругают за децентрализованность.
За то, что его слабо связанные с друг другом библиотеки и фреймворки, сваленные в кучу, превратились в натуральную помойку.
За то, что он задал тот самый "низкий порог вхождения" одним из первых в отрасли, со всеми полагающимися светошумовыми эффектами.
Это был совершенно новый для индустрии опыт. ))

Т.е. PHP помойка не из-за св-в языка (он весьма неплох, повторюсь), а потому что такая сложилась вокруг него культура.
Что-то типа как вокруг современного JS — тоже та еще складывается помоечка.

============

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

V>>Мы говорим о ситуации в современом IT.
S>Ой, это такая размытая штука, эта ваша "ситуация в современном IT".

Железо, на котором крутится rsdn — вполне себе "современная ситуация".
Причём, мейнстримовая (плюс-минус не так далеко).


V>>Я это не предполагал.
V>>Я предлагал посмотреть на ходовые сценарии и что в них не так.
S>В них много чего не так. Например, хреновая отказоустойчивость некластерных решений.

Гы. Кластера бывают разные.
Там как раз прямое отображение на соотв. уровни raid — т.е. как дублирование данных, так и распараллеливание нагрузки.
Плюс еще комбинации того и другого.

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


S>>>На ноуте и SQLite будет показывать отличные результаты.
V>>Не будет.
S>Будет.

В сравнении с MySQL — нет.


S>У нас, есличо, один проект внезапно вырос со 100 "строк" до 300K "строк" (а это, для нашего продукта, уже объёмы, которые создают телекомы мирового уровня, с десятками миллионов долларов месячного оборота в рамках этого конкретного продукта), оставаясь на SQLite. В котором, к слову, почти все таблицы были устроены как (int id, varchar(max) jsonData).
S>От этой реализации отошли по причинам, не связанным с производительностью

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

Еще неплохой результат показывал MS SQL CE, если нарисовать ему ручками свой шедуллер/pipeline, вместо штатных ср-в и без всяких .Net.

Но! Проекты MySQL и SQLite интересны тем, что показывают — СУБД можно разрабатывать даже "на коленке".
Первые их версии были убоги по меркам современных Oracle/MS SQL/DB2, но были мощнее, скажем, версии Oracle 5.

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

А уже сегодня MySQL поспорит с версий (не побоюсь этого слова) Oracle 7. При этом все "кишки" наружу, все либы есть. Можно использовать классически SQL (фронтенд) через отдельный сервис, либо в виде встраиваемой СУБД, но так же во втором случае можно непосредствено оперировать таблицами, т.е. "дергать" за бэкенд напрямую.
Понимаешь, к чему я клоню? ))


V>>Зависит от сценариев.
V>>Когда надо в основном только отдавать данные, то MySQL на современной технике практически вне конкуренции.
S>Когда надо "только отдавать", да ещё и при select * from mytable where id = ?, справится вообще кто угодно.

Уже при двух join начинается разница.

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


S>>>А пока что речь идёт о том, как бы он круто выиграл забег, если бы ему дали.
V>>Дык, он и выиграл давным давно.
V>>Чуть менее чем весь современный веб опирается на MySql в бэкенде.
S>Это передёргивание. Чуть менее чем весь современный веб опирается на Apache и PHP. Что не мешает быть говном и тому и другому.

ngix, скорее.
И да, PHP для своего времени был прекрасен.
Ведь это именно в рамках PHP индустрией был отлажен подход к шаблонизации HTML-страниц, который практически без изменения пошел в JSP и ASP, с точностью до меток начала/конца кода шаблона.

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

Помимо шаблонизатора, как сам скриптовый язык PHP тоже весьма неплох, особенно с 5-й версии.
По крайней мере рядом с его тогдашним самым популярным современником — Перлом.

Похоже, ты не понимаешь, за что ругают PHP.
Его ругают за децентрализованность.
За то, что его слабо связанные с друг другом библиотеки и фреймворки, сваленные в кучу, превратились в натуральную помойку.
За то, что он задал тот самый "низкий порог вхождения" одним из первых в отрасли, со всеми полагающимися светошумовыми эффектами.
Это был совершенно новый для индустрии опыт. ))

Т.е. PHP помойка не из-за св-в языка (он весьма неплох, повторюсь), а потому что такая сложилась вокруг него культура.
Что-то типа как вокруг современного JS — тоже та еще складывается помоечка.

============