В настоящее время суточные и часовые интеграторы хранятся минимум один месяц. Однако, в некоторых системах интеграторы не требуются вовсе, но при этом запрашиваются часовые данные. В результате хранение интеграторов занимает значительную долю базы данных. В приведенном ниже примере, например, более 15%.
Предланаю: реализовать настройку, при которой минимальный срок хранения часовых интеграторов будет составлять 1 час, а суточных - 1 сутки.
Добрый день!
Удаление данных производится раз в сутки, делать скважность хранения в час вообще не имеет смысла.
Насколько я понимаю, подавляющее большинство пользователей устраивает текущий механизм хранения, так что пока мы не планируем менять систему очистки.
Пусть будут сутки. Тоже хорошо.
Моё предложение возникло, когда пришлось изменять работу системы: увеличивать количество объектов и частоту опросов, пытаясь остаться в той же базе данных.
Натолкнулся на “аппендикс”: если интеграторы не нужны, они всё равно есть и занимают немалую часть базы.
Вот данные системы, настройка которой приведена в начале: база 4814 мб
Интеграторы занимают 14,4%. При этом они совсем не нужны в этой конкретной системе.
Раз не формировать интеграторы не получается (эта часть не управляется), то моё предложение - сделать очистку часовых и суточных интеграторов так же часто, как и текущие.
Это не аргумент
Я с вами про оптимизацию ПО, а вы про принятие технических решений на основе каких-то опросов, хотя я не понял, из чего вы сделали этот вывод
“Подавляющее большинство пользователей” вообще не должно интересоваться “механизмом хранения”. А если начинает интересоваться, то это показатель проблем.
А “подавляющее большинство” систем, в моей практике, вообще не настроено в части того, что и как хранить в базе. И если не хватает базы, переходят на Postgres или покупают MSSQL, или забрасывают систему ЛЭРС как негодную, а то и принимают решение о финансировании другого проекта.
Я пока не вижу необходимости в такой оптимизации. Приведённые вами параметры показывают, что протоколы опроса занимают в 3 раза больше места, чем интеграторы. Если вы сократите срок хранения протоколов, выигрыш будет гораздо больше.
Не думаю, что именно эта доработка заставит это большинство пользователей не переходить на другую систему.
Её достаточно проблемно сделать с технической точки зрения и я до сих пор не вижу как это улучшит работу даже той системы, скриншот отчёта по которой вы показали.
Более того, если вы аппелируете к тому, что ЛЭРС считают негодной из-за того, что кончается место в БД SQL Server, будет куда выгоднее перейти в стандартной поставке с SQL Server на Postgres. Думаю, что мы рассмотрим такой вариант.
Эти данные важны. В системе сотни объектов и 15-минутные опросы. Но и этот объем тоже будет оптимизирован. Однако в этой теме я говорю про интеграторы, которые иногда вообще не используются.
Вы поняли не тот смысл, который я вкладывал в свой текст. Меня смутил оборот “подавляющее большинство пользователей” в качестве аргумента, не более. И я показал, как сумел, что он тут неприменим.
Я об этом не думал. Но, возможно, в этом и есть смысл. Исчезнет задача сделать систему рабочей и при этом “упихать” ее в 10 Гб.
Хотя внешние ограничения дисциплинируют и заставляют смотреть на размер базы, что в среднем благотворно сказывается на быстродействии.
Ну, грубая прикидка говорит о том, что 91-94% данных в таблице интеграторов в системе из примера - это часовые данные. И если получится изменить сроки хранения, то размер уменьшится на 90%. Это грубо, и наверняка я не учел нюансов, которые знаете вы.
Поэтому как минимум обдумайте это предложение.
Если уж вы говорите про оптимизацию ПО, то она делается по-другому. Сначала проводится анализ и определяются хотспоты. Оптимизация начинается именно с них, так как это реально узкие места, мешающие работы системы.
Без этого оптимизация не делается. В вашем случае можно сделать вывод, что общий объём базы примерно 5Гб, так что здесь оптимизация вообще не требуется и выполнять её незачем.
Даже если предположить, что она действительно нужна, то интеграторы занимают только 14% от всей базы. К тому же, это будет предельный размер, сильно больше их не станет, так как уже работает очистка БД.
Но даже не учитывая этот факт, если мы сократим количество интеграторов даже на 90% (в чём я сомневаюсь), то общий размер базы снизится примерно на 12%, что так же не будет сильно заметно.
Если у вас есть какие-то другие примеры, мы готовы их проанализировать. Но из вашего предложения пока видно, что вам никакая оптимизация не требуется.
Текущий размер уже результат оптимизации. Вы правы, сейчас нет необходимости ее уменьшать. Интеграторы для меня показались потенциальным ресурсом.
вот другой.
Настройки
Текущий размер базы - как на прошлой неделе скорректировали профиль хранения данных
Размер таблиц
В этом примере интеграторы занимают 25%
