Если не нужны данные за предыдущий месяц, зачем тогда создавать 12 партиций. Можно же сделать динамическое создание партиций на будущий месяц и динамическое удаления за предыдущий месяц, т.е. плавыющее окно.
Конфигурация с peers решает эту проблему: ядро распределяет входящие соединения между слушающими сокетами, при получении cancel проверяет идентификатор сессии и отправляет «отмену» правильному бэкенду.
Такая конфигурация может решить проблему notify через pgbouncer в режиме транзакций?
Спасибо за ответ. В статье не сказано о том, что Index-only Scan будет использоваться, если в запросе указано только одно индексируемое поле. Правильно я пониманию?
На Вашем графике " Сost и selectivity для методов доступа" при низкой селективности (1) стоимость последовательного сканирования выше чем стоимость index only scan, это действительно так? Можете пояснить почему? По моему мнению стоимость в данной ситуация должна удовлетворять условию seq scan < index only scan.
Уточню вопрос. Как правило обычный пользователь не знает, что творится под капотом, он просто пишет в поисковой строке запрос. Вопрос, как построить процесс поиска (пайплайн), чтобы выдать релевантный результат. Если пользователю дать на выбор способы поиска, то этого пользователя надо с начало погрузить в механику этих способов поиска, а к этому не готов.
Например, был в свое время реализован полнотекстовый поиск, но оказалось, что в ряде случаев, этот поиск не находит, то что может найти классический поиск, поэтому был реализован одновременный поиск и результаты обоих поисков складывался.
Автор решил поделиться своим опытом в проектировании базы данных. Изложил свои правила и вынес не обсуждение. Самое главное, что для себя Автор при проектировании базы данных опирается на свои правила (это позволит понять другим участникам проекта, почему принято то или иное решение), а то что эти правила не претендуют на обобщение - это уже другой вопрос. Если каждый разработчик имеет свой набор правил - это хорошо, проще разобраться в проекта. Хуже, если нет вообще каких-то правил, или эти правила вообще не документированы и когда тебе эта база данных сваливается в сопровождение, то начинаются хождения по мукам. Статью стоит рассматривать, как обмен опытом проектирования, с чем-то соглашаться с чем-то нет, корректировать свои правила. В целом статья полезная, раз столько комментариев.
В этом решение есть одна очень не приятная проблема, а именно, если кто-то подпишется на NOTIFY и не будет вычитывать данные, то данные не отправленные клиенты-подписчику будут накапливаться на сервере и когда объем данных в очереди превысит 8 Гб, то сервер остановится.
Основную нагрузку на запись выносим в шардированные системы вроде Cosmos DB. Нагрузки, которые сложнее шардировать, но при этом создают значительный объём, требуют больше времени на миграцию, поэтому этот процесс продолжается.
Не понятно, как это сочетается c
Поскольку все операции записи проходят через один главный узел (primary), такая архитектура не масштабируется горизонтально.
1) Этот пример на основе представленной таблицы vehicles по-сути содержит не нормализованные данные, а именно для поля verhicles_type напрашивается отдельная справочная таблицы, на которую идет ссылка из таблицы vehicles. По другим подобным полям аналогичная ситуация. Вопрос - Как должна теперь выглядеть Ваша разработка?
2) А теперь представим нормализованную базу данных с сотнями таблицы и различными запросами пользователей на естественном языке. Как в этом случае использовать Ваши наработки, не получится ли в итоге тоже самое, как вы описывали ограничения c BI-дашбордами? Как научить модель строить сложные запросы с агрегацией, рекурсиями и т.д. и т.п.?
Если не нужны данные за предыдущий месяц, зачем тогда создавать 12 партиций. Можно же сделать динамическое создание партиций на будущий месяц и динамическое удаления за предыдущий месяц, т.е. плавыющее окно.
А что вы скажет про Pacemaker?
Такая конфигурация может решить проблему notify через pgbouncer в режиме транзакций?
Есть ли в
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
Жаль, что на все поставленные вопросы нет комментария автора статьи. Или я ошибаюсь?
1) Этот пример на основе представленной таблицы vehicles по-сути содержит не нормализованные данные, а именно для поля verhicles_type напрашивается отдельная справочная таблицы, на которую идет ссылка из таблицы vehicles. По другим подобным полям аналогичная ситуация. Вопрос - Как должна теперь выглядеть Ваша разработка?
2) А теперь представим нормализованную базу данных с сотнями таблицы и различными запросами пользователей на естественном языке. Как в этом случае использовать Ваши наработки, не получится ли в итоге тоже самое, как вы описывали ограничения c BI-дашбордами? Как научить модель строить сложные запросы с агрегацией, рекурсиями и т.д. и т.п.?
В чем преимущество Вашего подхода по сравнению с восстановление на заданный момент времени штатным подходом и после этого восстановить данные?
Я именно так и делал. Но дело в том, что новая версия zabbix использует другую структуру базы данных. В этом то и проблема.
Насколько я понял из статьи, что архив создается после порчи данных. Если это так, то тогда не понятно, как получить данные до их порчи.