Разработка базы данных для данных с высокой частотой дискретизации, построение графиков с несколькими уровнями масштабирования

Question

У меня есть несколько датчиков, подающих данные в мое веб-приложение. Каждый канал имеет 5 выборок в секунду, и данные загружаются вместе в виде 1-минутных сообщений json (содержащих 300 выборок). Данные будут отображаться с использованием flot при нескольких уровнях масштабирования от 1 дня до 1 минуты.

Я использую Amazon SimpleDB и в настоящее время я храню данные в 1-минутных блоках, в которые я их получаю. Это хорошо работает для высоких уровней масштабирования, но для полных дней просто будет слишком много строк для извлечения .

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

Похоже ли это на разумное решение? Как другие внедрили такие же системы?

Answer 1

Хранение данных с пониженной дискретизацией - идеальный подход.Узнайте, как munin хранит свои графики - дневные, средние, ранние и внутридневные графики хранятся там отдельно.

Вы можете хранить данные за каждую минуту, каждые 5 минут, каждый час, каждые 4 часа, каждый день в разныхстолы.Накладные расходы очень малы по сравнению с простым хранением каждой минуты с большой пользой, поскольку вы не передаете то, что вам не нужно.

Answer 2

Для ускорения работы базы данных используйте прямую организационную модель.Это самый быстрый способ хранения / извлечения данных из файлов.Реализация настолько проста, что вам не нужны никакие фреймворки или библиотеки.

Метод:

1. , вам нужно создать алгоритм, которыйпреобразует ключ в непрерывную запись нумерацию (0..макс. количество записей),
2. необходимо использовать фиксированный размер записи,
3. данные хранятся в плоских файлах, где записьПоложение в файле является рек.нет.(на основе ключа, как описано в 1.), умноженного на размер записи (см. 2.).

Собственные данные

Вы можете создать одну информациюфайл в день для облегчения обслуживания.Тогда ваш ключ - нет.образца в течение дня.Таким образом, ваш ежедневный файл будет 18000 * 24 * размер записи .Вам следует предварительно создать этот файл с нулями, чтобы облегчить жизнь операционной системе (возможно, это мало поможет, это зависит от базовой файловой системы / механизма кэширования).

Итак, когда поступают данные, вычислитеположение файла и вставьте запись на место.

Суммированные данные

Сводные данные также следует хранить в прямых файлах.Эти файлы будут намного меньше.В случае суммированных значений за 1 минуту в нем будет 24 * 60 * 60 записей.

Есть несколько решений, которые вы должны принять:

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

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

• по мере поступления собственных данных (в этом случае данные за 1 с обновляются 300 раз, чтоне является оптимальным для немедленной записи на диск, суммирование должно выполняться в памяти);
• фоновое задание должно периодически обрабатывать собственные данные,
• данные суммы должны создаваться ленивым образом, наспрос.

---

Не забывайте, не так уж и много лет назад эти проблемы были проблемами проектирования базы данных.Я могу обещать одно: это будет быстро, быстрее всего (кроме использования памяти для хранения данных).

Answer 3

Я реализовал это некоторое время назад с понижением частоты на лету для некоторых графиков. Недостаток в том, что старший теряет разрешение, но я считаю, что это приемлемо для вас. А если вас интересуют пики, вы можете указать значения max, avg и min.

Алгоритм не так уж сложен. Если у вас есть 5 образцов в секунду и вы хотите удерживать эту гранулярность в течение, возможно, часа, вы должны хранить 5 * 60 * 60 = 18000 образцов для этого часа.

В течение дня вы можете снижаться до 1 выборки каждые 5 секунд, уменьшая количество в 25 раз. Затем алгоритм будет запускаться каждые 5 секунд и вычислять медиану, минимум и максимум из 5 секунд, которые прошли 24 несколько часов назад. Результаты в 12 * 60 * 23 = 16560 больше образцов в день, и если вы храните

Далее я рекомендую пробу каждую минуту, уменьшая количество на 12, возможно, на две недели, так что у вас есть 60 * 24 * 13 = 18720 проб на данные за две недели.

Особое внимание следует уделить хранению данных в БД. Чтобы получить максимальную производительность, вы должны убедиться, что данные одного датчика хранятся в одном блоке в базе данных. Если вы используете, например, PostgreSQL, вы знаете, что один блок имеет длину 8192 байта, и в одном блоке не хранятся две записи. Предполагая, что одна выборка имеет длину 4 байта, и учитывая издержки на строку, я могу добавить 2048 минус несколько выборок в одном блоке. Учитывая самое высокое разрешение, это 2040/5/60 = 6 минут данных. Может быть, сейчас хорошая идея всегда добавлять 6 минут сразу, а может быть 5, чтобы они были просто фиктивными для обновления в более поздние минуты, чтобы запросы могли быстрее извлекать блоки одного датчика.

По крайней мере, я бы использовал разные таблицы для разной степени детализации сенсора.

Answer 4

С некоторых дней Amazon CloudWatch также позволяет использовать пользовательских метрик .Если мониторинг и сигнализация являются вашей главной задачей, это может быть полезно.