powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Большой объем таблицы (большое приращение ежедневно)
13 сообщений из 13, страница 1 из 1
Большой объем таблицы (большое приращение ежедневно)
    #35595380
АндрейПл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть задача опрашивать как можно чаше N-ное количество устройств (минимум 54 максимум 2000) в нормальном варианте 600 (время опроса 0,1 с получается 10 устройст в сек.).
Естественно у меня есть таблица со списком этих устройств и надо как то организовать хранение результатов опроса с указанием времени опроса.
Так вот у меня вопрос может кто подскажет как организовать это хранение истории т.к. данных прибавляться будет очень много.
В день я посчитал выходит
24*60*60 сек * 10устр/сек = 864000 записей ежедневно.
даже если не так часто опрашивать все равно выходит не меньше 400тыс. каждый день!
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35595416
Kirill Razuvaev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> Так вот у меня вопрос может кто подскажет как организовать это хранение
>> истории т.к. данных прибавляться будет очень много.
А в чем, собственно, проблема? Как хранить? - В таблице, вестимо... :-)
И что Вы хотите делать потом с этими данными? Что за данные вообще?
Возможно, имеет смысл далеко не все хранить в БД. Например, если результат
опроса не отличается от предыдущего...


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35595502
IT-Shaman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
АндрейПлЕсть задача опрашивать как можно чаше N-ное количество устройств (минимум 54 максимум 2000) в нормальном варианте 600 (время опроса 0,1 с получается 10 устройст в сек.).
Естественно у меня есть таблица со списком этих устройств и надо как то организовать хранение результатов опроса с указанием времени опроса.
Так вот у меня вопрос может кто подскажет как организовать это хранение истории т.к. данных прибавляться будет очень много.
В день я посчитал выходит
24*60*60 сек * 10устр/сек = 864000 записей ежедневно.
даже если не так часто опрашивать все равно выходит не меньше 400тыс. каждый день!

хранить как ссылку на таблицу устройств, дата-время, прочие параметры.
для оптимизации, как сказано в предыдущем посте, можно хранить только изменения значений параметров или не хранить какие-то дефолтные значения. например, в одном из проектов, связанным с финансовой отчетностью, мы не записывали ежедневный остаток на счете, если он = 0.
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35595744
АндрейПл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Хранить скорее прийдется все значения опросов т.к. в 99% случаев они будут отличаться от предыдущих. (значения там такого рода: ток, напряжение, темперетура, напряжение на входе, код режима работы ну и еще пару на подобие )
Проблема в том как организовать хранение данных опроса (они потом понадобятся для показа диаграмм или таблиц истории) так как если все записывать в одну таблицу то она уже за день будет пол миллиона записей , а за неделю а за месяц.... (это наверное будет влиять на скорость выборки хотя может я ошибаюсь поправте меня СУБД скорее всего будет MS SQL 2000)
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35595786
IT-Shaman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
АндрейПлХранить скорее прийдется все значения опросов т.к. в 99% случаев они будут отличаться от предыдущих. (значения там такого рода: ток, напряжение, темперетура, напряжение на входе, код режима работы ну и еще пару на подобие )
Проблема в том как организовать хранение данных опроса (они потом понадобятся для показа диаграмм или таблиц истории) так как если все записывать в одну таблицу то она уже за день будет пол миллиона записей , а за неделю а за месяц.... (это наверное будет влиять на скорость выборки хотя может я ошибаюсь поправте меня СУБД скорее всего будет MS SQL 2000)

есстественно чем больших записей, тем при прочих равных будет замедляться выборка.
можно создать индексы на поля, по которым будут фильтроваться, группироваться данные.
можно строить таблицы-агрегаты для хранения обобщенных данных.
можно попробовать партиционирование
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35595982
Kirill Razuvaev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> можно создать индексы на поля, по которым будут фильтроваться,
>> группироваться данные.
А вот с индексами на таких объемах - важно не ошибиться...
IMHO, лучше ограничиться PK в составе штампа времени и кода устройства, ибо
любая выборка по времени д.б. ограничена...


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35596029
Kirill Razuvaev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> Проблема в том как организовать хранение данных опроса (они потом
>> понадобятся для показа диаграмм или таблиц истории)
В приведенном Вами "нормальном" варианте при 600 устройствах получается
порядка 1440 отсчетов за сутки (864000/600). Для визуального контроля
(истории) даже 1440 строк - не так уж мало. С другой стороны, сколько
событий нужно для диаграммы, близкой до степени визуальной идентичности к
100% точной? Неужели все?

А к вопросу о постоянной смене контролируемых параметров - может, стоит
писать в БД не все параметры, а только изменившиеся? Типа: "время", "код
прибора", "тип параметра", "значение"? Если, конечно, они все сразу там не
изменяются.


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35596423
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kirill Razuvaev
>> Проблема в том как организовать хранение данных опроса (они потом
>> понадобятся для показа диаграмм или таблиц истории)
А к вопросу о постоянной смене контролируемых параметров - может, стоит
писать в БД не все параметры, а только изменившиеся? Типа: "время", "код
прибора", "тип параметра", "значение"? Если, конечно, они все сразу там не
изменяются....


А насколько усложнится выборка данных и их измененеие (при необходимости)?

IMHO А насчет субж "большой объем таблицы" - IMHO купить большой винчестер.
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35596463
Kirill Razuvaev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> А насколько усложнится выборка данных и их измененеие (при
>> необходимости)?
А в чем сложность? Расскажите? Значение параметра в момент времени узнать
сложно?
Ну, будет это не простой select, а select min(timestamp) where - какие
проблемы-то, при штампе времени в начале первичного ключа?
А изменять - чем сложнее?
Не говоря уже о том, что это первичные данные, кои в нормальной ситуации
изменению не подлежат.

>> А насчет субж "большой объем таблицы" - IMHO купить большой винчестер.
Ага, и сохранять резальтаты в текстовый файл... :-)


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35596575
тыц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в начале вам надо выяснить что от вас требуется, нужныли вам эти показатели в отдельности или только некоторая их агрегация, если пока ещё не ясно, то сохранять в простой таблице, возможно даже без индексов, потом когда будет много данных и более менее понятно что надо прикручивать матвью и партицирование

---
it чтиво
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35596740
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kirill Razuvaev
Ну, будет это не простой select, а select min(timestamp) where - какие
проблемы-то, при штампе времени в начале первичного ключа?

проблемы - в производительности.
даже "при штампе времени в начале первичного ключа".
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35596833
Kirill Razuvaev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> проблемы - в производительности.
>> даже "при штампе времени в начале первичного ключа".
А что, выборок будет больше, чем вставок?
Думаю, уместнее над оптимизацией вставки работать. Тем более, что в
предложенном мной варианте, и место на диске экономится, и данные "чище".
К тому же, если даже брать диаграммы, то быстрее и эффективнее диаграмму
строить по 100 неповторяющимся значениям, чем по 1000 повторяющихся.
Тем более, что выборка все равно по первичному ключу пойдет...
Или, может, natural? ;-)


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Большой объем таблицы (большое приращение ежедневно)
    #35603560
KOT MATPOCKuH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как обычно, для решения проблемы нужно немного, а именно:
- Понять - для чего именно эти данные нужны
- как долго должны храниться
- Выбор инструмента и решения
- Тюнинг

Некоторые мысли и предложения:
1) Обычно такие подробные данные нужны бывают для оперативного контроля, т.е. нужны максимум неделю, потом нужно чистить.

Более важны и дольше должны храниться агрегированные данные - их и нужно считать либо "на лету" (триггеры?), либо периодически, например, раз в час. При этом забудьте 3НФ!!! Считайте и отдельно храните все необходимые агрегированные результаты.
Про индексы по исходной таблице - тоже забудьте, т.к. замедление вставки из-за перестройки индексов экспонентциально зависит от количества строк. Т.к. строк в таблице будет много, каждый индекс существенно будет эту вставку тормозить.

2) На счет инструмента - посоветовал бы выбрать одну из иерархических БД SCADA систем - они для этого и предусмотрены - собирать и хранить данные с устройств в лавинообразном количестве.
Например, Industrial SQL Server (WanderWare) - Для любителей MS SQL, т.к. построен на нем, но заменили подсистему хранения и получения данных, запросы для аналитики можно строить - как к обычному MS SQL

3) На одном предприятии мы получали примерно раз в 30-60 сек с оборудования файл с параметрами работы - около 40 МБ. Требование к хранению - 50 лет.
В итоге, решено было хранить эти файлы в файловом архиве, а в БД заливали из него только 20-30 параметров, с помощью которых в целом можно оценить - как оборудование работает и идентифицировать файл из архива для детального анализа - если таковое протребуется (за год потребовалось только 2 раза). Для файлового архива специально преобрели дисковый массив и пишут DVD-болванки. Пока так. Геморно, но....работает
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Большой объем таблицы (большое приращение ежедневно)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]