Очень смешно. Явно заказное исследование. Опять же все продукты коммерческие. Все продукты на базе Postgres. Один из критериев сравнения это возможность миграции с импортных продуктов (интересено, в оракле и ms sql есть пакеты миграции с postgresql). Куча фреймворков, которые развиваются в рамках своих корпораций. На российском рынке только один продукт, который заслуживает внимание это Postgres Pro, он хоть не зависит от корпорации и старается продвигать на общественных началах не коммерческий продукт Postgres, а также развивают некоммерческую версию postgres. А почему исследователи забыли про postgres встроенный в astra linux, это же большой сегмент рынка силовых структур и госкомпаний. Опять же интересно, как это будет развиваться на длительном периоде времени, попробую предсказать, все будут ждать выхода новой версии postgres, а потом оперативно дорабатывать свои продукты под новую ванильную версию.
В программном средстве barman есть возможность настройки различных политик связанных с ротацией архивов, а также автоматизации самого процесса регулярного архивирования. Вопрос есть ли такие же возможности в WAL-G. Или это надо еще оборачивать в свой скрипт?
postgres с pgvector насколько мне известно, проигрывает по производительности векторным базам данных. Хотелось бы увидеть сравнение именно с векторными базами данных.
Если не нужны данные за предыдущий месяц, зачем тогда создавать 12 партиций. Можно же сделать динамическое создание партиций на будущий месяц и динамическое удаления за предыдущий месяц, т.е. плавыющее окно.
Спасибо за ответ. В статье не сказано о том, что Index-only Scan будет использоваться, если в запросе указано только одно индексируемое поле. Правильно я пониманию?
На Вашем графике " Сost и selectivity для методов доступа" при низкой селективности (1) стоимость последовательного сканирования выше чем стоимость index only scan, это действительно так? Можете пояснить почему? По моему мнению стоимость в данной ситуация должна удовлетворять условию seq scan < index only scan.
Уточню вопрос. Как правило обычный пользователь не знает, что творится под капотом, он просто пишет в поисковой строке запрос. Вопрос, как построить процесс поиска (пайплайн), чтобы выдать релевантный результат. Если пользователю дать на выбор способы поиска, то этого пользователя надо с начало погрузить в механику этих способов поиска, а к этому не готов.
Например, был в свое время реализован полнотекстовый поиск, но оказалось, что в ряде случаев, этот поиск не находит, то что может найти классический поиск, поэтому был реализован одновременный поиск и результаты обоих поисков складывался.
Автор решил поделиться своим опытом в проектировании базы данных. Изложил свои правила и вынес не обсуждение. Самое главное, что для себя Автор при проектировании базы данных опирается на свои правила (это позволит понять другим участникам проекта, почему принято то или иное решение), а то что эти правила не претендуют на обобщение - это уже другой вопрос. Если каждый разработчик имеет свой набор правил - это хорошо, проще разобраться в проекта. Хуже, если нет вообще каких-то правил, или эти правила вообще не документированы и когда тебе эта база данных сваливается в сопровождение, то начинаются хождения по мукам. Статью стоит рассматривать, как обмен опытом проектирования, с чем-то соглашаться с чем-то нет, корректировать свои правила. В целом статья полезная, раз столько комментариев.
В этом решение есть одна очень не приятная проблема, а именно, если кто-то подпишется на NOTIFY и не будет вычитывать данные, то данные не отправленные клиенты-подписчику будут накапливаться на сервере и когда объем данных в очереди превысит 8 Гб, то сервер остановится.
Основную нагрузку на запись выносим в шардированные системы вроде Cosmos DB. Нагрузки, которые сложнее шардировать, но при этом создают значительный объём, требуют больше времени на миграцию, поэтому этот процесс продолжается.
Не понятно, как это сочетается c
Поскольку все операции записи проходят через один главный узел (primary), такая архитектура не масштабируется горизонтально.
Очень смешно. Явно заказное исследование. Опять же все продукты коммерческие. Все продукты на базе Postgres. Один из критериев сравнения это возможность миграции с импортных продуктов (интересено, в оракле и ms sql есть пакеты миграции с postgresql). Куча фреймворков, которые развиваются в рамках своих корпораций. На российском рынке только один продукт, который заслуживает внимание это Postgres Pro, он хоть не зависит от корпорации и старается продвигать на общественных началах не коммерческий продукт Postgres, а также развивают некоммерческую версию postgres. А почему исследователи забыли про postgres встроенный в astra linux, это же большой сегмент рынка силовых структур и госкомпаний. Опять же интересно, как это будет развиваться на длительном периоде времени, попробую предсказать, все будут ждать выхода новой версии postgres, а потом оперативно дорабатывать свои продукты под новую ванильную версию.
В программном средстве barman есть возможность настройки различных политик связанных с ротацией архивов, а также автоматизации самого процесса регулярного архивирования.
Вопрос есть ли такие же возможности в WAL-G. Или это надо еще оборачивать в свой скрипт?
На скриншоте видно, что процессы находятся в состоянии idle, а это значит, что commit состоялся
такое ощущение, что я такую статью уже где-то читал
postgres с pgvector насколько мне известно, проигрывает по производительности векторным базам данных. Хотелось бы увидеть сравнение именно с векторными базами данных.
Если не нужны данные за предыдущий месяц, зачем тогда создавать 12 партиций. Можно же сделать динамическое создание партиций на будущий месяц и динамическое удаления за предыдущий месяц, т.е. плавыющее окно.
Есть ли в
darts модельChronos (TimeSeriesDataFrame, TimeSeriesPredictor) ?Используется barman. Вопрос - есть ли реализация pgbsckrest в barman?
Спасибо за ответ. В статье не сказано о том, что Index-only Scan будет использоваться, если в запросе указано только одно индексируемое поле. Правильно я пониманию?
На Вашем графике " Сost и selectivity для методов доступа" при низкой селективности (1) стоимость последовательного сканирования выше чем стоимость index only scan, это действительно так? Можете пояснить почему? По моему мнению стоимость в данной ситуация должна удовлетворять условию seq scan < index only scan.
Странное утверждение, что нет четкого понимания, где и как хранятся персональные данные. Тогда, как выстраивается их защита и аудит?
Уточню вопрос. Как правило обычный пользователь не знает, что творится под капотом, он просто пишет в поисковой строке запрос. Вопрос, как построить процесс поиска (пайплайн), чтобы выдать релевантный результат. Если пользователю дать на выбор способы поиска, то этого пользователя надо с начало погрузить в механику этих способов поиска, а к этому не готов.
Например, был в свое время реализован полнотекстовый поиск, но оказалось, что в ряде случаев, этот поиск не находит, то что может найти классический поиск, поэтому был реализован одновременный поиск и результаты обоих поисков складывался.
Можете поделиться своим опытом?
Я еще не встречал той модели, которая умеет писать нормальные SQL-запросы, всё сводится к простейшим реализациям.
Автор решил поделиться своим опытом в проектировании базы данных. Изложил свои правила и вынес не обсуждение. Самое главное, что для себя Автор при проектировании базы данных опирается на свои правила (это позволит понять другим участникам проекта, почему принято то или иное решение), а то что эти правила не претендуют на обобщение - это уже другой вопрос. Если каждый разработчик имеет свой набор правил - это хорошо, проще разобраться в проекта. Хуже, если нет вообще каких-то правил, или эти правила вообще не документированы и когда тебе эта база данных сваливается в сопровождение, то начинаются хождения по мукам. Статью стоит рассматривать, как обмен опытом проектирования, с чем-то соглашаться с чем-то нет, корректировать свои правила. В целом статья полезная, раз столько комментариев.
В статье рассмотрены варианты поиска. Хотелось бы, кроме этого получить какие-нибудь рекомендации в каких случаях использовать тот или иной вариант.
Вопрос. В какой шард попадают новые записи? Насколько я понял из статьи, Вы рассказали, как данные распределены по шардам и как получить к ним доступ.
Второй вопрос. Что делается с данными, по которым заявка закрыта?
В этом решение есть одна очень не приятная проблема, а именно, если кто-то подпишется на NOTIFY и не будет вычитывать данные, то данные не отправленные клиенты-подписчику будут накапливаться на сервере и когда объем данных в очереди превысит 8 Гб, то сервер остановится.
Не понятно, как это сочетается c
Жаль, что на все поставленные вопросы нет комментария автора статьи. Или я ошибаюсь?
В чем преимущество Вашего подхода по сравнению с восстановление на заданный момент времени штатным подходом и после этого восстановить данные?