[13945] Хранение ограниченного количества экземпляров базы настройки

Сейчас можно выставить ограничение только по возрасту записи. Но по сути нам нужны только последние 2-3 версии.
Экземпляры записей базы настроек занимают у нас примерно 20%-25% базы.
Возможно ли добавить настройку для удаления устаревших записей(с указанием глубины актуальности ‘1 или 2 или 3… последних версии’)?

А как часто вы считываете базу настроек? Может, просто делать это пореже, например, раз в неделю, и хранить архива месяц?

Читаем ежедневно т.к. необходим оперативный контроль за изменением базы настроек в устройстве.

П.С. если ограничивать длительность хранения - получаем проблему с удалением всех экземпляров по истечении срока хранения в случаях, когда прибор по той или иной причине не опрашивался.

Дополню.
Этот вопрос не имеет какой-либо срочности. Просто предложение по оптимизации БД.

Мы добавили предложение в копилку идей, но пока без конкретной версии. В ближайшее время мы сконцентрируемся на других задачах, а сроки реализации этого предложения определим позже.

Поддерживаю предложение. Вот тут подробный пример, как работает текущий алгоритм хранения базы настройки: Размер таблицы базы настроечных параметров неадекватно большой

Я бы предложил, более существенные изменения. В настройках хранения базы настроечных параметров добавил бы возможность хранить только значимые экземпляры базы: 1 запрошенный экземпляр, самый последний запрошенный, а также экземпляры вокруг изменения. Т.е. после обнаружения изменения настройки, сохраняется последний экземпляр базы до изменения и первый после изменения.

В моей практике прочие экземпляры не нужны.

1 лайк

Ну да. В принципе не имеет смысла сохранять новый экземпляр, если его контрольная сумма совпадает с текущим.

Это слишком выбивается из остальных механизмов очистки БД. Если хранение N последних записей ещё как-то можно уложить, то вычислять окрестности и хранить только данные из них кажется мне черезмерным усложнением, которое большинству пользователей пока не требуется.

Может быть, достаточно хранить только изменившиеся параметры и сделать такую настройку в системе?

И ещё один момент. Для чего это нужно? Как я понимаю, вы хотите открыть таблицу с базой настроек устройства и увидеть только значимые даты, в которые происходили изменения. Может, просто сделать флажок “Только изменившиеся параметры” в фильтр? Тогда можно будет посмотреть записи только за те даты, в которые были зафиксированы изменения парамтеров.

Выделить эти изменившиеся параметры между 2 экземплярами - это будет удобно. Но хранить стоит экземпляр базы целиком, т.к. текущее состояние настройки - это документ и может потребоваться передать кому-нибудь или напечатать.

Для меня вроде логика простая, может мы не поняли друг друга?
При получении нового экземпляра вы его сравниваете с последним сохраненным, причем можно для ускорения сравнивать по какому-нибудь вычислимому коду, контрольной сумме, хэшу и т.д. на ваше усмотрение. И если оба экземпляра одинаковые, то последний в базе перезаписывается полученным. Все.

Да, именно такая цель. И видеть настройку прибора в момент его монтажа было бы отлично, но текущая реализация не позволит этого совместно с ежедневым контролем изменения, на большом количестве объектов

Я и не хотел ничего из БД удалять. Только добавить возможность исключить из просмотра записи, в которых нет изменений.

А зачем что-то перезаписывать, когда это можно сделать прямо на интерфейсе? Сейчас вы выбираете период, за который просматривается база настроек. Добавить флажок “Показывать только изменившиеся”, и одинаковые настройки будут скрыты. В БД они останутся, их всегда можно будет просмотреть, чтобы восстановить историю опроса.

Я наткнулся на эту тему, только потому, что пришлось разбираться с системой в которой таблица с настроечными параметрами занимает 5 Гб и сейчас это 17%. В системе были ошибки планирования опроса, этим объясняется ее громадный размер. Но погрузившись в детали, я выяснил, что при наличии постоянной задаче оптимизации размера базы данных, цели:

  • контроль за изменением настроечных параметров;

  • хранение всей истории изменения настроечных параметров;

  • оптимальное использование базы данных для хранения настроечных параметров

не реализуемы.

И это вроде не цели класса: купить дешево, качественно и быстро :slight_smile:

Это и является проблемой. И экземпляры настроечных баз никто, по моему мнению, из-за профессиональной потребности смотреть не будет, нужно знать только когда и что изменилось, и быть уверенными, что контроль постоянный. Экземпляры одинаковые, в них нечего смотреть - сейчас при ежедневном контроле неизменности настроечных параметров – хранимые экземпляры базы настроечных параметров на 99% “информационный мусор”, его никто не смотрит. И я не могу придумать причину, когда нужно смотреть базу настроек, если она не текущая или она не отличается от остальных.

Итого, просмотр только изменившихся данных я считаю, нужно добавить. Задача оптимизации базы считаю второстепенной. Возникла она только один раз у вас из-за неверных настроек. Добавлять какой-то новый механизм очистки только ради одного раза считаю нецелесообразным.

:rofl: Неожиданный вывод

А как же эти цели. Они тоже несовместимы, на мой взгляд. :slight_smile:

Мне не понятно как оценить увеличение базы данных, чтобы в ЛЭРСе были настроечные данные прибора, даже если его сняли в ремонт и ремонт затянулся или нет связи длительное время с типичной задачей - ежедневный контроль настроечных параметров.
Можете дать исходные цифры для оценки? Размер одного экземпляра настроечной базы 1 прибора

Не понимаю что с чем несовместимо. И как это вяжется с размером БД.

Если прибор снят на ремонт, он не опрашивается и на размер базы не влияет.

Нет, это сильно зависит от модели устройства. У ВКТ-5, например, три параметра, которые займут 30 байт. А у ТСРВ-024 их под тысячу и займут они десять килобайт.

Так же хочу уточнить, что база настроек системой используется только для диагностики, и количество записей в ней практически не влияет на то как быстро работает опрос и формирование отчётов. В таблице есть все нужные индексы для того, чтобы выборка была максимально быстрой.

Для системы с количеством объектов в диапазоне 150-300, как правило, бесплатная база данных из комплекта поставки вполне подходит. Однако необходимо найти баланс между размером логов, журналов и данных и потребностями пользователей в хранении этой информации.

Рассмотрим затраты на базу данных для такой системы. Она будет состоять из распространенных приборов, таких как СПТ944, 943, ТВ7 и ТСРВ. Исходя из ваших данных, размер базы данных одного прибора составляет около 10 Кб. Предположим, что настройки приборов хранятся в течение одного календарного года, и ведется ежедневный контроль настроек прибора.

В результате, таблица займет примерно 0,5 Гб (для 150 приборов) - 1 Гб (для 300 приборов).

Однако, если пользователи не настроят отдельное расписание автоопроса для чтения базы данных, а это, на мой взгляд, не очевидное действие, размер базы данных может увеличиться до 12-24 Гб. В таком случае, вероятно, систему придется переводить на коммерческую БД или оптимизировать ее для более эффективного чтения данных. В последнем случае вы получаете увеличение нагрузки на вашу ТП.

При этом, из всего этого объема информации, только 36 Мб является действительно полезной. Это данные, которые теоретически кто-то может просмотреть. Я рассчитал этот объем, исходя из нереалистичного сценария, где настройки каждого из 150-300 приборов меняются каждый месяц в течение года.

Важно отметить, что при таком сценарии пользователи не смогут увидеть настройки, которые были при запуске узла учета, а они, скорее всего, соответствуют проектной документации. Проще говоря, спустя год пользователь не сможет получить доступ к первоначальным настройкам. Это является серьезным недостатком.

Именно этот аспект я имел в виду, когда говорил о “несовместимости”.

Если в моем анализе есть неточности, пожалуйста, укажите их.

По возвращению прибора из ремонта в ЛЭРСе может отсутствовать база данных, необходимая для сравнения с данными, хранящимися в приборе. Это может привести к невозможности сравнения, а то восстановления настроек прибора после ремонта. К сожалению, ЛЭРС не всегда может помочь в таких ситуациях, так как база настроек прибора уже может быть удалена.

Всегда можно использовать бесплатную базу Postgres, в которой ограничений на объём нет. Я пока не вижу большой проблемы, только теоретические описания. На практике, повторюсь, это первый случай, когда размер базы настроек стал проблемой. Исходя из этого я пока не хочу усложнять механизмы очистки.

Чтобы хранить мусор?

Я пришёл к выводу, что есть два варианта: либо мы контролируем настройки приборов и ограничиваем размер базы данных, либо читаем настройки прибора в полуавтоматическом режиме, в зависимости от ситуации, чтобы они всегда были и не терялись, и не ограничиваем размер базы данных.

Мне не нравится этот выбор, но я не вижу иных вариантов.

У меня, как оказалось, почти все случаи более менее больших систем поставщиков ресурсов - “такие”.

Этот вопрос не был первоочередным, поэтому я не анализировал ситуацию. Однако, описанный выше случай с таблицей настроек объемом 5 ГБ заставил меня более внимательно изучить проблему.

С моей точки зрения, вам необходимо доработать настройки.

Будем ждать пока завалят случаями? Почему не исправить заранее, выявленную проблему?