Какие у них преимущества? Есть ли у них будущее?

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

M>Какие у них преимущества? Есть ли у них будущее?
Преимуществ перед РСУБД нет. Будущего тоже нет.

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

M>Какие у них преимущества? Есть ли у них будущее?
RussianFellow, перелогинься!

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

G>Преимуществ перед РСУБД нет. Будущего тоже нет.

Можно более развернутое обоснование?

M>Какие у них преимущества? Есть ли у них будущее?
Поиск выдаёт какие-то статейки на хабре 2015г.
Что с тех пор на них написали?

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

M>>Какие у них преимущества? Есть ли у них будущее?
G>Преимуществ перед РСУБД нет. Будущего тоже нет.

Это мягко говоря преувеличение. Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.

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

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

G>>Преимуществ перед РСУБД нет. Будущего тоже нет.

M>Можно более развернутое обоснование?

Графовая БД отличается от реляционной тем, что имеет в языке запросов алгоритмы обхода графов: поиск в глубину, в ширину, транзитивное замыкание итд.

Если граф влезает в память, то возможности и быстродействие РСБУД и графовой БД сравнимы: просто загружаем в память весь граф и обходим так как нужно. Так как алгоритмы на графах не представляют собой ноу-хау, то преимущество уже реализованных алгоритмов внутри графовой БД незначительно.

А вот если граф не влезает в память, то надо немного подумать.
Основная операция при обходе графа — получение списка связанных вершин.
На SQL это можно записать так:

select To from Edges where From=@id

Где edges это пара (From,To)
В РСУБД эта операция оптимизируется индексом (B+ tree). На сегодня нет реализаций хранимых данных, которые смогут быстрее выполнить такой запрос. Так что в случае очень больших графов тоже смысла в специализированной графовой БД нет.


Графовые базы имели смысл лет 20 назад, так как большинство РСУБД не имели возможностей описать рекурсивный алгоритм на языке запросов. Сейчас мало того, что можно сделать рекурсивный запрос, так еще и можно написать функцию на языке высокого уровня, которая будет обходить граф как нужно и не гонять данные между приложением и базой.

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

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

M>>>Какие у них преимущества? Есть ли у них будущее?
G>>Преимуществ перед РСУБД нет. Будущего тоже нет.

P>Это мягко говоря преувеличение.
Сможете обосновать свои слова?

P>Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.
Это как раз является причиной смотреть на какие-то альтернативы РСУБД там где РСУБД прекрасно справляется.

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

P>Это мягко говоря преувеличение. Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.

В смысле? Люди не умеют в нормализацию? Не умеют в денормализацию? Не знают о существовании репликации? Не умеют в схемы?
Что ты имеешь в виду под "готовить"?

Почему ты этот вопрос поднял под этим топиком?

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

M>Какие у них преимущества? Есть ли у них будущее?

Не так давно нашли для них новую нишу — relationship based access control. Суть в том, что авторизация по тройке (юзер объект операция) выполняется отдельной системой, в которой хранятся только айдишники объектов и все необходимые взаимосвязи кому-чего-что-можно.

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

P>>Это мягко говоря преувеличение. Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.

Ф>В смысле? Люди не умеют в нормализацию? Не умеют в денормализацию? Не знают о существовании репликации? Не умеют в схемы?
Ф>Что ты имеешь в виду под "готовить"?

И нормализацию, и денормализацию, и написание запросов, и проектирование схем, и оптимизацию производительности, и много чего другого.

Ф>Почему ты этот вопрос поднял под этим топиком?

"Преимуществ перед РСУБД нет. Будущего тоже нет."

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

M>>>>Какие у них преимущества? Есть ли у них будущее?
G>>>Преимуществ перед РСУБД нет. Будущего тоже нет.

P>>Это мягко говоря преувеличение.
G>Сможете обосновать свои слова?

Читаем вместе:
"Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше."

P>>Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.
G>Это как раз является причиной смотреть на какие-то альтернативы РСУБД там где РСУБД прекрасно справляется.

Альтернативы рсубд где рсубд прекрасно справляется? Что вы хотели сказать — непонятно. Альтернативы ищут там, где рсубд не справляется, и без разницы, какие причины. Когда проектная команда не справляется с написанием запросов — в таком случае или рсубд не взлетит, или проект не взлетит. Разницы в отношении рсубд совсем немного.

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

P>И нормализацию, и денормализацию, и написание запросов, и проектирование схем, и оптимизацию производительности, и много чего другого.

Интересно, в чём проблема. С моей точки зрения один талмуд, полгода практики и... всё будешь уметь. Что мешает?

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

P>>И нормализацию, и денормализацию, и написание запросов, и проектирование схем, и оптимизацию производительности, и много чего другого.

Ф>Интересно, в чём проблема. С моей точки зрения один талмуд, полгода практики и... всё будешь уметь. Что мешает?

Полгода практики в чистом виде никогда не бывает:
Во первых, всегда есть митинги, они отнимают существенную долю времени.
Во вторых, есть куча багфикса-отладки-тестов коего процентов 80% от всего подряд и с бд там будет какая ни будь мелочевка в основной массе, т.к. всё это связано с огромным количеством коммуникации — уточнить, спросить, обсудить, проверить, написать тест, пофиксить одну строчку, и так по кругу.
В третьих, куча работы связаной с билдами, локальным окружением, инфраструктурой и тд
И задачи по проекту далеко не всегда включают в себя БД, особенно, если спецализаци — фуллстек, что сейчас крайне популярно
Кроме того, знание домена никто не отменял, оно намного более важно чем бд и вообще все технологии взятые в одном проекте разом

Итого — эти полгода придется набирать урывками и года за три-четыре люди обычно справляются. Но штука в том, что через эти три-четыре года митингов станет больше, а возможно прибавятся и менеджерские обязанности. Итого — если у нас не чистый бакенд, коих очень мало, то шансы освоить рсубд вообще говоря минимальны. Что и наблюдаем.

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

G>На SQL это можно записать так:
G>

G>select To from Edges where From=@id
G>

G>Где edges это пара (From,To)
G>В РСУБД эта операция оптимизируется индексом (B+ tree). На сегодня нет реализаций хранимых данных, которые смогут быстрее выполнить такой запрос. Так что в случае очень больших графов тоже смысла в специализированной графовой БД нет.

А как будет обход в глубину выглядет на этом SQL и какая квалификация потребуется от разработчика что бы такое сварганить?

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


P>А как будет обход в глубину выглядет на этом SQL и какая квалификация потребуется от разработчика что бы такое сварганить
На sql нет обхода в глубину и в ширину, это декларативный язык.чтобы такое сварганить нужно знать алгоритмы на графах и синтаксис используемой бд. Я думаю если у вас проект, где есть граф, не вмещающийся в память, то вам в любом случае понадобятся специалисты с такими знаниями.

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

M>Какие у них преимущества? Есть ли у них будущее?

Это, если я правильно понял, фактически другое название иерархических БД, известных еще с 1960-х?

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

P>>А как будет обход в глубину выглядет на этом SQL и какая квалификация потребуется от разработчика что бы такое сварганить
G>На sql нет обхода в глубину и в ширину, это декларативный язык.чтобы такое сварганить нужно знать алгоритмы на графах и синтаксис используемой бд. Я думаю если у вас проект, где есть граф, не вмещающийся в память, то вам в любом случае понадобятся специалисты с такими знаниями.

Намолачивать запросы-обходы разного сорта вручную это довольно высокая квалификация. А от скажем тот же graphql поддерживается neo4f. Для рсубд вам придется пилить запросы для рсубд. С neo4j вы можете такое большей частью переложить эту работу.

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

P>Намолачивать запросы-обходы разного сорта вручную это довольно высокая квалификация. А от скажем тот же graphql поддерживается neo4f. Для рсубд вам придется пилить запросы для рсубд.

Чтобы работать с БД надо знать язык запросов, это логично. А чтобы эффективно работать — надо ещё и понимать как работает оптимизатор.

Это все независимо от БД, хоть postgres, хоть neo4f, хоть ещё что-то

В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

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

G>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

Вот-вот. А количество тех, кто знает — не увеличивается.

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

G>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

Осталось еще старую фразу Тома Кайта процитировать для полноты абсурда: "Если что-то можно сделать в БД, то там оно и должно быть сделано"(с)

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

P>Это мягко говоря преувеличение. Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.

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

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

G>>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

IT>Осталось еще старую фразу Тома Кайта процитировать для полноты абсурда: "Если что-то можно сделать в БД, то там оно и должно быть сделано"(с)

Да бог с ним с Кайтом. Люди про транзакции и джоины не слышали. Прыгают с бубном вокруг nosql, решая проблемы, которых в РСУБД нет.

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

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

P>>Намолачивать запросы-обходы разного сорта вручную это довольно высокая квалификация. А от скажем тот же graphql поддерживается neo4f. Для рсубд вам придется пилить запросы для рсубд.

G>Чтобы работать с БД надо знать язык запросов, это логично. А чтобы эффективно работать — надо ещё и понимать как работает оптимизатор.

G>Это все независимо от БД, хоть postgres, хоть neo4f, хоть ещё что-то

G>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

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

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

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

P>>И нормализацию, и денормализацию, и написание запросов, и проектирование схем, и оптимизацию производительности, и много чего другого.

Ф>Интересно, в чём проблема. С моей точки зрения один талмуд, полгода практики и... всё будешь уметь. Что мешает?

Полгода будет маловато. Года 3-4 хождения по граблям это самый минимум, для более-менее серьезного применения.

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

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

G>>>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

IT>>Осталось еще старую фразу Тома Кайта процитировать для полноты абсурда: "Если что-то можно сделать в БД, то там оно и должно быть сделано"(с)

K>Да бог с ним с Кайтом. Люди про транзакции и джоины не слышали. Прыгают с бубном вокруг nosql, решая проблемы, которых в РСУБД нет.

Ох уж эти теоретики...

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

G>>>>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

IT>>>Осталось еще старую фразу Тома Кайта процитировать для полноты абсурда: "Если что-то можно сделать в БД, то там оно и должно быть сделано"(с)

K>>Да бог с ним с Кайтом. Люди про транзакции и джоины не слышали. Прыгают с бубном вокруг nosql, решая проблемы, которых в РСУБД нет.

VC>Ох уж эти теоретики...

Какие теоретики? Ты думаешь я в реальности всё это не видел? Есть наверно какие-то узкие предметные области, где отказ от РСУБД оправдан. Но за время нереляционного хайпа успело похоже вырасти поколение, пихавшее неРСУБД вообще везде и в итоге мало что в БД умеющее.

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

K>Прыгают с бубном вокруг nosql, решая проблемы, которых в РСУБД нет.
Напомнило:
— А что в резюме писать?
— Ну, ты например SQL знаешь?
— Нет
— Значит пиши: NoSQL

P>Это мягко говоря преувеличение. Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.

Потому что объемы данных становятся очень большими, а масштабировать РСУБД на эти объемы мало кто умеет. Я б, пожалуй, назвал Google (Spanner) да может быть Яндекс (с их вариантом Calvin'а).

G>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

Леворезьбовые СУБД обычно не от хорошей жизни прикручивают, а от невозможности сделать распределенную РСУБД.

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

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

P>>Это мягко говоря преувеличение. Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.

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

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

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

Если говорить про запись, то здесь также всё зависит от требований к производительности и к целостности выполнения транзакции.
Например, если вызывающая сторона (приложение) по отдельности посылает команду — открыть транзакцию, потом также по отдельности несколько команд на запись (update/delete/insert) и потом также отдельным вызовом завершает транзакцию, то образуется сразу 2 проблемы:
— трафик между приложением и БД
— целостность, т.к. в случае какого-либо сбоя (например разрыв соединения или отказ в работе вызывающей стороны) получаем блокировки созданные в рамках незавершенной транзакции.

Иногда чтобы этого избежать, всё запихивают в один скрипт, типа:

begin; delete(n)/insert(n)/update(n); commit/rollback;

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

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

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

VC>>Ох уж эти теоретики...

K>Какие теоретики? Ты думаешь я в реальности всё это не видел? Есть наверно какие-то узкие предметные области, где отказ от РСУБД оправдан. Но за время нереляционного хайпа успело похоже вырасти поколение, пихавшее неРСУБД вообще везде и в итоге мало что в БД умеющее.

Скорее наоборот — область деятельности типичного разработчика настолько перегружена, что погрузиться в БД нет возможности. РСУБД довольно треботвательна к квалификации разработчика технология, ошибок не прощает.

1. есть тн фуллстеки — от верстки на фроте, до запросов в бд. В итоге слишком часто ни там, ни там.
2. методология девопс, это как фуллстеки, только шире — еще и тестирование на себя берут, и инфраструктуру, и даже частично l2 суппорт.

Теоретически, можно по вечерам с книжкой засесть. Только учить то надо не одну бд, а по книге на каждую область, и здесь ровно тот же зоопарк, что и в работе.
РСУБД требует довольно глубокого погружения, иначе не бывает.

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

P>>Это мягко говоря преувеличение. Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.

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

А можно развернуть этот аргумент, что бы понятнее было?

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

P>>Это мягко говоря преувеличение. Ощущение, что с каждым годом количество людей, которые понимают как правильно готовить РСУБД, становится всё меньше.

SD>Потому что объемы данных становятся очень большими, а масштабировать РСУБД на эти объемы мало кто умеет. Я б, пожалуй, назвал Google (Spanner) да может быть Яндекс (с их вариантом Calvin'а).

Сейчас от разработчиков в норме требуют чуть не всё подряд. Чем ширше специализация, тем менее глубоко будут копать такие специалисты. А раз так, то сложные и мощные технологии для таких будут недоступны.

Да ЗП добавляет веселья — клауд стоит раз в десять меньше, чем ЗП команды разработчиков. А раз так, то вопросы БД можно решать самим клаудом.

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

P>>>Намолачивать запросы-обходы разного сорта вручную это довольно высокая квалификация. А от скажем тот же graphql поддерживается neo4f. Для рсубд вам придется пилить запросы для рсубд.

G>>Чтобы работать с БД надо знать язык запросов, это логично. А чтобы эффективно работать — надо ещё и понимать как работает оптимизатор.
G>>Это все независимо от БД, хоть postgres, хоть neo4f, хоть ещё что-то
G>>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

VC>Проблема с СУБД в том, что они оптимизируют под простоту разработки и использования а не под быстродействие.
VC>Чтобы графовые алгоритмы на СУБД работали хорошо, придется серьезно поплясать с бубном, потрахаться с оптимизатором.
VC>На некоторых базах некоторые вещи будут работать все равно плохо и ничего ты с этим не сделаешь.
VC>Тогда как графовых базах нужные паттерны уже оптимизированы "из коробки".
Это похоже на историю с документарными БД. Лет 10 назад был хайп документарных баз данных из-за Mongo.
Со временем во все взрослые движки добавили обработку JSON и документарные базы стали в целом не нужны.

То же самое происходит с графовыми базами. В MS SQL добавили поддержку графов еще 5 лен назад, в oracle и postres давно существуют плагины для графов.
Но даже если ничего нет, то никто не мешает с помощью рекурсивных запросов и расширений на компилируемом языке сделать свое расширение.
Да, это сложно, но это будет вполне оправдано если размеры графа не позволяют загрузить его в память приложения и обработать существующими алгоритмами.

VC>Так что "никаких преимуществ нет" это неправильный ответ.
Приведите пример, где Neo4j или GraphDb разрывает MS SQL на вот этом примере https://learn.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-sample?view=sql-server-ver16

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

P>Сейчас от разработчиков в норме требуют чуть не всё подряд. Чем ширше специализация, тем менее глубоко будут копать такие специалисты.
Программист никогда не сможет заранее знать все технологии достаточно глубоко.
Хороший программист должен уметь за разумное время изучить новую технологию достаточно глубоко за разумное время.
Например если человек всю жизнь программировал на .NET под Windows и использовал MS SQL, то он вполне сможет за месяц начать писать на том же .NET под Linux с базой на Postgres.



P>А раз так, то сложные и мощные технологии для таких будут недоступны.
Если программист никогда в жизни не касался баз данных или веба, то ему будет крайне сложно и в клауде.

P>Да ЗП добавляет веселья — клауд стоит раз в десять меньше, чем ЗП команды разработчиков. А раз так, то вопросы БД можно решать самим клаудом.
Клауд требует больше знаний, чем РСУБД. Тем более что немая часть задач в калуде это как раз хранение данных, которое без понимания очень легко сделать неправильно.

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

G>Программист никогда не сможет заранее знать все технологии достаточно глубоко.
G>Хороший программист должен уметь за разумное время изучить новую технологию достаточно глубоко за разумное время.

Хорошесть она разная. Обычно если заказчик доволен — значит хороший. Но вот квалификация может быть и не той системы.

G>Например если человек всю жизнь программировал на .NET под Windows и использовал MS SQL, то он вполне сможет за месяц начать писать на том же .NET под Linux с базой на Postgres.

Куда деть фуллстеков, которых пруд пруди, и т.н. девопс метолодогию, когда девелоперы заняты вообще всем подряд, разве что железо не колупают?

P>>Да ЗП добавляет веселья — клауд стоит раз в десять меньше, чем ЗП команды разработчиков. А раз так, то вопросы БД можно решать самим клаудом.
G>Клауд требует больше знаний, чем РСУБД. Тем более что немая часть задач в калуде это как раз хранение данных, которое без понимания очень легко сделать неправильно.

Именно потому люди бОльше внимания уделяют клауду, а РСУБД идет по остаточноу принципу.

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

G>Со временем во все взрослые движки добавили обработку JSON и документарные базы стали в целом не нужны.

Каким образом обработка JSON решила вопросы с горизонтальной масштабируемостью?

G>Да, это сложно, но это будет вполне оправдано если размеры графа не позволяют загрузить его в память приложения и обработать существующими алгоритмами.

Если это сложно, то следовательно недоступно для большинства команд и проектов.

VC>>Так что "никаких преимуществ нет" это неправильный ответ.
G>Приведите пример, где Neo4j или GraphDb разрывает MS SQL на вот этом примере https://learn.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-sample?view=sql-server-ver16

Не совсем понятно, что вы ждете. Neo4j может работать с запросами graphql напрямую. Т.е. пока ваша команда ms sql пишет и отлаживает запросы, ребята с neo4j уже вышли в продакшн. А сэкономленое на разработке время отдали на оплату клауда.

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

G>>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

SD>Леворезьбовые СУБД обычно не от хорошей жизни прикручивают, а от невозможности сделать распределенную РСУБД.
Точнее от неумения делать распределенную РСУБД.

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

M>Какие у них преимущества? Есть ли у них будущее?

А про обычные БД? Я думаю что у них тоже нет никаких стимулов чтобы выжить, кроме преемственности. Когда умрет оракл, тогда и все остальные субд, но оракл умрет последним ибо слишком много всего на нем завязано. Но даже сегодня и вчера — это просто трупы.

Кто заменит оракл обеспечив совместимость — тот сорвет джекпот, если за копейки не продастся.

G>Точнее от неумения делать распределенную РСУБД.

Потому что это и в самом деле нетривиально. Даже банальные вторичные индексы уже не так просто сделать (особенно если нужно более одного).

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

M>Какие у них преимущества? Есть ли у них будущее?

Есть, если данные представлены графовой моделью и их много. Но количество таких задач сопоставимо с количеством задач, которые можно решить с помощью Prolog. Я однажды работал у интернет-провайдера и создавал систему учёта сетевого оборудования. Граф, представленный сетью провайдера легко моделировался таблицей списка рёбер, различные алгоритмы на графах — CTE и хранимыми процедурами. Хотя сперва тоже почитал про графовые БД, то так не понял, как они мне помогут.

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

P>Не совсем понятно, что вы ждете. Neo4j может работать с запросами graphql напрямую. Т.е. пока ваша команда ms sql пишет и отлаживает запросы, ребята с neo4j уже вышли в продакшн. А сэкономленое на разработке время отдали на оплату клауда.

Я думаю что это вылечат квотами на энергоэффективность в клаудах, а также урезанием финансирования. Чтобы не неслись в продакшн, как бешеные, и не тащили свои недоделки.

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

С>Я думаю что это вылечат квотами на энергоэффективность в клаудах, а также урезанием финансирования. Чтобы не неслись в продакшн, как бешеные, и не тащили свои недоделки.

Квотами вряд ли получится решить проблему, тк time-to-market идет не от разработчиков, а от бизнеса.
Клауд подстраивается под такую реальность, ровно как и разработчики.

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

VC>>>Ох уж эти теоретики...

K>>Какие теоретики? Ты думаешь я в реальности всё это не видел? Есть наверно какие-то узкие предметные области, где отказ от РСУБД оправдан. Но за время нереляционного хайпа успело похоже вырасти поколение, пихавшее неРСУБД вообще везде и в итоге мало что в БД умеющее.

P>Скорее наоборот — область деятельности типичного разработчика настолько перегружена, что погрузиться в БД нет возможности. РСУБД довольно треботвательна к квалификации разработчика технология, ошибок не прощает.

P>1. есть тн фуллстеки — от верстки на фроте, до запросов в бд. В итоге слишком часто ни там, ни там.
P>2. методология девопс, это как фуллстеки, только шире — еще и тестирование на себя берут, и инфраструктуру

Мне кажется, наоборот. Может конечно это мой субъективный опыт. Относительно недавно вообще все были фуллстеками. На человека, который сказал бы "я специалист по mfc (или vcl), а про БД ничего не знаю" смотрели бы как на неполноценного. Но в борьбе за снижение порога входа в профессию мы пришли к суперузким специализациям типа senior react developer. Работа человека — знать конкретный фреймворк, а всё что за его пределами — это уже другая специализация.

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

G>>Точнее от неумения делать распределенную РСУБД.

SD>Потому что это и в самом деле нетривиально. Даже банальные вторичные индексы уже не так просто сделать (особенно если нужно более одного).

А можно пример, что бы понятнее было?

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

P>А можно развернуть этот аргумент, что бы понятнее было?
SQL проигрывает языкам высокого уровня по выразительности и организации кода.
Я работал в проекте, где вся (вообще вся) бизнес-логика, кроме UI, реализована в хранимках. Такой проект напоминает переросшую все разумные границы школьную программу на Бэйсике. Поддерживать его не просто.

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

G>>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.
SD>Леворезьбовые СУБД обычно не от хорошей жизни прикручивают, а от невозможности сделать распределенную РСУБД.

Или такой еще вариант. В Гугле или Яндексе сталкиваются с проблемой обработки своих охренилиардов данных, применяют какую-то нестандартную БД, потом пишут про это статью "применение Х при обработке больших объемов данных".

Молодые и горячие разработчики куда более простого софта читают эту статью, соображают что "а у нас же тоже очень много данных (аж целый миллион записей) — надо срочно переходить на Х, ведь так серьезные разработчики делают". И внедряют. Хотя реально под их приложение простого одиночного Postgres было бы достаточно с многократным запасом....

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

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

G>>Со временем во все взрослые движки добавили обработку JSON и документарные базы стали в целом не нужны.

P>Каким образом обработка JSON решила вопросы с горизонтальной масштабируемостью?
Таким же как в NoSQL — JSON это отсуствие джоинов и легкий шаридинг.

G>>Да, это сложно, но это будет вполне оправдано если размеры графа не позволяют загрузить его в память приложения и обработать существующими алгоритмами.
P>Если это сложно, то следовательно недоступно для большинства команд и проектов.
У большинства команд и проектов нет проблемы не умещающихся в память данных.

VC>>>Так что "никаких преимуществ нет" это неправильный ответ.
G>>Приведите пример, где Neo4j или GraphDb разрывает MS SQL на вот этом примере https://learn.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-sample?view=sql-server-ver16

P>Не совсем понятно, что вы ждете. Neo4j может работать с запросами graphql напрямую. Т.е. пока ваша команда ms sql пишет и отлаживает запросы, ребята с neo4j уже вышли в продакшн. А сэкономленое на разработке время отдали на оплату клауда.
Так я и прошу пример кода, вместе с аналогом DDL для Neo4j, чтобы стало очевидно, что разработка на Neo4j выйдет в разы быстрее. Задача, связанная именно с алгоритмами на графах, по ссылке.

graphql кстати это вовсе не про алгоритмы на графах. Это про удобный запрос данных их разветвленной реляционной структуры. Для EF в .NET есть готовый пакет, который выставляет graphql эндпоинт.

F>Молодые и горячие разработчики куда более простого софта читают эту статью, соображают что "а у нас же тоже очень много данных (аж целый миллион записей) — надо срочно переходить на Х, ведь так серьезные разработчики делают". И внедряют. Хотя реально под их приложение простого одиночного Postgres было бы достаточно с многократным запасом....

сдается мне, что у тех молодых и горячих тупо больше опыта и знаний. postgres кверики не умеет параллелить, считай весь анализ (тм) тошнит в однопотоке. вопрос не в размере, а то что даже под небольшой объем постгрес даже ноутбук не сможет нагрузить как следует и соответственно сливает как по скорости так и по тяжести администрирования, требуя присиданий DBA, анала с вакумом и прочими нафиг в большинстве случаев не нужными заморочками.

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

G>>Точнее от неумения делать распределенную РСУБД.
SD>Потому что это и в самом деле нетривиально. Даже банальные вторичные индексы уже не так просто сделать (особенно если нужно более одного).

Во-первых когда ваше приложение упрется в задачу распределения данных в РСУБД, то все известные NoSQL уже загнутся от нагрузки. РСУБД вполне могут нормально работать при соотношении объема хранимых данных и ОП 100:1 и даже 1000:1. Тогда как большинство NoSQL решений уже не смогут работать при 10:1.
Во-вторых если вы доживете до такой проблемы с РСУБД, то у вас уже будет достаточно оптимальная структура базы, которая легко переживёт распределение по нескольким узлам.

F>Молодые и горячие разработчики куда более простого софта

Так я не про них писал. А про тех, кто пока не в состоянии сделать распределенную РСУБД. Я ж писал уже, что это задача и в самом деле непростая.

G>graphql кстати это вовсе не про алгоритмы на графах. Это про удобный запрос данных их разветвленной реляционной структуры.

С graphql все еще хуже, как раз тот случай про "молодых и горячих", и к базам данных сей протокол вообще отношения не имеет. Это именно что "существующие RPC неудобны, хочу еще один стандарт RPC, который точно лучше". Все как в том меме от xkcd. Й-эх, я б к двум известным computer science problems (те что cache invalidation и naming) добавил бы третью, "еще один вариант RPC". А ну, кто уже свой вариант придумывал, поднимите руку! Я подниму сразу две. Не от большого ума, конечно, но молодым и горячим можно

G>Во-первых когда ваше приложение упрется в задачу распределения данных в РСУБД, то все известные NoSQL уже загнутся от нагрузки. РСУБД вполне могут нормально работать при соотношении объема хранимых данных и ОП 100:1 и даже 1000:1. Тогда как большинство NoSQL решений уже не смогут работать при 10:1.

Честно говоря, я вас не понимаю. При чем тут соотношения хранимых данных и памяти? Проблемы, с которыми я встречаюсь, совсем другого рода. И высокая нагрузка на базу данных — это не для красного словца, а вполне себе реальность (несколько миллионов запросов в секунду).

G>Во-вторых если вы доживете до такой проблемы с РСУБД, то у вас уже будет достаточно оптимальная структура базы, которая легко переживёт распределение по нескольким узлам.

Как вы вообще себе это представляете? Давайте по-простому: есть таблица accounts, где, ну, пусть 3 миллиарда записей (причем активных больше половины). И у нее есть many-to-many relation: "моя записная книжка", когда один аккаунт может содержать, ну, скажем, до полумиллиона ссылок на другие аккаунты. Какую именно мне использовать РСУБД, и как раскидать таблицы по узлам сети, чтобы эта РСУБД не выродилась в де-факто key-value storage, а хотя бы сохранила referential integrity.

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

G>>Во-первых когда ваше приложение упрется в задачу распределения данных в РСУБД, то все известные NoSQL уже загнутся от нагрузки. РСУБД вполне могут нормально работать при соотношении объема хранимых данных и ОП 100:1 и даже 1000:1. Тогда как большинство NoSQL решений уже не смогут работать при 10:1.

SD>Честно говоря, я вас не понимаю. При чем тут соотношения хранимых данных и памяти? Проблемы, с которыми я встречаюсь, совсем другого рода. И высокая нагрузка на базу данных — это не для красного словца, а вполне себе реальность (несколько миллионов запросов в секунду).
Мы сейчас о масштабировании?
Для масштабирования вам нужен шаридинг — запросы по одному диапазону ключей идут в одну ноду, по другому диапазону — в другую.
Вопрос в том, сколько вам нужно шард — зависит от объема хранимых и запрашиваемых данных, а также объема памяти. Так вот РСУБД справляется при гораздо более высоком соотношении, чем noSQL базы.


G>>Во-вторых если вы доживете до такой проблемы с РСУБД, то у вас уже будет достаточно оптимальная структура базы, которая легко переживёт распределение по нескольким узлам.

SD>Как вы вообще себе это представляете? Давайте по-простому: есть таблица accounts, где, ну, пусть 3 миллиарда записей (причем активных больше половины). И у нее есть many-to-many relation: "моя записная книжка", когда один аккаунт может содержать, ну, скажем, до полумиллиона ссылок на другие аккаунты. Какую именно мне использовать РСУБД, и как раскидать таблицы по узлам сети, чтобы эта РСУБД не выродилась в де-факто key-value storage, а хотя бы сохранила referential integrity.
А как такую же задачу решает любой nosql? С тем же referential integrity.
Если расскажете, то я вам расскажу как сделать это на РСУБД.

G>Мы сейчас о масштабировании?

С самого начала nosql был "о масштабировании". Потому как другое "достоинство" (отсутствие схемы) на самом деле является недостатком.

G>Для масштабирования вам нужен шаридинг — запросы по одному диапазону ключей идут в одну ноду, по другому диапазону — в другую.

А теперь расскажите, как можно эффективно реализовать secondary indexes. Без которых РСУБД вырождаются в те самые nosql, key-value store. Стандартные подходы (например, упорядочивание записи — так что сначала пишем индекс, потом сам ключ) имеют определенные проблемы с эффективностью и атомарностью (после чтения индекса надо проверить, что ключи в самом деле существуют).

	Скрытый текст
	Вопросом распределенных БД я некоторое время занимаюсь очень плотно, и в теме разбираюсь более чем. Не знаю, какой опыт у вас, могу лишь судить по заявлениям типа "вы не умеете их готовить". В этой области есть несколько фундаментальных проблем, у которых пока нет общепринятого решения. Я уже три раза упоминал Spanner (как одну из реализаций, основанной на применении высокоточного таймера), и Calvin, основанный на детерминированном исполнении очереди транзакций, порядок которых выбирается лидером RAFT). Это должно было навести вас на определенные мысли о том, что я таки знаю, о чем пишу. Если же вы с этими протоколами не знакомы, значит, вам просто не требовалось решать масштабные задачи, и для вас РСУБД действительно достаточны.

G>А как такую же задачу решает любой nosql? С тем же referential integrity.

Никак — nosql не имеет referential integrity Для каждого конкретного отношения (relation) пишется своя бизнес-логика, обычно инкапсулировання где-то в отдельном сервисе. По факту каждый сервис из себя представляет в чем-то уникальную базу данных, высокая производительность которой основана на каких-то дополнительных знаниях о свойствах лежащих в БД объектов. Костыли, конечно, — ну так nosql для того и нужен. Можно это сравнить с применением FFI где-нибудь в Питоне: сам по себе он слишком тормозной, поэтому определенные задачи приходится решать на С.

G>Если расскажете, то я вам расскажу как сделать это на РСУБД.

И как же? Чем это будет лучше в сравнении с key-value store? И в чем вообще будут отличия? РСУБД для того и нужны, чтоб referential integrity (и ACID вообще) реализовывать.

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

G>>А как такую же задачу решает любой nosql? С тем же referential integrity.

SD>Никак — nosql не имеет referential integrity Для каждого конкретного отношения (relation) пишется своя бизнес-логика, обычно инкапсулировання где-то в отдельном сервисе. По факту каждый сервис из себя представляет в чем-то уникальную базу данных, высокая производительность которой основана на каких-то дополнительных знаниях о свойствах лежащих в БД объектов.

То есть РСУБД ведет себя не хуже как минимум. А если повезет сделать шардирование и\или синхронизацию записей, то еще и джоины с индексами заработают.

SD>Костыли, конечно, — ну так nosql для того и нужен.
NoSQL был нужен для двух вещей:
1) Инмемори кэш. Редис всех победил и теперь де-факто стандарт для кэша.
2) Работа с JSON, теперь это умеют все взрослые СУБД
Все остальные продукты теряют рынок. Я думаю, что они просто исчезнут лет через пять. Еще к NoSQL приписывали разные аналитические базы, но эта дурость быстро кончилась.

G>>Если расскажете, то я вам расскажу как сделать это на РСУБД.
SD>И как же? Чем это будет лучше в сравнении с key-value store? И в чем вообще будут отличия?
Например в том, что в рамках одного шарда есть и referential integrity, и ACID. Да и в целом не вижу ничего плохого чтобы сделать шардированный key-value на РСУБД со вторичными индексами.

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

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

G>>>>>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

IT>>>>Осталось еще старую фразу Тома Кайта процитировать для полноты абсурда: "Если что-то можно сделать в БД, то там оно и должно быть сделано"(с)

K>>>Да бог с ним с Кайтом. Люди про транзакции и джоины не слышали. Прыгают с бубном вокруг nosql, решая проблемы, которых в РСУБД нет.

VC>>Ох уж эти теоретики...

K>Какие теоретики? Ты думаешь я в реальности всё это не видел? Есть наверно какие-то узкие предметные области, где отказ от РСУБД оправдан. Но за время нереляционного хайпа успело похоже вырасти поколение, пихавшее неРСУБД вообще везде и в итоге мало что в БД умеющее.

Я не знаю что ты видел в реальности. Моя реальность сейчас такова, что я борюсь с оптимизатором, который считает статистику через пень-колоду и генерирует неоптимальные планы. Мы храним графы тоже, хотя наши графы максимально простые (их можно развернуть просто в список деревьев) и относительно небольшие. Но проблемы возникают уже на этом этапе. Поэтому я и говорю про "теоретиков".
Чем сложнее запрос тем ниже вероятность что сгенерированный план будет оптимальным. Всякие хинты и прочее помогают только частично. СУБД это универсальный инструмент и он приемлемо работает для относительно несложных случаев. Как только объем данных становится большим (начиная с терабайта и выше) а запросы относительно сложными (большое количество джойнов сильно усложняет оптимизатору работу), начинаются как раз те самые танцы с бубном. Рекурсивные запросы, плюс навесь еще несколько джойнов на большие таблицы сверху, это сложные случаи. Если использовать тот же движок реляционной базы, но более жестко прописать все алгоритмы которые там требуются, не давая возможности оптимизатору делать шаг влево шаг вправо, результат получится гораздо лучше.

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

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

P>>>>Намолачивать запросы-обходы разного сорта вручную это довольно высокая квалификация. А от скажем тот же graphql поддерживается neo4f. Для рсубд вам придется пилить запросы для рсубд.

G>>>Чтобы работать с БД надо знать язык запросов, это логично. А чтобы эффективно работать — надо ещё и понимать как работает оптимизатор.
G>>>Это все независимо от БД, хоть postgres, хоть neo4f, хоть ещё что-то
G>>>В целом восторженные возгласы по поводу леворезьбовых бд возникают только у тех кто РСУБД не знает.

VC>>Проблема с СУБД в том, что они оптимизируют под простоту разработки и использования а не под быстродействие.
VC>>Чтобы графовые алгоритмы на СУБД работали хорошо, придется серьезно поплясать с бубном, потрахаться с оптимизатором.
VC>>На некоторых базах некоторые вещи будут работать все равно плохо и ничего ты с этим не сделаешь.
VC>>Тогда как графовых базах нужные паттерны уже оптимизированы "из коробки".
G>Это похоже на историю с документарными БД. Лет 10 назад был хайп документарных баз данных из-за Mongo.
G>Со временем во все взрослые движки добавили обработку JSON и документарные базы стали в целом не нужны.

G>То же самое происходит с графовыми базами. В MS SQL добавили поддержку графов еще 5 лен назад, в oracle и postres давно существуют плагины для графов.
G>Но даже если ничего нет, то никто не мешает с помощью рекурсивных запросов и расширений на компилируемом языке сделать свое расширение.
G>Да, это сложно, но это будет вполне оправдано если размеры графа не позволяют загрузить его в память приложения и обработать существующими алгоритмами.

Это называется "городить свой велосипед", да. Я работаю с postgres и хотя для него есть графовые расширения, но они не работают например на AWS Aurora, который мы используем.
Так что этот вариант отпадает. Приходится плясать с бубном, ничего не поделаешь. Neo4J или что-то подобное для нас тоже не вариант.
Я не агитирую особо за переход на них, просто говорю что на голой реляционной базе это городить это далеко не простая история. Дело больше не в написании запросов а с плясками с бубном вокруг оптимизатора после того как эти запросы написаны. Лучший вариант был бы использование реляционного движка и написание своего функционала поверх него, но это задача и сложная и далеко не всегда возможная (особенно если хостишься где-то в клаудах).

VC>>Так что "никаких преимуществ нет" это неправильный ответ.
G>Приведите пример, где Neo4j или GraphDb разрывает MS SQL на вот этом примере https://learn.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-sample?view=sql-server-ver16

С MSSQL я уже больше 10 лет не работаю так что не имею понятия.

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

P>Скорее наоборот — область деятельности типичного разработчика настолько перегружена, что погрузиться в БД нет возможности. РСУБД довольно треботвательна к квалификации разработчика технология, ошибок не прощает.

С точностью до наоборот. РСУБД ошибки прощает куда больше, чем типичная NoSQL, встающая раком при малейшем неосторожном движении.

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

K>Да бог с ним с Кайтом. Люди про транзакции и джоины не слышали. Прыгают с бубном вокруг nosql, решая проблемы, которых в РСУБД нет.

Под каждую проблему — свой инструмент. Это гораздо адекватнее, чем все решать молотком.

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

G>>Мы сейчас о масштабировании?

SD>С самого начала nosql был "о масштабировании". Потому как другое "достоинство" (отсутствие схемы) на самом деле является недостатком.

G>>Для масштабирования вам нужен шаридинг — запросы по одному диапазону ключей идут в одну ноду, по другому диапазону — в другую.

SD>А теперь расскажите, как можно эффективно реализовать secondary indexes. Без которых РСУБД вырождаются в те самые nosql, key-value store. Стандартные подходы (например, упорядочивание записи — так что сначала пишем индекс, потом сам ключ) имеют определенные проблемы с эффективностью и атомарностью (после чтения индекса надо проверить, что ключи в самом деле существуют).

G>>А как такую же задачу решает любой nosql? С тем же referential integrity.
SD>Никак — nosql не имеет referential integrity Для каждого конкретного отношения (relation) пишется своя бизнес-логика, обычно инкапсулировання где-то в отдельном сервисе. По факту каждый сервис из себя представляет в чем-то уникальную базу данных, высокая производительность которой основана на каких-то дополнительных знаниях о свойствах лежащих в БД объектов. Костыли, конечно, — ну так nosql для того и нужен. Можно это сравнить с применением FFI где-нибудь в Питоне: сам по себе он слишком тормозной, поэтому определенные задачи приходится решать на С.

G>>Если расскажете, то я вам расскажу как сделать это на РСУБД.
SD>И как же? Чем это будет лучше в сравнении с key-value store? И в чем вообще будут отличия? РСУБД для того и нужны, чтоб referential integrity (и ACID вообще) реализовывать.


РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия. Не на уровне ядра РСУБД малосовместимые, а на уровне интерфейса (SQL).
SQL — это декларативный интерфейс, когда оптимизатор сам решает как именно выполнять конкретный запрос. К сожалению, ни одна существующая реализация оптимизатора не выполняет эту работу сколько-нибудь эффективно для больших данных
(стоимость поддержки актуальной статистики оптимизатора растет линейно с ростом размера данных и есть подозрение что это вообще невозможно для достаточно больших баз данных).
Изначально SQL был сделан максимально дружелюбным для пользователя, чтобы им могли пользоваться не-программисты. Ну и проблемы растут в основном из этого.
Если же отойти от этой проблемы, принципиально нет причин по которым РСУБД (на уровне движка) не могли бы масштабироваться не хуже чем NoSQL. Наделать кучу шардов дурное дело нехитрое.
Поддерживать согласованность данных в разных шардах все равно потребуется какими-то внешними способами (как в случае NoSQL так и РСУБД). Плюс в случае РСУБД у тебя есть дополнительный бонус транзакционности на уровне одного шарда.

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


F>>Молодые и горячие разработчики куда более простого софта читают эту статью, соображают что "а у нас же тоже очень много данных (аж целый миллион записей) — надо срочно переходить на Х, ведь так серьезные разработчики делают". И внедряют. Хотя реально под их приложение простого одиночного Postgres было бы достаточно с многократным запасом....

Gt_>сдается мне, что у тех молодых и горячих тупо больше опыта и знаний. postgres кверики не умеет параллелить, считай весь анализ (тм) тошнит в однопотоке. вопрос не в размере, а то что даже под небольшой объем постгрес даже ноутбук не сможет нагрузить как следует и соответственно сливает как по скорости так и по тяжести администрирования, требуя присиданий DBA, анала с вакумом и прочими нафиг в большинстве случаев не нужными заморочками.

"Кверики" то он уже давно умеет параллелить. У него с другим в основном проблемы. Хотя из-за легаси там тоже есть проблемки, в частности необходимость "вакуума" и по процессу на коннекшн — это все от кривого дизайна 90-х годов идет.
При этом он не то чтобы плох, и кое какие вещи в нем очень неплохо оптимизированы. Но это такое лоскутное одеяло которое многими людьми делалось — кое где все классно, а кое где надо бы выкинуть и переписать заново.
Издержки опен сорса.

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


VC>РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия. Не на уровне ядра РСУБД малосовместимые, а на уровне интерфейса (SQL).
VC>SQL — это декларативный интерфейс, когда оптимизатор сам решает как именно выполнять конкретный запрос. К сожалению, ни одна существующая реализация оптимизатора не выполняет эту работу сколько-нибудь эффективно для больших данных
Громкое заявление, обоснование будет?
Какие альтернативы предлагаете?

VC>(стоимость поддержки актуальной статистики оптимизатора растет линейно с ростом размера данных и есть подозрение что это вообще невозможно для достаточно больших баз данных).
Статистика на то и статистика, что терпит погрешности. Чем больше данных, тем рже можно статистику обновлять. По умолчанию статистика обновляется при изменении какого процента строк, что приводит не к линейному росту затрат, а к логарифическом.
Для ОЧЕНЬ_БОЛЬШИХ таблиц во всех серьезных базах есть partitioning.

VC>Изначально SQL был сделан максимально дружелюбным для пользователя, чтобы им могли пользоваться не-программисты. Ну и проблемы растут в основном из этого.
Какую альтернативу предлагаете?

VC>Если же отойти от этой проблемы, принципиально нет причин по которым РСУБД (на уровне движка) не могли бы масштабироваться не хуже чем NoSQL. Наделать кучу шардов дурное дело нехитрое.
VC>Поддерживать согласованность данных в разных шардах все равно потребуется какими-то внешними способами (как в случае NoSQL так и РСУБД). Плюс в случае РСУБД у тебя есть дополнительный бонус транзакционности на уровне одного шарда.
А чем SQL мешает делать шарды?

VC>"Кверики" то он уже давно умеет параллелить.

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

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

Gt_>сдается мне, что у тех молодых и горячих тупо больше опыта и знаний. postgres кверики не умеет параллелить,

Да да да. Пришлось как то хоронить проект один. Там в самых розовых мечтах было что то в районе 100 заказов в день, без того чтобы распараллелить кверики не потянуть меганагрузку. Вот и вкрячили туда монгу аж на 5 машинах.
Вот, правда, на этой сотне заказов супермонга быстро легла, не помогли ей распараллеленые кверики почему то. А старый проект, гонявший примерно тех же заказов на пару порядков больше, и обходившийся самым дешевым таером Azure SQL почему то пахал без проблем. Но не модно и не молодежно, это да.

НС>Да да да. Пришлось как то хоронить проект один. Там в самых розовых мечтах было что то в районе 100 заказов в день, без того чтобы распараллелить кверики не потянуть меганагрузку. Вот и вкрячили туда монгу аж на 5 машинах.
НС>Вот, правда, на этой сотне заказов супермонга быстро легла, не помогли ей распараллеленые кверики почему то. А старый проект, гонявший примерно тех же заказов на пару порядков больше, и обходившийся самым дешевым таером Azure SQL почему то пахал без проблем. Но не модно и не молодежно, это да.

я не верю. даже если бы они все антипатерны собрали и писали бы в один документ данные со всех заказов, даже так было бы сложновато слечь на нескольких мб данных, что дали бы 100 заказов в день.
я не видел монго, но на сколько помню они аля key-value с вторичными индексами, т.е. тормозная на сканирующих запросах, не попадающих на индексы. но не на нескольких мб данных в год.

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


VC>>"Кверики" то он уже давно умеет параллелить.

Gt_>выполнение одного кверика толком не умеет параллелить. лишь при чтении с партицированных таблиц при условии, что там совпадет тучи условий, на фоне спарк можно считать, что не парраллеит вовсе.

Умеет, умеет. Разные вещи параллелятся — индекс сканы, джойны, аггрегации. Количество воркеров настраиваемое. Может вы просто не умеете это готовить?
https://www.postgresql.org/docs/current/parallel-plans.html

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

Gt_>я не верю.

Мне зачем об этом знать?

Gt_>даже если бы они все антипатерны собрали и писали бы в один документ данные со всех заказов, даже так было бы сложновато слечь на нескольких мб данных, что дали бы 100 заказов в день.

Не, они накосячили с самопальной очередью + еще какие то косяки в логике, в результате оно само себя заваливало бесконечными сообщениями.
Это был намек на то, что проблемы с производительностью самой БД в 95% проектов — на третьем плане. Что не мешало таки затащить в такой проект монгу, потому что это модно и молодежно. А то что они сфакапились в итоге именно на ней — так, вишенка на торте.

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

VC>Умеет, умеет. Разные вещи параллелятся — индекс сканы, джойны, аггрегации.

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

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

SD>Давайте по-простому: есть таблица accounts, где, ну, пусть 3 миллиарда записей (причем активных больше половины).

У тебя реально четверть населения планеты — активные аккаунты? Если реально — это крайне особенный кейс, таких на этом шарике — по пальцам одной руки, и решения из этого кейса в принципе нет смысла тиражировать.

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

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


VC>>РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия. Не на уровне ядра РСУБД малосовместимые, а на уровне интерфейса (SQL).
VC>>SQL — это декларативный интерфейс, когда оптимизатор сам решает как именно выполнять конкретный запрос. К сожалению, ни одна существующая реализация оптимизатора не выполняет эту работу сколько-нибудь эффективно для больших данных
G>Громкое заявление, обоснование будет?
G>Какие альтернативы предлагаете?

Обоснование ниже, про статистику и автоматизированный выбор оптимальных планов выполнения. Альтернатива — все правильно, partitioning (для снижения размера отдельных таблиц) + ручное управление планами выполнения. Что сильно увеличивает стоимость поддержки всего этого. Ни одна из известных мне РСУБД не предоставляет удовлетворительных способов решения этой проблемы. Как правило при росте объемов данных и сложности запросов, планы выполнения начинают плавать и начинается вуду с их оптимизацией на основе различных хинтов и т.п. Вообще говоря, не любую схему данных можно эффективно партиционировать или шардить. Как предлагаете работать с теми, которые не поддаются этому?

VC>>(стоимость поддержки актуальной статистики оптимизатора растет линейно с ростом размера данных и есть подозрение что это вообще невозможно для достаточно больших баз данных).
G>Статистика на то и статистика, что терпит погрешности. Чем больше данных, тем рже можно статистику обновлять. По умолчанию статистика обновляется при изменении какого процента строк, что приводит не к линейному росту затрат, а к логарифическом.
G>Для ОЧЕНЬ_БОЛЬШИХ таблиц во всех серьезных базах есть partitioning.

Я не про то как часто обновляется статистика, а про затраты на то чтоб ее подсчитать (и про точность подсчета).

VC>>Изначально SQL был сделан максимально дружелюбным для пользователя, чтобы им могли пользоваться не-программисты. Ну и проблемы растут в основном из этого.
G>Какую альтернативу предлагаете?

Альтернативный API, позволяющий использовать движок БД напрямую минуя оптимизатор.

VC>>Если же отойти от этой проблемы, принципиально нет причин по которым РСУБД (на уровне движка) не могли бы масштабироваться не хуже чем NoSQL. Наделать кучу шардов дурное дело нехитрое.
VC>>Поддерживать согласованность данных в разных шардах все равно потребуется какими-то внешними способами (как в случае NoSQL так и РСУБД). Плюс в случае РСУБД у тебя есть дополнительный бонус транзакционности на уровне одного шарда.
G>А чем SQL мешает делать шарды?

Да не мешает SQL делать шарды. Проблемы с SQL это про другое.

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

VC>Обоснование ниже, про статистику и автоматизированный выбор оптимальных планов выполнения.

И что мешает тебе пользоваться хинтами, если уж ты считаешь что справишься лучше оптимизатора?

VC>Что сильно увеличивает стоимость поддержки всего этого.

А рукопашный запил любых запросов к несиквелю не увеличивает?

VC> Ни одна из известных мне РСУБД не предоставляет удовлетворительных способов решения этой проблемы.

А несиквели предоставляют?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, SkyDance, Вы писали:

SD>>Давайте по-простому: есть таблица accounts, где, ну, пусть 3 миллиарда записей (причем активных больше половины).

НС>У тебя реально четверть населения планеты — активные аккаунты? Если реально — это крайне особенный кейс, таких на этом шарике — по пальцам одной руки, и решения из этого кейса в принципе нет смысла тиражировать.

Такой случай может быть и редкий (с миллиардами аккаунтов), но случаев где количество уникальных записей других типов примерно такого же порядка (миллиарды — десятки миллиардов) будет побольше.
У нас например случай такой, что количество записей раз в 10 поменьше (сотни миллионов), но количество связей и их сложность заметно побольше. А это составляет бОльшую проблему чем количество записей. И удовлетворительных решений "из коробки" для подобных случаев не существует .

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

VC>У нас например случай такой, что количество записей раз в 10 поменьше (сотни миллионов)

И с такими объемами справляются вполне рядовые РСУБД.

VC>И удовлетворительных решений "из коробки" для подобных случаев не существует .

И? При чем тут несиквели?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

VC>>Обоснование ниже, про статистику и автоматизированный выбор оптимальных планов выполнения.
НС>И что мешает тебе пользоваться хинтами, если уж ты считаешь что справишься лучше оптимизатора?

Хинты это костыль который к тому же не всегда работает как надо.

VC>>Что сильно увеличивает стоимость поддержки всего этого.
НС>А рукопашный запил любых запросов к несиквелю не увеличивает?

Увеличивает конечно. Нужна более гибкая система, которая позволяет и автоматизацию
и нормальное (а не через ж как в случае с хинтами) задание алгоритма выполнения.

VC>> Ни одна из известных мне РСУБД не предоставляет удовлетворительных способов решения этой проблемы.
НС>А несиквели предоставляют?

Некоторые предоставляют. Грубо говоря, берешь эффективный key-value storage и пилишь все остальное поверх него .
Включая вторичные индексы, транзакции (в том числе распределенные) и т.п.
Это была шутка, но не на 100%, некоторые именно так и поступают.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

VC>>У нас например случай такой, что количество записей раз в 10 поменьше (сотни миллионов)

НС>И с такими объемами справляются вполне рядовые РСУБД.

Справляются они с какими угодно объемами, вопрос в том насколько хорошо они с этими объемами справляются.

VC>>И удовлетворительных решений "из коробки" для подобных случаев не существует .

НС>И? При чем тут несиквели?

Ась? Я вообще что-то говорил про несиквели?

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

VC>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>Здравствуйте, VladiCh, Вы писали:

VC>>>У нас например случай такой, что количество записей раз в 10 поменьше (сотни миллионов)

НС>>И с такими объемами справляются вполне рядовые РСУБД.

VC>Справляются они с какими угодно объемами, вопрос в том насколько хорошо они с этими объемами справляются.

Если непонятно о чем я — я о сервисах у которых p99 на запрос в единицы миллисекунд. У РСУБД из-за невозможности сбора точной статистики большая проблема с "хвостом" запросов.
И в среднем все может работать более-менее кое-как, но p99 или упаси боже p999 будет плохим.

НС>Мне зачем об этом знать?

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

Gt_>>даже если бы они все антипатерны собрали и писали бы в один документ данные со всех заказов, даже так было бы сложновато слечь на нескольких мб данных, что дали бы 100 заказов в день.

НС>Не, они накосячили с самопальной очередью

зачем мне это знать ? это было очевидно и без этих оправданий. плюс очевидно, что с такой логикой azure sql дохнет много быстрее. и не потому что плохой инструмент, а потому что пытается обеспечить много больше консистентности, транзакционности.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

VC>>Умеет, умеет. Разные вещи параллелятся — индекс сканы, джойны, аггрегации.

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

не будет. традиционные субд просто свалят все на одну ноду и тот же джоин будут тошнить вечность. что бы получить хоть какую-то параллельность из рсубд делают MPP варианты, если говорить о postgres, то из него сделали Greenplum

Gt_>>выполнение одного кверика толком не умеет параллелить. лишь при чтении с партицированных таблиц при условии, что там совпадет тучи условий, на фоне спарк можно считать, что не парраллеит вовсе.

VC>Умеет, умеет. Разные вещи параллелятся — индекс сканы, джойны, аггрегации. Количество воркеров настраиваемое. Может вы просто не умеете это готовить?
VC>https://www.postgresql.org/docs/current/parallel-plans.html

речь то не обо мне, вот чуваки на примере TPC-H поазывают postgres 14.4 тошнит часами в одном потоке
https://www.youtube.com/watch?v=lww3wuEOr5w&2m:05s

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


Gt_>>>выполнение одного кверика толком не умеет параллелить. лишь при чтении с партицированных таблиц при условии, что там совпадет тучи условий, на фоне спарк можно считать, что не парраллеит вовсе.

VC>>Умеет, умеет. Разные вещи параллелятся — индекс сканы, джойны, аггрегации. Количество воркеров настраиваемое. Может вы просто не умеете это готовить?
VC>>https://www.postgresql.org/docs/current/parallel-plans.html

Gt_>речь то не обо мне, вот чуваки на примере TPC-H поазывают postgres 14.4 тошнит часами в одном потоке
Gt_>https://www.youtube.com/watch?v=lww3wuEOr5w&2m:05s

Это те самые чуваки которые пытаются доказать что их зеленая слива кому-то нужна?
Ну я тоже могу настроить постгрес так что он будет тошнить в одном потоке .

НС>У тебя реально четверть населения планеты — активные аккаунты?

Ага. Даже чуть больше

НС>Если реально — это крайне особенный кейс, таких на этом шарике — по пальцам одной руки, и решения из этого кейса в принципе нет смысла тиражировать.

Иногда нужно, если подумать о том, что у одного человека ("население планеты") может быть много активных устройств. Например, "умный дом" может влегкую насчитывать более сотни устройств. Но вот там действительно можно шардировать (потому что устройства одного аккаунта не связываются с устройствами другого).

VC>Но это такое лоскутное одеяло которое многими людьми делалось — кое где все классно, а кое где надо бы выкинуть и переписать заново.
VC>Издержки опен сорса.

Дело совсем не в этом, а именно в масштабе — распределенные РСУБД действительно сложная задача, вне зависимости от легаси или отсутствия такового.

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

VC>>Но это такое лоскутное одеяло которое многими людьми делалось — кое где все классно, а кое где надо бы выкинуть и переписать заново.
VC>>Издержки опен сорса.

SD>Дело совсем не в этом, а именно в масштабе — распределенные РСУБД действительно сложная задача, вне зависимости от легаси или отсутствия такового.

Ты посмотри хоть на что я отвечал. Я тут не про распределенные РСУБД говорил вообще-то. Да и постгрес никаким местом не распределенная РСУБД.

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

НС>>И что мешает тебе пользоваться хинтами, если уж ты считаешь что справишься лучше оптимизатора?
VC>Хинты это костыль

Ну ты же хочешь порулить оптимизатором? Вполне адекватный инструмент для этого. А костыль/не костыль — это эмоциональная характеристика.

VC> который к тому же не всегда работает как надо.

Например?

VC>>>Что сильно увеличивает стоимость поддержки всего этого.
НС>>А рукопашный запил любых запросов к несиквелю не увеличивает?
VC>Увеличивает конечно.

Ну то есть это не недостаток РСУБД как класса, это проблема любых СУБД в принципе.

VC> Нужна более гибкая система, которая позволяет и автоматизацию и нормальное (а не через ж как в случае с хинтами) задание алгоритма выполнения.

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

VC>>> Ни одна из известных мне РСУБД не предоставляет удовлетворительных способов решения этой проблемы.
НС>>А несиквели предоставляют?
VC>Некоторые предоставляют. Грубо говоря, берешь эффективный key-value storage и пилишь все остальное поверх него .

Т.е. работаешь вместо оптимизатора. Никакого принципиального отличия от хинтов в sql нет.

VC>Это была шутка, но не на 100%, некоторые именно так и поступают.

Что то кроме этой шутки я никакого другого смысла в твоих возражениях не вижу.

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

НС>>И с такими объемами справляются вполне рядовые РСУБД.
VC>Справляются они с какими угодно объемами, вопрос в том насколько хорошо они с этими объемами справляются.

Не хуже несиквелей. Несиквели становятся интересны, когда нагрузка не влазит в 1-2 ноды и нужен шардинг. Шардинг в РСУБД это весьма непростая штука, с несиквелями проще и больше вариантов искаропки.
Ну и еще один вариант — большинство несиквелей существенно дешевле РСУБД. Но это большинство, топовые по перфу варианты тоже стоят по конски. А вот какой нибудь экстрадешевый сторадж с огромными объемами, но без супертребований к перфу — тут на текущем этапе несиквели рулят. Либо наоборот, когда объемы небольшие, но супержесткие требования по латентности — ACID и его обертки в РСУБД, даже если собственно ACID отрубить, все равно дают очень серьезные задержки.

VC>>>И удовлетворительных решений "из коробки" для подобных случаев не существует .
НС>>И? При чем тут несиквели?
VC>Ась? Я вообще что-то говорил про несиквели?

Тут весь тред про них вообще то.

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

SD>Иногда нужно, если подумать о том, что у одного человека ("население планеты") может быть много активных устройств.

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

SD> Например, "умный дом" может влегкую насчитывать более сотни устройств.

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

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

НС>>Да и шардинг никто не отменял, а в нем то уж точно все параллельно будет. А все эти несиквелы в основном за счет шардинга и параллелятся.
Gt_>не будет. традиционные субд просто свалят все на одну ноду

При включенном шардинге? Как мало ты знаешь про РСУБД.

Gt_>и тот же джоин будут тошнить вечность.

А на несиквеле у тебя вообще возможности джойна не будет, или это будет не джойн а некая вариация map-reduce, что, мягко говоря, совсем не тоже самое.

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

SD>Дело совсем не в этом, а именно в масштабе — распределенные РСУБД действительно сложная задача

Распределенные несиквели, что характерно, тоже. И сложности и там и там начинаются, когда ты не можешь обойтись без связей между нодами. А если можешь — и на РСУБД решения будут относительно простыми.

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

НС>>Мне зачем об этом знать?
Gt_>что бы понимал, как смешно выглядел когда пытался рассказать, что "А старый проект, гонявший примерно тех же заказов ... почему то пахал без проблем."

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

Gt_>>>даже если бы они все антипатерны собрали и писали бы в один документ данные со всех заказов, даже так было бы сложновато слечь на нескольких мб данных, что дали бы 100 заказов в день.
НС>>Не, они накосячили с самопальной очередью
Gt_>зачем мне это знать ?

Это была иллюстрация того самого примера, когда тащат несиквели не потому что они обладают конкретными для конкретного проекта плюсами, а только потому что это модно и молодежно.
И ты тут занимаешься ровно тем же — не зная вообще никакой специфики конкретного проекта сразу отметаешь вариант постгри. В результате и рождаются проекты, которые по нагрузке могут вообще без БД обходиться, одним каким нибудь S3, но в них впендюривают полдесятка нод какого нибудь несиквела.

Gt_>плюс очевидно, что с такой логикой azure sql дохнет много быстрее.

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

Gt_> и не потому что плохой инструмент

Про плохие инструменты тут написал только ты. Любой инструмент имеет свои плюсы и свои минусы. И раз постгри до сих пор очень популярное решение — значит есть ситуации, когда плюсы перевешивают минусы.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

НС>>>И с такими объемами справляются вполне рядовые РСУБД.
VC>>Справляются они с какими угодно объемами, вопрос в том насколько хорошо они с этими объемами справляются.

НС>Не хуже несиквелей. Несиквели становятся интересны, когда нагрузка не влазит в 1-2 ноды и нужен шардинг. Шардинг в РСУБД это весьма непростая штука, с несиквелями проще и больше вариантов искаропки.
НС>Ну и еще один вариант — большинство несиквелей существенно дешевле РСУБД. Но это большинство, топовые по перфу варианты тоже стоят по конски. А вот какой нибудь экстрадешевый сторадж с огромными объемами, но без супертребований к перфу — тут на текущем этапе несиквели рулят. Либо наоборот, когда объемы небольшие, но супержесткие требования по латентности — ACID и его обертки в РСУБД, даже если собственно ACID отрубить, все равно дают очень серьезные задержки.

VC>>>>И удовлетворительных решений "из коробки" для подобных случаев не существует .
НС>>>И? При чем тут несиквели?
VC>>Ась? Я вообще что-то говорил про несиквели?

НС>Тут весь тред про них вообще то.

Тред начинался про графовые базы и сравнение имплементации графовых алгоритмов на РСУБД и специализированных баз.
Но мы уже совсем другое тут обсуждаем. Я в частности говорил о том, что РСУБД это слишком общий инструмент который "из коробки" не работает хорошо
для специализированных применений. Как то, низкая латентность, большой объем, сложные структуры данных + большой объем и/или низкая латентность.
Причины я выше приводил. Он заточен под некий "общий случай" и простоту использования. Графовые алгоритмы не являются таким "общим случаем".
Допилить движок РСУБД под них можно (если сам движок позволяет), но прямо из коробки делать на чистом SQL это идея так себе.
Опять же, ничего невозможного нет и используя хинты (где они есть), сохраненные планы (где они есть) и другие пляски с бубнами наверное можно заставить это работать.
Про NoSQL решения в этой области я и не упоминал вообще. А ты мне кажется уехал в обсуждении совсем общих соображений NoSQL vs SQL.

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

VC>Но мы уже совсем другое тут обсуждаем. Я в частности говорил о том, что РСУБД это слишком общий инструмент который "из коробки" не работает хорошо
VC>для специализированных применений.

Ты начал скруглять углы. Изначально у тебя было куда более категорично:

РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия.

А в новой формулировке никто, думаю, возражать не будет.

P>Полгода практики в чистом виде никогда не бывает:
P>Во первых, всегда есть митинги, они отнимают существенную долю времени.
P>Во вторых, есть куча багфикса-отладки-тестов коего процентов 80% от всего подряд и с бд там будет какая ни будь мелочевка в основной массе, т.к. всё это связано с огромным количеством коммуникации — уточнить, спросить, обсудить, проверить, написать тест, пофиксить одну строчку, и так по кругу.
P>В третьих, куча работы связаной с билдами, локальным окружением, инфраструктурой и тд
P>И задачи по проекту далеко не всегда включают в себя БД, особенно, если спецализаци — фуллстек, что сейчас крайне популярно
P>Кроме того, знание домена никто не отменял, оно намного более важно чем бд и вообще все технологии взятые в одном проекте разом

P>Итого — эти полгода придется набирать урывками и года за три-четыре люди обычно справляются. Но штука в том, что через эти три-четыре года митингов станет больше, а возможно прибавятся и менеджерские обязанности. Итого — если у нас не чистый бакенд, коих очень мало, то шансы освоить рсубд вообще говоря минимальны. Что и наблюдаем.

Позвольте, а как же эти изумительные существе изначально попали "служить в очистку" без базовых знаний? Понаберут неучей, а потом им времени развиваться, видите ли, нет. Тьпху!

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

P>>Итого — эти полгода придется набирать урывками и года за три-четыре люди обычно справляются. Но штука в том, что через эти три-четыре года митингов станет больше, а возможно прибавятся и менеджерские обязанности. Итого — если у нас не чистый бакенд, коих очень мало, то шансы освоить рсубд вообще говоря минимальны. Что и наблюдаем.

ZZ>Позвольте, а как же эти изумительные существе изначально попали "служить в очистку" без базовых знаний? Понаберут неучей, а потом им времени развиваться, видите ли, нет. Тьпху!

Ранок перегрет, уже больше двух десятков лет. Соответсвенно отрасль наполняется необученым контингентом. Это одна из болезней быстрого роста в любой индустрии.
Этот необученый контингент постепенно дообучается, но на это требуется время и тд. Следствия
1. фундаментальных знаний у большинства нет, соответственно, спрос на упрощенные инструменты
2. разделение труда полным ходом
3. рост зп сначала замедляется, а потом уравновесится в какой то зоне, подозреваю, ниже нынешней. И дальше будет качественный рост контингента.

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

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

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


VC>>>РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия. Не на уровне ядра РСУБД малосовместимые, а на уровне интерфейса (SQL).
VC>>>SQL — это декларативный интерфейс, когда оптимизатор сам решает как именно выполнять конкретный запрос. К сожалению, ни одна существующая реализация оптимизатора не выполняет эту работу сколько-нибудь эффективно для больших данных
G>>Громкое заявление, обоснование будет?
G>>Какие альтернативы предлагаете?


VC>Альтернатива — все правильно, partitioning (для снижения размера отдельных таблиц) + ручное управление планами выполнения.
Это не альтернатива SQL, а его часть. Может вы о каком-то другом partitioning говорите?

VC>Что сильно увеличивает стоимость поддержки всего этого.
По сравнению с чем? В любом случае затраты (как CPU и RAM, так и трудочасов) растут как минимум логарифмически от объема данных. РСУБД и язык SQL для достаточно больших объемов (примерно когда объем данных превышает объем доступной ОП в 1000 раз) сохраняет этот логарифмический рост во многих сценариях.

VC>Ни одна из известных мне РСУБД не предоставляет удовлетворительных способов решения этой проблемы. Как правило при росте объемов данных и сложности запросов, планы выполнения начинают плавать и начинается вуду с их оптимизацией на основе различных хинтов и т.п. Вообще говоря, не любую схему данных можно эффективно партиционировать или шардить.
Вы опять повторяете утверждение, но не обосновываете его.

VC>Как предлагаете работать с теми, которые не поддаются этому?
Как вы предлагаете шардить, то что плохо шардится? Примените те же самые методы к любой SQL-базе данных.


VC>>>(стоимость поддержки актуальной статистики оптимизатора растет линейно с ростом размера данных и есть подозрение что это вообще невозможно для достаточно больших баз данных).
G>>Статистика на то и статистика, что терпит погрешности. Чем больше данных, тем рже можно статистику обновлять. По умолчанию статистика обновляется при изменении какого процента строк, что приводит не к линейному росту затрат, а к логарифическом.
G>>Для ОЧЕНЬ_БОЛЬШИХ таблиц во всех серьезных базах есть partitioning.
VC>Я не про то как часто обновляется статистика, а про затраты на то чтоб ее подсчитать (и про точность подсчета).
Затраты чтобы посчитать статистику — скан таблицы. Современные SSD читают гигабайт в секунду. Если таблица данных настолько большая, что обновление статистики выполняется дольше, чем интервал неактивности, то используют партиционирование, чтобы сканить не всю таблицу, а только одну партицию.
Точность подсчета — неясно что вы имеете ввиду. Статистика хранит кортежи (граница диапазона, количество строк в диапазоне, количество уникальных значений в диапазоне). Это позволяет получить достаточно точную оценку селективности запросов по индексу на равенство и диапазон значений. Проблема может быть только в том случае если у вас индекс по нескольким полям, и селективность высокая по совокупности, но низкая по любому подмножеству. Но это решаемо созданием вычисляемого поля и индексированием его.

VC>>>Изначально SQL был сделан максимально дружелюбным для пользователя, чтобы им могли пользоваться не-программисты. Ну и проблемы растут в основном из этого.
G>>Какую альтернативу предлагаете?
VC>Альтернативный API, позволяющий использовать движок БД напрямую минуя оптимизатор.
Что вы имеете ввиду под "движком БД" ? Обращение напрямую к хранимым b-tree? Что вам это даст? вы же все равно начнете писать свой оптимизатор, чтобы выбирать стратегию обхода и из какого индекса читать данные.
Если вас интересует просто key-value, то их полно и сейчас, но что-то не видно бешеной популярности.

VC>Да не мешает SQL делать шарды. Проблемы с SQL это про другое.
Про что? Я так и не понял.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

VC>>Но мы уже совсем другое тут обсуждаем. Я в частности говорил о том, что РСУБД это слишком общий инструмент который "из коробки" не работает хорошо
VC>>для специализированных применений.

НС>Ты начал скруглять углы. Изначально у тебя было куда более категорично:
НС>

НС>РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия.

НС>А в новой формулировке никто, думаю, возражать не будет.

Я от слов выше не отказываюсь. Ну ok, может быть та формулировка была чересчур категоричная. Но только совсем немного ...
Как я написал выше, проблема у РСУБД в tail latency. Что для "высокопроизводительных сервисов" в моем понимании создает большие сложности.
Может ли считаться сервис "высокопроизводительным" если у него p99 в 50 раз выше чем p50?

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

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


VC>>Альтернатива — все правильно, partitioning (для снижения размера отдельных таблиц) + ручное управление планами выполнения.
G>Это не альтернатива SQL, а его часть. Может вы о каком-то другом partitioning говорите?

Слово "альтернатива" предложили вы. Ok, назовем это "способ уменьшить влияние этой проблемы".

VC>>Что сильно увеличивает стоимость поддержки всего этого.
G>По сравнению с чем? В любом случае затраты (как CPU и RAM, так и трудочасов) растут как минимум логарифмически от объема данных. РСУБД и язык SQL для достаточно больших объемов (примерно когда объем данных превышает объем доступной ОП в 1000 раз) сохраняет этот логарифмический рост во многих сценариях.

VC>>Ни одна из известных мне РСУБД не предоставляет удовлетворительных способов решения этой проблемы. Как правило при росте объемов данных и сложности запросов, планы выполнения начинают плавать и начинается вуду с их оптимизацией на основе различных хинтов и т.п. Вообще говоря, не любую схему данных можно эффективно партиционировать или шардить.
G>Вы опять повторяете утверждение, но не обосновываете его.

Для какого именно высказывания вы требуете обоснования? Для первого? Это, как говорится, личный опыт. Вам достаточно привести один обратный пример чтобы это опровергнуть.
Но не каждый личный опыт подойдет. Я в курсе что в большинстве случаев статистика работает удовлетворительно — не везде требуется низкая латентность, не везде комбинация размера базы данных и сложности запросов такова что начинают проявляться проблемы.

VC>>Как предлагаете работать с теми, которые не поддаются этому?
G>Как вы предлагаете шардить, то что плохо шардится? Примените те же самые методы к любой SQL-базе данных.

Я не предлагаю шардить то что плохо шардится. Я утверждаю что "шардинг" или "партишенинг" как средство решения проблем РСУБД не всегда работает.
То есть должны существовать другие средства решения этих проблем для случаев когда они не работают.

VC>>>>(стоимость поддержки актуальной статистики оптимизатора растет линейно с ростом размера данных и есть подозрение что это вообще невозможно для достаточно больших баз данных).
G>>>Статистика на то и статистика, что терпит погрешности. Чем больше данных, тем рже можно статистику обновлять. По умолчанию статистика обновляется при изменении какого процента строк, что приводит не к линейному росту затрат, а к логарифическом.
G>>>Для ОЧЕНЬ_БОЛЬШИХ таблиц во всех серьезных базах есть partitioning.

см выше.

VC>>Я не про то как часто обновляется статистика, а про затраты на то чтоб ее подсчитать (и про точность подсчета).
G>Затраты чтобы посчитать статистику — скан таблицы. Современные SSD читают гигабайт в секунду. Если таблица данных настолько большая, что обновление статистики выполняется дольше, чем интервал неактивности, то используют партиционирование, чтобы сканить не всю таблицу, а только одну партицию.
G>Точность подсчета — неясно что вы имеете ввиду. Статистика хранит кортежи (граница диапазона, количество строк в диапазоне, количество уникальных значений в диапазоне). Это позволяет получить достаточно точную оценку селективности запросов по индексу на равенство и диапазон значений. Проблема может быть только в том случае если у вас индекс по нескольким полям, и селективность высокая по совокупности, но низкая по любому подмножеству. Но это решаемо созданием вычисляемого поля и индексированием его.

Пример из постгреса (в других базах может быть по другому, но я сомневаюсь что где-то считается полная статистика).
Постгрес подсчитывает статистику используя random sampling таблиц, причем размер этого sample очень небольшой по сравнению с размерами таблиц для больших баз.
Из-за этого статистика получается кривая и планы выполнения плавают после каждого подсчета статистики.
Сканировать полностью все таблицы для этого и делать это регулярно — ну это такое... В куче случаев (при частом обновлении больших таблиц) это просто невозможно, или база будет большую часть времени только статистику считать. Подсчет при каждом изменении сильно снижает производительность на запись.
А если чего-то из этого не делать, точность будет страдать и tail latency увеличиваться.

VC>>>>Изначально SQL был сделан максимально дружелюбным для пользователя, чтобы им могли пользоваться не-программисты. Ну и проблемы растут в основном из этого.
G>>>Какую альтернативу предлагаете?
VC>>Альтернативный API, позволяющий использовать движок БД напрямую минуя оптимизатор.
G>Что вы имеете ввиду под "движком БД" ? Обращение напрямую к хранимым b-tree? Что вам это даст? вы же все равно начнете писать свой оптимизатор, чтобы выбирать стратегию обхода и из какого индекса читать данные.

В куче случаев схема данных меняется ну очень редко. Поэтому один раз написанный план выполнения может быть фиксирован на длительное время. Хотя бы возможность этого должна иметься.
В некоторых РСУБД есть некие зачатки этого (возможность сохранять и переиспользовать планы, использовать хинты), но нормальной целостной системы я не видел нигде.

G>Если вас интересует просто key-value, то их полно и сейчас, но что-то не видно бешеной популярности.

не интересуют.

VC>>Да не мешает SQL делать шарды. Проблемы с SQL это про другое.
G>Про что? Я так и не понял.

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

за 20 лет тут я посмеялся ни над одним поколениям местечковых дяденек, могу себе позволить. в 2003 они тут стадом вокруг блокировочников все бегали, смешные. извини, но я сходу виду дилетантов, что на ходу сочиняют не понимая как смешно эти ужимки выглядят. еще раз, ты насочинял о 100 заказах в день, т.е. даже за пару лет это речь о мегабайтах. и теперь ты уверяешь что кто-то пошел разворачивать 5 нод неважно чего ради мегабайтов ?
это смешно, правда не ново для рсдн.


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

да, и могу еще раз подтвердить в задаче "а у нас же тоже очень много данных (аж целый миллион записей)" постгрес нафиг не нужен, особливо в контексте

F>Или такой еще вариант. В Гугле или Яндексе сталкиваются с проблемой обработки своих охренилиардов данных, применяют какую-то нестандартную БД, потом пишут про это статью "применение Х при обработке больших объемов данных".

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

VC>Как я написал выше, проблема у РСУБД в tail latency.

А это точно проблема для любых высокопроизводительных сервисов? Уверен?
Обычно сверхнизкая латентность если и нужна, то в небольшом количестве запросов, и она почти всегда неплохо лечится тем же редисом. Трахатся с несиквелами в остальных 100500 запросах ради десятка критичных — не самое разумное решение.

VC>Может ли считаться сервис "высокопроизводительным" если у него p99 в 50 раз выше чем p50?

Это тут вообще при чем?

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

Gt_>да, и могу еще раз подтвердить в задаче "а у нас же тоже очень много данных (аж целый миллион записей)" постгрес нафиг не нужен, особливо в контексте

Да сколько угодно. Но хоть сколько нибудь аргументированным твое заявление от повторения не становится. Типичная "халва, халва".

Здравствуйте, Ночной Смотрящий, Вы писали:

VC>>Как я написал выше, проблема у РСУБД в tail latency.

НС>А это точно проблема для любых высокопроизводительных сервисов? Уверен?
НС>Обычно сверхнизкая латентность если и нужна, то в небольшом количестве запросов, и она почти всегда неплохо лечится тем же редисом.

А общая производительность системы не страдает, когда проваливается tail latency? Это же влияет на все юзерские запросы что инициируют цепочку запросов к бд.

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

P>Ранок перегрет, уже больше двух десятков лет. Соответсвенно отрасль наполняется необученым контингентом. Это одна из болезней быстрого роста в любой индустрии.
P>Этот необученый контингент постепенно дообучается, но на это требуется время и тд. Следствия
P>1. фундаментальных знаний у большинства нет, соответственно, спрос на упрощенные инструменты
P>2. разделение труда полным ходом
P>3. рост зп сначала замедляется, а потом уравновесится в какой то зоне, подозреваю, ниже нынешней. И дальше будет качественный рост контингента.

Рынок перегрет не зарплатами, а излишне завышенными ожиданиями к скорости исполнения задач. Прекращение роста ЗП будет означать, что за ту же ЗП людей будут грузить ещё большим количеством задач, и учиться они станут ещё меньше. Тут надо не программистов ругать, а бить в лоб слишком резво несущийся вперёд бизнес, чтобы не бизнесовали столь споро.

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

С>Рынок перегрет не зарплатами, а излишне завышенными ожиданиями к скорости исполнения задач.

Это не сильно принципиально, что именно греет рынок. Раз он перегрет, то естественным образом туда дрефует необученный контингент. Останавливающих механизмов ведь нет, типа лицензирование и тд.

> Прекращение роста ЗП будет означать, что за ту же ЗП людей будут грузить ещё большим количеством задач, и учиться они станут ещё меньше. Тут надо не программистов ругать, а бить в лоб слишком резво несущийся вперёд бизнес, чтобы не бизнесовали столь споро.

Бизнес сам решает, бежать ему или стоять. Рост ЗП прекратится только в том случае, если будет достаточное количестов заместителей/заменителей.

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

P>Это не сильно принципиально, что именно греет рынок. Раз он перегрет, то естественным образом туда дрефует необученный контингент. Останавливающих механизмов ведь нет, типа лицензирование и тд.

ПИК с Мортоном имеют лицензии, а посмотрите-ка, что они строят

P>Бизнес сам решает, бежать ему или стоять. Рост ЗП прекратится только в том случае, если будет достаточное количестов заместителей/заменителей.

Пока что сам решает.

Вы не понимаете. Если на обучение у работников нет времени, то его не появится, пока оно явно не будет выделено работодателем. И сам по себе он вряд ли это сделает. Бывают конечно идеалисты, но не в нынешнем мире.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

VC>>Как я написал выше, проблема у РСУБД в tail latency.

НС>А это точно проблема для любых высокопроизводительных сервисов? Уверен?
НС>Обычно сверхнизкая латентность если и нужна, то в небольшом количестве запросов, и она почти всегда неплохо лечится тем же редисом. Трахатся с несиквелами в остальных 100500 запросах ради десятка критичных — не самое разумное решение.

Еще раз, речь здесь не про "трахаться с несиквелами".
Существующие движки РСУБД вполне способны выдавать нужные цифры, проблема не в них, а в нестабильном интерфейсе (SQL) навернутом сверху.

VC>>Может ли считаться сервис "высокопроизводительным" если у него p99 в 50 раз выше чем p50?

НС>Это тут вообще при чем?

Да все при том же. Про низкую latency, которую РСУБД "из коробки" не может толком обеспечить. И речь не о какой-то там сверхнизкой, а скажем до 10-20ms на запрос.
И нет, редис тут не поможет в общем случае.

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

P>Здравствуйте, Ночной Смотрящий, Вы писали:

VC>>>Как я написал выше, проблема у РСУБД в tail latency.

НС>>А это точно проблема для любых высокопроизводительных сервисов? Уверен?
НС>>Обычно сверхнизкая латентность если и нужна, то в небольшом количестве запросов, и она почти всегда неплохо лечится тем же редисом.

P>А общая производительность системы не страдает, когда проваливается tail latency? Это же влияет на все юзерские запросы что инициируют цепочку запросов к бд.

В каких-то граничных случаях может и страдать (когда tail latency в десятки раз хуже чем средняя).

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

С>Вы не понимаете. Если на обучение у работников нет времени, то его не появится, пока оно явно не будет выделено работодателем. И сам по себе он вряд ли это сделает. Бывают конечно идеалисты, но не в нынешнем мире.

Вся прокачка в основном в личное время

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

P>>А общая производительность системы не страдает, когда проваливается tail latency? Это же влияет на все юзерские запросы что инициируют цепочку запросов к бд.

VC>В каких-то граничных случаях может и страдать (когда tail latency в десятки раз хуже чем средняя).

Если общаяя производительность страдает только в граничных случаях, то вопрос яйца выеденного не стоит.
Вы то как раз на обратном настаиваете, утверждаете, что tail latency это большой недостаток у рдбмс

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

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

P>>>А общая производительность системы не страдает, когда проваливается tail latency? Это же влияет на все юзерские запросы что инициируют цепочку запросов к бд.

VC>>В каких-то граничных случаях может и страдать (когда tail latency в десятки раз хуже чем средняя).

P>Если общаяя производительность страдает только в граничных случаях, то вопрос яйца выеденного не стоит.
P>Вы то как раз на обратном настаиваете, утверждаете, что tail latency это большой недостаток у рдбмс

Общая производительность это еще не все. Вот есть у вас например сервис авторизации которому хоть убейся надо 10ms максимум выдавать на запрос.
Если будет выдавать больше то у кучи других сервисов от него зависящих latency будет страдать.
Даже при нормальной общей производительности это проблема плохо решаемая РСУБД.
Я просто не стал здесь категоричных заявлений делать. Понятно что если запросы в хвосте получаются тяжелыми, это может на общую производительность влиять,
но это наверное специфично для конкретного сервиса. Но сам факт плохой tail latency это не очень специфично для конкретных сервисов, это проблема
которая проявится при определенных объемах и сложности запросов на практически любом сервисе. Могу разве что сделать оговорку что если структура базы у вас простая
и простые запросы (простой / сложный тут тоже субъективно, но не будем туда углубляться пока), а также относительно небольшой объем базы, то проблем с РСУБД у вас скорее всего не будет.

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

P>>Вы то как раз на обратном настаиваете, утверждаете, что tail latency это большой недостаток у рдбмс

VC>Общая производительность это еще не все. Вот есть у вас например сервис авторизации которому хоть убейся надо 10ms максимум выдавать на запрос.
VC>Если будет выдавать больше то у кучи других сервисов от него зависящих latency будет страдать.

То есть, общая производительность системы страдает, раз зависимые сервысы начнут подтупливать. Разве не так?

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

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

P>>>Вы то как раз на обратном настаиваете, утверждаете, что tail latency это большой недостаток у рдбмс

VC>>Общая производительность это еще не все. Вот есть у вас например сервис авторизации которому хоть убейся надо 10ms максимум выдавать на запрос.
VC>>Если будет выдавать больше то у кучи других сервисов от него зависящих latency будет страдать.

P>То есть, общая производительность системы страдает, раз зависимые сервысы начнут подтупливать. Разве не так?

Давай определимся с понятием "общая производительность" для начала. Похоже мы говорим о разном.

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

С>>Вы не понимаете. Если на обучение у работников нет времени, то его не появится, пока оно явно не будет выделено работодателем. И сам по себе он вряд ли это сделает. Бывают конечно идеалисты, но не в нынешнем мире.
P>Вся прокачка в основном в личное время

Вы быть может помните такие понятия как "библиотечный день", "курсы повышения квалификации", "учеба без отрыва от производства" (и с отрывом).

То есть, в какой-то момент тут на территории 1/6 все рехнулись и решили, что у людей в сутках должно быть 48 часов, и в США происходит нечто похожее. Но я надеюсь, что все эти люди просто вымрут от излишней нагрузки и всё вернётся на круги своя.

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

Gt_>за 20 лет тут я посмеялся ни над одним поколениям местечковых дяденек, могу себе позволить. в 2003 они тут стадом вокруг блокировочников все бегали, смешные. извини, но я сходу виду дилетантов, что на ходу сочиняют не понимая как смешно эти ужимки выглядят.
Удивительно не это. Удивительно, что за 20 прошедших лет вы так и не добавили к своим посмехиваниям никаких аргументов.

Gt_>>за 20 лет тут я посмеялся ни над одним поколениям местечковых дяденек, могу себе позволить. в 2003 они тут стадом вокруг блокировочников все бегали, смешные. извини, но я сходу виду дилетантов, что на ходу сочиняют не понимая как смешно эти ужимки выглядят.
S>Удивительно не это. Удивительно, что за 20 прошедших лет вы так и не добавили к своим посмехиваниям никаких аргументов.

согласен, не добавлял. но меня извиняет тот факт, что аргументов озвученных еще в 2003 оказалось достаточно, что бы лагерь блокировочников полностью вымер и мсскл добавил версионность. видел у azure sql версионный RC уже по дефолту.

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

P>>То есть, общая производительность системы страдает, раз зависимые сервысы начнут подтупливать. Разве не так?

VC>Давай определимся с понятием "общая производительность" для начала. Похоже мы говорим о разном.

А вы про что именно говорите?

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

P>А общая производительность системы не страдает, когда проваливается tail latency?

Общая производительность — понятие очень растяжимое. Если ты под ней понимаешь throughput, то в большинстве случаев нет, не страдает. Если latency — страдает, но обычно на это влияет, как я уже писал, сравнительно небольшое количество запросов, которые можно кешировать.
И есть еще один момент. Латентность из-за оверхеда на специфику РСУБД — она фиксированная. Если у тебя запрос легкий — это на суммарную латентность влияет заметно. А вот если тяжелый — эту дополнительную латентность и в микроскоп не разглядеть.
Ну и самое главное — рассуждать о достаточности перформанса и узких местах сферической системы в вакууме — треш, угар и содомия. Это практически невозможно качественно предсказать заранее даже для примерно понятных систем. А если ты о них ничего вообще не знаешь — хиромантия будет точнее, чем такие предсказания. Поэтому местные любители категорично заявить о неприменимости сиквелей/несиквелей ничего кроме смеха не вызывают.

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

VC>Существующие движки РСУБД вполне способны выдавать нужные цифры, проблема не в них, а в нестабильном интерфейсе (SQL) навернутом сверху.

Это утверждение нуждается в доказательствах.

VC>>>Может ли считаться сервис "высокопроизводительным" если у него p99 в 50 раз выше чем p50?
НС>>Это тут вообще при чем?
VC>Да все при том же. Про низкую latency, которую РСУБД "из коробки" не может толком обеспечить.

И при чем тут разница между р50 и р99?

VC>И нет, редис тут не поможет в общем случае.

А в общем случае и не нужно.

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

G>Что вы имеете ввиду под "движком БД" ? Обращение напрямую к хранимым b-tree?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Он имеет в виду возможность зафиксировать план запроса. Хинты и возможность указать конкретный план его почему то не устраивают. Почему — он объяснить так и не смог, про хинты единственный аргумент был что это костыль (поченму костыль, опять же, ответа нет), а возможность зафиксировать план он просто проигнорировал.

А что значит "указать конткретный план" ? Есть какой пример простой?

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

P>А что значит "указать конткретный план" ?

https://learn.microsoft.com/en-us/sql/relational-databases/performance/apply-a-fixed-query-plan-to-a-plan-guide?view=sql-server-ver16

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

VC>Вот есть у вас например сервис авторизации которому хоть убейся надо 10ms максимум выдавать на запрос.

Откуда такое странное требование? Про что конкретно вообще речь? Про получение access токена? И зачем этой операции такой жесткий лимит по латентности?

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

С>Вы не понимаете. Если на обучение у работников нет времени, то его не появится, пока оно явно не будет выделено работодателем.

У тебя нет времени на обучение? МНе просто интересно — вот дают тебе задачу, которую ты не делал (обычно таких задач в нашей профессии 90%+) — ты не разбираешься и ломишься вперед на мины? Как это вообще может работать?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, gandjustas, Вы писали:

G>>Что вы имеете ввиду под "движком БД" ? Обращение напрямую к хранимым b-tree?

НС>Он имеет в виду возможность зафиксировать план запроса. Хинты и возможность указать конкретный план его почему то не устраивают. Почему — он объяснить так и не смог, про хинты единственный аргумент был что это костыль (поченму костыль, опять же, ответа нет), а возможность зафиксировать план он просто проигнорировал.

Не просто зафиксировать, а при необходимости написать нужный план. Зафиксировать тоже конечно помогает, постольку поскольку (если оптимизатор в принципе может сгенерировать то что тебе требуется).
Почему хинты костыль — ну потому что это далеко не во всех базах работает и в той с которой я работаю сейчас, это больше не работает чем работает.
Зафиксировать план — вообще не работает в самой базе, только в некоторых клаудных имплементациях (AWS Aurora Postgres например), но и там не без проблем.
Так что приводить это все в качестве примера того что работает для RDBMS в ообщем нельзя. Для каких-то конкретных имплементаций — возможно. Кстати, для каких?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

VC>>Вот есть у вас например сервис авторизации которому хоть убейся надо 10ms максимум выдавать на запрос.

НС>Откуда такое странное требование? Про что конкретно вообще речь? Про получение access токена? И зачем этой операции такой жесткий лимит по латентности?

Проверка прав доступа в rbac модели. Что в нем странного? У сервиса есть клиенты которым требуется минимальная латентность.
10ms это не супер низкая латентность в общем-то. Да и вообще вопрос не в этом. пусть будет даже 50ms.
Вопрос в том, что если на относительно большой базе съедет план выполнения (например джойн выполнится не тем методом что нужно или не в том порядке), про такую латентность можно будет забыть.
А случиться это может в условиях неполной статистики элементарно. Про фиксацию планов выполнения выше мы уже говорили и это проблему по большей части решает.
Но проблема эта общая для всего класса RDBMS, а решается только в каких-то очень частных случаях (ну и я не видел удовлетворительного решения пока, хотя допускаю что где-то оно есть, скорее всего в каких-то коммерческих RDBMS).

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

VC>>Существующие движки РСУБД вполне способны выдавать нужные цифры, проблема не в них, а в нестабильном интерфейсе (SQL) навернутом сверху.

НС>Это утверждение нуждается в доказательствах.

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

VC>>>>Может ли считаться сервис "высокопроизводительным" если у него p99 в 50 раз выше чем p50?
НС>>>Это тут вообще при чем?
VC>>Да все при том же. Про низкую latency, которую РСУБД "из коробки" не может толком обеспечить.

НС>И при чем тут разница между р50 и р99?

Она просто для иллюстрации того что tail latency страдает из-за неполной статистики.
Только и всего.

VC>>И нет, редис тут не поможет в общем случае.

НС>А в общем случае и не нужно.

Ну как же, ты ведь утверждаешь что (почти) любые проблемы с latency можно решить редисом.
Какие-то можно, какие-то нет. Чтоб утверждать что проблем нет, нужно чтобы кеширование решало их в общем случае. Что очевидно не так;

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

VC>Не просто зафиксировать, а при необходимости написать нужный план.

В случае mssql там xml. Есть желание — берешь и правишь/пишешь его руками. Ссылку как это сделать я рядом дал.

VC>Почему хинты костыль — ну потому что это далеко не во всех базах работает

Во всех взрослых — работает. А те, в которых не работает — в любом случае не про high load.

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

VC>Проверка прав доступа в rbac модели. Что в нем странного? У сервиса есть клиенты которым требуется минимальная латентность.

Если речь про row level security — эта задача на любом типе БД очень непростая. Если без привлечения объектов — там все прекрасно кешируется в редисе.

VC>Но проблема эта общая для всего класса RDBMS,

Не, тут другое. На основании своего частного случая с узкой задачей и строго конкретным типом СУБД (постгри, да?) с не очень удачным оптимизатором ты вывел обобщающее утверждение про весь класс РСУБД.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

VC>>Проверка прав доступа в rbac модели. Что в нем странного? У сервиса есть клиенты которым требуется минимальная латентность.

НС>Если речь про row level security — эта задача на любом типе БД очень непростая. Если без привлечения объектов — там все прекрасно кешируется в редисе.

Нет, не row level security. Частично проблему можно решить кэшированием, частично нет. Вдаваться в подробности конкретной задачи здесь нет особого смысла, не тот формат.

VC>>Но проблема эта общая для всего класса RDBMS,

НС>Не, тут другое. На основании своего частного случая с узкой задачей и строго конкретным типом СУБД (постгри, да?) с не очень удачным оптимизатором ты вывел обобщающее утверждение про весь класс РСУБД.

На этом типе задачи я столкнулся с ограничениями, и покопав глубже понял что ограничения эти довольно фундаментальные, и специфичные именно что для всего класса RDBMS.
Хотя проявляются не везде, тут я согласен. Чем больше объем данных и сложнее запросы тем больше вероятность что они проявятся.
В моем случае была комбинация нескольких факторов:
1. объем довольно приличный (несколько терабайт)
2. количество записей довольно приличное (в нескольких таблицах сотни миллионов записей)
3. запросы достаточно сложные с большим количество джойнов между таблицами.
4. требования к низкой латентности.
Каждая по отдельности это не проблема. Все вместе — проблема.
Но даже если каждая не проблема по отдельности, система с большим количеством данных рано или поздно сползет в ту сторону.
Чем сложнее запросы тем быстрее сползет. Хотя если запросы довольно простые то есть шанс что с этим никогда не познакомишься несмотря на объем данных.

У Postgres кстати довольно хороший оптимизатор, проблема не в нем. Проблема, еще раз, в том что поддержание статистики, на основе которой работает оптимизатор,
в актуальном (и полном) состоянии — это дорогостоящая задача в случая когда объем данных большой. MSSQL по умолчанию кажется с 1% данных собирает статистику? Как я посмотрел, в нем все же есть опция
считать ее по всему датасету, что конечно хорошо, но на больших базах никто этого не будет делать, потому что рано или поздно все прийдет к тому что база занимается только подсчетом статистики и больше ничем. А на неполной статистике оптимизатор начинает косячить случайным образом, и появляется та самая tail latency.
Будем считать что проблема в случае MSSQL решается тем, что можно самому написать план запроса и забить на статистику — это важный функционал в данном случае.
Насчет того что "все взрослые РСУБД это умеют" — это не так. Сохранять и повторно использовать умеют (Oracle например умеет точно), писать самому планы, насколько я знаю — нет.
Для Postgres есть расширения позволяющие использовать хинты и сохранять планы, но они довольно убогие, к сожалению. И некоторые из них проприетарные, работают только на AWS например.