Здравствуйте, 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 например.
Здравствуйте, VladiCh, Вы писали:
НС>>Если речь про row level security — эта задача на любом типе БД очень непростая. Если без привлечения объектов — там все прекрасно кешируется в редисе. VC>Нет, не row level security.
Тогда не вижу проблем. БД описывающая права на уровне операций обычно редко меняется и без проблем влазит в память.
VC>На этом типе задачи я столкнулся с ограничениями,
Как будто бывает иначе с каким то другим типом БД.
VC>У Postgres кстати довольно хороший оптимизатор,
Смотря с чем сравнивать. Если с большой тройкой — то крайне примитивный он. С другой стороны он, конечно, более предсказуем и ближе к тому что ты хочешь, чтобы часть работы приходилось делать за него.
VC>Для Postgres есть расширения позволяющие использовать хинты и сохранять планы, но они довольно убогие, к сожалению.
О чем я и говорил — проблема не в РСУБД, проблема конкретно в постгри.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, VladiCh, Вы писали:
НС>>>Если речь про row level security — эта задача на любом типе БД очень непростая. Если без привлечения объектов — там все прекрасно кешируется в редисе. VC>>Нет, не row level security.
НС>Тогда не вижу проблем. БД описывающая права на уровне операций обычно редко меняется и без проблем влазит в память.
Я же написал — RBAC — role based access control — на уровне объектов и операций над ними (описываемых ролями).
Нет, в память не влазит — сотни миллионов пользователей, миллионы организаций, десятки миллионов групп (группы существуют на уровне организаций, пользователи глобальны).
Количество объектов — тоже сотни миллионов (в будущем миллиарды). Количество прав — это пересечение между этими всеми сущностями (плюс еще роли, но их относительно мало).
Прав опять же сотни миллионов в данный момент, но в перспективе тоже будут миллиарды. Есть еще наследуемые права и прочие сложности, так что запросы получаются не самые простые.
Там довольно большая база и растет быстро.
VC>>На этом типе задачи я столкнулся с ограничениями,
НС>Как будто бывает иначе с каким то другим типом БД.
Ну если делать все вручную опять же, используя domain knowledge а не статистику оптимизатора, то все работает куда надежнее.
Удобства использования конечно меньше, но это не самое важное в подобных сервисах.
Соответственно более простые и дубовые базы данных могут в данном случае выигрывать.
VC>>У Postgres кстати довольно хороший оптимизатор,
НС>Смотря с чем сравнивать. Если с большой тройкой — то крайне примитивный он. С другой стороны он, конечно, более предсказуем и ближе к тому что ты хочешь, чтобы часть работы приходилось делать за него.
VC>>Для Postgres есть расширения позволяющие использовать хинты и сохранять планы, но они довольно убогие, к сожалению.
НС>О чем я и говорил — проблема не в РСУБД, проблема конкретно в постгри.
Они (хинты/сохранение планов) копируют функционал Оракла по большому счету, значит в Оракле примерно та же проблема существует.
Да и вообще, основная проблема то не в качестве инструментов, а в том что они вообще требуются.
Ну и если мы соглашаемся что проблема такая есть (для всего класса баз данных) и инструменты требуются, по хорошему они должны быть стандартизованы на уровне SQL.
Иначе в случае возникновения этих проблем их решения требуют использования какого-то вуду, причем для каждой СУБД своего.
Здравствуйте, VladiCh, Вы писали:
НС>>О чем я и говорил — проблема не в РСУБД, проблема конкретно в постгри. VC>Они (хинты/сохранение планов) копируют функционал Оракла по большому счету, значит в Оракле примерно та же проблема существует.
Это как а анекдоте: слышал я этого вашего Паваротти, мне Рабинович напел — фигня какая то.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, VladiCh, Вы писали:
НС>>>О чем я и говорил — проблема не в РСУБД, проблема конкретно в постгри. VC>>Они (хинты/сохранение планов) копируют функционал Оракла по большому счету, значит в Оракле примерно та же проблема существует.
НС>Это как а анекдоте: слышал я этого вашего Паваротти, мне Рабинович напел — фигня какая то.
Здравствуйте, VladiCh, Вы писали:
VC>То есть кое где кое как проблемы решить можно, но это все частные костыли для решения системной проблемы.
Ну то есть проблема решаема, но РСУБД не подходят из-за твоих психологических заморочек по поводу костылей, а потому РСУБД вообще не годятся для большой нагрузки. Ну ок, я тебя понял.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, VladiCh, Вы писали:
VC>>То есть кое где кое как проблемы решить можно, но это все частные костыли для решения системной проблемы.
НС>Ну то есть проблема решаема, но РСУБД не подходят из-за твоих психологических заморочек по поводу костылей, а потому РСУБД вообще не годятся для большой нагрузки. Ну ок, я тебя понял.
Да причем тут психологические заморочки?
Последний раз (потому что задолбалось уже повторять одно и то же):
1. Есть концептуальная проблема с RDBMS, так как они отдают приоритет удобству использования по отношению к гибкости.
Этот приоритет зафиксирован в стандарте SQL, который исключительно декларативен и не предполагает никакого ручного вмешательства в алгоритмы доступа к данным.
2. Эта концепция плохо работает в случаях которые я описывал выше — большой объем данных, сложные запросы, требования к низкой латентности.
3. Есть нестандартные способы решения этих проблем в некоторых (далеко не во всех) RDBMS. Их качество и возможности плавают.
Эти нестандартные возможности я и называю "костылями", потому что они не укладываются в концепцию декларативного доступа к данным и имплементируются каждым производителем как бог на душу положит.
Мои "психологические заморочки" тут вообще ни при чем.
Здравствуйте, Ночной Смотрящий, Вы писали:
VC>>Проверка прав доступа в rbac модели. Что в нем странного? У сервиса есть клиенты которым требуется минимальная латентность.
НС>Если речь про row level security — эта задача на любом типе БД очень непростая. Если без привлечения объектов — там все прекрасно кешируется в редисе.
А что значит "без привлечения объектов" и почему это может быть проблемой?
Здравствуйте, Pauel, Вы писали:
НС>>Если речь про row level security — эта задача на любом типе БД очень непростая. Если без привлечения объектов — там все прекрасно кешируется в редисе. P>А что значит "без привлечения объектов"
Когда права определяются только по типу операции, а не по ее параметрам.
P>и почему это может быть проблемой?
Объем данных принципиально другой и джойнов между ними больше. В общем случае задача до сих пор иногда непосильная, решают только с ухищрениями.
