Вот лично 100% согласен. С чего автор считает что умение сеньора ревьювит не поддается ИИ обучению ? Научился кодить, научится и ревьювить сначала плохо, потом лучше, со временем обойдет любые возможности любого сеньора. Смешно ей богу, это как раньше утверждали, что машина в шахматы не научится играть)
Ого, БД позиционирущая себя как OLAP выполнила быстрее аналитический запрос. А на параллельной OLTP нагрузке pg будет лучше, и без исследования можно сказать. Есть ли смысл таких изысканий ?
Главный шанс для отечественных игроков – использовать представившееся окно возможностей.
Интересно, какое окно возможностей нам тут представилось ? Полявилось достаточное количество сильных инженерных команд ? Глобальные рынки, рост экономики, инвестиции ?
Логично, может это и оправданно в вашем случае, поэтому и про объемы упомянул. Но в любом случае надо держать в голове , ваш подход - это пороховая бочка, которая к каждому(!) обращению добавляет index range scan по сути, и рано или поздно, это убъет производительность. Притом какой-нибудь самый важный и есс-но "жирный" по данным клиент - он будет ждать дольше всех.
Не знаю конечно ваши объемы , но если брать общий случай , то RLS, там где можно без него - это 100% ошибка проектирования. Если у вас реально логически клиенты никак не связаны, и могут быть помещены в отдельную бд , то так и надо делать, это гораздо лучше чем RLS. Keep it simple , bro ) Производительность , возможности масштабирования и настройки - все в 100 раз лучше. Легкие БД - в рамках одного инстанса , стали тяжелей - можно размазать на сколько нужно инстансов, на какую нужно инфру. Возможности масштабирования огромны.
В доке YDB в разделе backup and recovery по сути только dump. Как-то не вяжется отсутствие в доке транзационного бэкапа, понятного механизма обеспечения его консистентности и восстановления до последней транзации и карточный процессинг.
В ванильном pg и так есть инстумент для сбора extended stats ( в тч по отдельным колонкам ) : CREATE STATISTICS .... ON column_name ... Он не отработал ? Иначе не понятно зачем это тогда все.
Казалось, что может быть логичней, зачем платить килотонны баксов если есть бесплатный postgres, да еще и дока на русском. Но есть нюанс. Бесплатный ванильный postgres не совсем удовлетворяет требованиям карточного процессинга, да и в целом банкинга, по security прежде всего, но не только. Набрать разработчиков которые все это допилят, будут поддерживать а потом мигрануть АБД, карточный процеесинг - не факт что это дешевле, чем просто остаться на Oracle.
Я обратился к GPT, описав проблему и он мне подсказал "действенный 100%-й способ"...
Ну да ну да , кому нужна эта документация )
https://postgrespro.ru/docs/postgresql/17/ddl-partitioning Точно так же, если в секционированной таблице есть секция DEFAULT, рекомендуется создать ограничение CHECK, которое исключает ограничение секции, подлежащей присоединению. Если этого не сделать, то секция DEFAULT будет просканирована, чтобы убедиться, что она не содержит записей, которые должны быть расположены в присоединяемой секции.
Плюсую. Может у меня какое-то профессиональная деформация на оракле, но считаю что бэкапом транзакционной БД может считаться то, что позволяет восстановится на момент последней закомиченной транзакции (если не потеряны логи транзакций, конечно), оно же PITR по сути. И в доке pg_dump написано такое : Note, however, that except in simple cases, pg_dump is generally not the right choice for taking regular backups of production databases. Поэтому, сторго говоря, это не должно называться backup tool/инструмент резервного копирвания.
Это все определеяет - ни консистентного бэкапа, ни нормальных транзакций на уровне БД. Получается все гарантированно только внутри одного шарда. Это, скорей, массив разрозненных БД , с роутингом, не совсем шардирование.
Представьте: нужно обновить базу данных размером с небольшое озеро — целых 10 ТБ. Классические методы тут не работают.
Вот интересно какие классические методы тут не работают? Классический метод major апгрейдов - это pg_upgrade. Для больших объемов явно рекомендуется использовать ключ --link дабы избежать копирования файлов данных. Он тут не работает ? С какими непреодолимыми трудностями вы столкнулись ?
Очень интресная статья, спасибо. Ну вот не могу отделаться от мысли, что под такие задачи, как диск и почта, не лучше ли было выбрять более подходящую БД ? С шардингом, репликами, авто балансировкой нагрузки, автофайловером, все из коробки - ну ту же монгу(не к ночи будет помянута). К ShardDB прикрутить redis раз там на чтение в основном, который тоже хорошо масштабируется на чтение репликами. И получается уже стандарная инфра для проектов такого типа. Ну зачем идти в строгую реляционку ? Как-то много напильником допиливать, не финансы же все таки.
Нишу никто не займет, так как ниша БД оракл - это не хранилка, а БД + вся enterprise логика - миллионы строк кода. Пока это все переписывать, скорей тут ишак или падишах... А кто использует Оракл просто как хранилку, конечно съезжают, так как это изначально неверный выбор был, а не замещение Оракл, явно.
Однако в жизни можно ставить задачу не столь идеалистично.
Так я именно про это же. Человек задумывается над теоремой и понимает, что нужна реализация каких то конретных метрик. И вопросы про сферический мультимастер отпадают, так как наступает хоть какое-то начальное понимание о возможностях и ограничениях в реализации.
Когда у меня кто то спрашивает про мультимастер в PG, я обычно спрашиваю в ответ, что он знает о теореме CAP. Как правило оказываеться ничего, и отправляется читать википедию. Мне это неплохо экономит время.
Вот лично 100% согласен. С чего автор считает что умение сеньора ревьювит не поддается ИИ обучению ? Научился кодить, научится и ревьювить сначала плохо, потом лучше, со временем обойдет любые возможности любого сеньора.
Смешно ей богу, это как раньше утверждали, что машина в шахматы не научится играть)
Ого, БД позиционирущая себя как OLAP выполнила быстрее аналитический запрос. А на параллельной OLTP нагрузке pg будет лучше, и без исследования можно сказать.
Есть ли смысл таких изысканий ?
Интересно, какое окно возможностей нам тут представилось ? Полявилось достаточное количество сильных инженерных команд ? Глобальные рынки, рост экономики, инвестиции ?
Если у вас сам сервис постгрес в автозапуске на ноде с патрони , то сплит брейн был раньше, в голове админа.
Логично, может это и оправданно в вашем случае, поэтому и про объемы упомянул.
Но в любом случае надо держать в голове , ваш подход - это пороховая бочка, которая к каждому(!) обращению добавляет index range scan по сути, и рано или поздно, это убъет производительность. Притом какой-нибудь самый важный и есс-но "жирный" по данным клиент - он будет ждать дольше всех.
Не знаю конечно ваши объемы , но если брать общий случай , то RLS, там где можно без него - это 100% ошибка проектирования.
Если у вас реально логически клиенты никак не связаны, и могут быть помещены в отдельную бд , то так и надо делать, это гораздо лучше чем RLS. Keep it simple , bro )
Производительность , возможности масштабирования и настройки - все в 100 раз лучше.
Легкие БД - в рамках одного инстанса , стали тяжелей - можно размазать на сколько нужно инстансов, на какую нужно инфру. Возможности масштабирования огромны.
В доке YDB в разделе backup and recovery по сути только dump. Как-то не вяжется отсутствие в доке транзационного бэкапа, понятного механизма обеспечения его консистентности и восстановления до последней транзации и карточный процессинг.
В ванильном pg и так есть инстумент для сбора extended stats ( в тч по отдельным колонкам ) :
CREATE STATISTICS .... ON
column_name...Он не отработал ? Иначе не понятно зачем это тогда все.
Казалось, что может быть логичней, зачем платить килотонны баксов если есть бесплатный postgres, да еще и дока на русском.
Но есть нюанс.
Бесплатный ванильный postgres не совсем удовлетворяет требованиям карточного процессинга, да и в целом банкинга, по security прежде всего, но не только. Набрать разработчиков которые все это допилят, будут поддерживать а потом мигрануть АБД, карточный процеесинг - не факт что это дешевле, чем просто остаться на Oracle.
Ну да ну да , кому нужна эта документация )
https://postgrespro.ru/docs/postgresql/17/ddl-partitioning
Точно так же, если в секционированной таблице есть секция
DEFAULT, рекомендуется создать ограничениеCHECK, которое исключает ограничение секции, подлежащей присоединению. Если этого не сделать, то секцияDEFAULTбудет просканирована, чтобы убедиться, что она не содержит записей, которые должны быть расположены в присоединяемой секции.Плюсую.
Может у меня какое-то профессиональная деформация на оракле, но считаю что бэкапом транзакционной БД может считаться то, что позволяет восстановится на момент последней закомиченной транзакции (если не потеряны логи транзакций, конечно), оно же PITR по сути.
И в доке pg_dump написано такое :
Note, however, that except in simple cases, pg_dump is generally not the right choice for taking regular backups of production databases.
Поэтому, сторго говоря, это не должно называться backup tool/инструмент резервного копирвания.
Это все определеяет - ни консистентного бэкапа, ни нормальных транзакций на уровне БД. Получается все гарантированно только внутри одного шарда. Это, скорей, массив разрозненных БД , с роутингом, не совсем шардирование.
Я так и прочитал, если бы речь была про пик было бы "на".. Разве не так ?
Вот интересно какие классические методы тут не работают? Классический метод major апгрейдов - это pg_upgrade. Для больших объемов явно рекомендуется использовать ключ --link дабы избежать копирования файлов данных. Он тут не работает ? С какими непреодолимыми трудностями вы столкнулись ?
Очень интресная статья, спасибо.
Ну вот не могу отделаться от мысли, что под такие задачи, как диск и почта, не лучше ли было выбрять более подходящую БД ?
С шардингом, репликами, авто балансировкой нагрузки, автофайловером, все из коробки - ну ту же монгу(не к ночи будет помянута).
К ShardDB прикрутить redis раз там на чтение в основном, который тоже хорошо масштабируется на чтение репликами.
И получается уже стандарная инфра для проектов такого типа.
Ну зачем идти в строгую реляционку ? Как-то много напильником допиливать, не финансы же все таки.
Нишу никто не займет, так как ниша БД оракл - это не хранилка, а БД + вся enterprise логика - миллионы строк кода. Пока это все переписывать, скорей тут ишак или падишах...
А кто использует Оракл просто как хранилку, конечно съезжают, так как это изначально неверный выбор был, а не замещение Оракл, явно.
Так я именно про это же. Человек задумывается над теоремой и понимает, что нужна реализация каких то конретных метрик. И вопросы про сферический мультимастер отпадают, так как наступает хоть какое-то начальное понимание о возможностях и ограничениях в реализации.
Когда у меня кто то спрашивает про мультимастер в PG, я обычно спрашиваю в ответ, что он знает о теореме CAP. Как правило оказываеться ничего, и отправляется читать википедию. Мне это неплохо экономит время.
Ну да, так же с проблемой онлайн общения и рассылки котиков через жиру )
Представьте, не все забивают гвозди микроскопом.
Статья про оптимизацию плана без единого плана)
Улыбнуло :
AI и/или лень хоть как то проверить было ?