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

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

V>Это не современное IT.


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

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

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

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

V>На нескольких обычных, обслуживающих непересекающиеся рынки.
V>Потому что важен не только и не столько throughput, сколько latency.
V>А приличные цифры latency сегодня дают ни в коем случае не кластеры, а хорошо вылизанные "единичные" серваки.
Ух ты! И что, одно failure материнской платы положит NASDAQ на время замены этой "обычной машинки"?

V>На этом кластере при его чудовищной througput показана одна из самых плохих latency — порядка 0.1 сек.
V>Это только в мусорку по современным реалиям.
Приложений, где нужна латентность лучше, чем 100мс, единицы. Биржевая торговля — да, согласен, тут надо прямо мигом.
А где ещё? Обработка кредиток? Там и 1000мс всех устроит, и 3000мс.

V>Выжимать такты требуется всегда.
Да ну? Почему ж тогда у нас сайты все сплошь работают на тормозных PHP и Apache, а не на, скажем, хотя бы Java и lighttpd? И уж тем более не на nginx и C++?
На чём-то приемлемом написаны доли процента всего веба.

V>Теперь надо повернуться лицом к софту и научить его выжимать максимум из железок.
Хотелось бы надеяться. Но пока что типичный шаг по "оптимизации производительности" соверменного проекта — это перевод его докер-контейнера в dedicated server. Вот мы в 50 раз и ускорились.

V>Нет, это было до Linq.
Интересно посмотреть, о чём это идёт речь.

V>>>Современные оптимизаторы отслеживают не только типы, они отслеживают жизненный цикл данных, принимают решения по трансформации графа операций с данными и т.д.
S>>А статистику они откуда берут?

V>Статистику берут оттуда же.
Непонятно, что такое "оттуда же". В жизни не видел оптимизатора, который бы учитывал хотя бы среднюю длину строки, которую будут передавать в функцию strstr.

V>А откуда это известно в динамике? ))
V>В динамике нужно пройтись по всем таблицам, посмотреть у кого какие индексы, построить варианты.
А также посмотреть на гистограммы, и на разнообразные constraints.
Именно это делают реальные RDBMS. Пользуясь, собсно, тем, что у них есть описание запроса в виде AST, с логическими операциями в узлах.
При этом мы можем скомпилировать код сегодня, а работать он будет через год — с актуальными на тот момент данными.
И когда мы добавляем к таблице индекс, нам не нужно останавливать систему на несколько часов, чтобы компилятор перекомпилировал бинарник, на ходу перестраивая сотни тысяч планов.

V>Но наличие индексов у таблиц — это статическая информация, её не нужно обрабатывать в динамике.

V>Далее. У подавляющего большинства запросов совсем маленькое количество вариантов планов, которые останутся после анализа статической информации. Собсно, я уже повторяюсь — я предлагал генерить как наборы самих планов, так и оптимизированный код их оценки.
V>Сейчас оценка происходит крайне медленно, поэтому иногда принимается решение взять "достаточно хороший" план, а не лучший.
Практически всегда принимается именно такое решение.
V>Допустим, есть два варианта плана по запросу из 3-х таблиц. По одному плану идёт скан таблиц 1, 2, 3, по другому — 1, 3, 2. Нетрудно заметить, что уже в статике становится понятно, что одновременно с оценкой каждого плана уже можно сканировать таблицу 1.
У джойна трёх таблиц 6 вариантов порядка соединения. Умножить на два-три варианта алгоритма соединения (лишние отбрасываем). Умножить на количество потенциальных индексов, которые можно использовать.
Ну, то есть получаем два-три десятка вариантов. Как будет выглядеть "оптимизированный код их оценки"?

V>Далее. Само сканирование (маппинг полей — проекции, вычисляемые поля и выражения при join т.д.) — сегодня это сильно тормозная штука в общих затратах (ведь это классика интерпретирования), бо скорость чтения с современных SSD-массивов приблизилась к скорости чтения обычной RAM. Это раньше можно было спекулировать на "этих затрат не видно и под микроскопом в сравнении со стоимостью чтения с диска", а сегодня забудь об этом аргументе навсегда. ))
Чушь. Лучшие SSD всё ещё в десяток раз дороже памяти в терминах латентности и в сотню раз — в терминах bandwidth.
Нет, я не настаиваю на интерпретации, но выбор подходящего алгоритма, который минимизирует обращения к диску, всё ещё важнее оптимизации сканирования уже загруженной страницы.

V>Это слава богу, что уже есть и неплохие компиллируемые NoSQL и прочие альтернативы, которые показывают какие-то совершенно дикие результаты в сравнении с "обычными" СУБД. Мне сейчас психологически банально легче, бо когда совсем уж против ветра было — то удовольствие не из изысканных.
Это кто у нас неплохие NoSQL?
Я всё жду, когда придёт кто-то компилируемый, и обскачет лидеров TPC-C. Причём не обязательно пердолиться абсолютным tpmC c мегакластерами — покажите, как ваша уберплатформа уделывает MS SQL Express на обычном серваке на ксеоне.
На практике внезапно оказывается, что все эти хвалёные NoSQL применимы только для каких-то других задач, не тех, для которых проектировали RDBMS.
V>Но я могу подкидывать требования к такому языку.
V>Это уже инженерия.
Ну, так-то да. Мне вообще непонятно даже, с чего начинать — декларативно всё должно быть, или императивно?
То есть — есть ли у нас assignment или только definition?


S>>Опять же — как делать: по языку для каждого слоя, или один на всех?

V>Один с достаточной выразительностью.


S>>Основной язык слишком императивный.

V>РА декларативна по-сути.
V>Т.е., хотя задана эдакая императивность операций, но это как в ФП-языках — императивность там только на бумаге, а на деле компилятор может выбирать последовательность вычислений и вообще проводить нетривиальные преобразования.

V>Ну и, говорил уже, нужна и РА и РИ.
V>Собсно, в современном Linq именно так и есть.
V>Просто РА сугубо императивна и практически не оптимизируется.

S>>В современном мейнстриме мы имеем либо вавилон из JS+Java+SQL, когда каждую фичу должно делать три разработчика плюс два тестера плюс отдельный менеджер, чтобы следить, чтобы все края совпали, либо JS everywhere с феерически неэффектиывым бэкендом и базой данных.

V>Про JS я даже говорить не хочу, если честно.
V>В сравнении с JS обсуждаемый SQL — просто верх человеческой мысли. ))

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

V>От сервера до готовой к линковке транспортной либы для клиента. Причём, типа как из CORBA — бинд на кучу языков.

V>Блин, да я готов довольно много поставить на то, что в конце всех концов "оно" именно так и будет.
V>Там и выхода-то другого нет.


S>>Иначе — будь любезен, соответствуй общепринятым стандартам.

V>Стандарты — штука капризная.
V>Protobuf появился вопреки всем стандартам и стал бешенно популярным, помножив весь IDL на ноль и почти на ноль XML-сообщения.
V>Это тупая инженерная хрень.
V>Тупейшая.
V>Бо отвечает прямо на прямо поставленные инженерные вопросы.
V>Но так и должно.


S>>Я об таком в свободное время фоном думаю, но во-первых, уделяю мало времени, во-вторых, не уверен, что это всё ещё актуально.

V>Дело не в актуальности. Дело в некоей привычки воспринимать реальность как данную свыше.
V>В итоге, мы ежедневно закрываем глаза на кучу откровенных глупостей, делаем вид, что так и надо.
V>Но любой вдруг ставший популярным фреймворк или язык не возникал на ровном месте — сначала возникала идея. ))


S>>Грубо говоря, непонятно, нужны ли ещё людям те приложения, которые я себе воображаю.

V>Нужны.


S>>TPC-C вышел из моды потому, что уже лет 15 никто не пишет учётные системы.

V>Пишут конструкторы учётных систем. ))
V>А еще никто не разворачивает выч. мощности "сам", их теперь арендуют и почти всегда есть доступ к "достаточной" мощности.
V>Но так-то всё в силе, в любом случае.


S>>Нет хороших фреймворков и вообще понимания, что и как должно делаться. Глобально — потому, что люди, выделяющие финансирование, катастрофически некомпетентны. Им показывают прототипы из одной странички, за которыми стоит база из 5 строчек. Когда начинается нормальная нагрузка — то либо проект дохнет (если не успевает принести денег), либо под него нанимаются мега спецы, которые способны собрать кастом билд MySQL и прикрутить статическую оптимизацию к PHP. Людям такого уровня "библиотеки" и "фреймворки" вообще не нужны — они сами могут компилятор сварганить.

V>Сварганить компилятор не сложно, можно за несколько вечеров на коленке.
V>А вот оптимизатор — это на той самой грани прогресса современного IT.


S>>А начинающие выбирают инструменты, которые позволяют "через полчаса в продакшн", а не те, которые позволяют за день написать код, который после пилота смасштабируется в 10000 раз по объёму и нагрузке.

V>Да. Должны быть сами такие "автомастшабируемые" ср-ва.
V>А они (по опыту в других областях) получаются только при использовании высокоуровневых параметрических моделей.

V>Т.е. вот встречается в программе описание некоего хранилища, а к нему хинт — ожидается сотня записей. А к другой таблице другой хинт — ожидается сотня миллионов записей. И одни и те же (внешне) операции начинают выполняться резко по-разному. А параметрическая модель — она живет в самом компиляторе и (по-хорошему) неплохо бы уметь эти модели ему скармливать извне тоже (это всё еще к вопросу требований к языку и инфраструктуре вокруг него).

V>Ну и, один из самых популярных способов оптимизации в С++ сегодня — это оптимизация по показаниям профайлера.
V>Т.е. собрали, запустили профайлер. А затем пересобрали уже с показаниями профайлера.
V>Для БД это вообще идеальный сценарий, тогда и хинты ручками указыать не надо, они будут расставляться профайлером по-факту.
Да, я давно уже думаю о том, что все современные методики изоляции транзакций построены на концепции "интерактивной сессии". Когда сел Вася за консоль, написал "set transaction isolation level serializable; go; begin tran; go; select top 100 * from customer_orders order by createDate desc go", Enter. Потянулся, закурил, и сидит. Думает. А Оракл тем временем сегмент отката щёлк!щёлк!. Ну, или MS SQL там за сценой shared range lock держит, и все операторы при сохранении заказов видят "Please wait...".
Потому что хрен его знает, что там этот Вася дальше планирует, накурившись-то?
А ведь в реале мы можем точно знать, что там будет происходить. Клиент (ну, или миддл-тир) обязан всю транзакцию, как она есть, отправить серверу на исполнение. Нельзя на ходу "придумать" следующий стейтмент — все ходы заранее записаны.
Тогда и уровни изоляции будут не нужны — оптимизатор и так видит, будут ли там повторные чтения, или нет; или что вот у нас в строке 1 прочитались данные, в строке 5 использовались, и больше они нам не нужны — поэтому все shared lock на них можно уже отпускать, не дожидаясь конца транзакции.
По идее, вот такие штуки могут ещё на порядок поднять быстродействие OLTP в том же железе, при сохранении ACID гарантий.

V>ЧТД, "своего железа".
V>А не дикого кластера.
V>Отсюда и пляшем.
Ну, так это же community-проект, с нулевым бюджетом и нулевой прибылью. А в коммерческом софте так не бывает — он приносит прибыль, и можно планировать затраты.