Огромная проблема хранения данных

Question

Я начинаю разрабатывать новое приложение, которое будет использоваться около 50000 устройств. Каждое устройство генерирует около 1440 реестров в день, это означает, что будет храниться более 72 миллионов реестров в день. Эти реестры продолжают поступать каждую минуту, и я должен иметь возможность запрашивать эти данные с помощью приложения Java (J2EE). Поэтому необходимо быстро писать, быстро читать и индексировать, чтобы можно было создавать отчеты. Устройства только вставляют данные, и приложение J2EE должно будет иногда читать. Сейчас я ищу варианты программного обеспечения для поддержки такого рода операций.

• Размещение этих данных в одной таблице приведет к катастрофическому состоянию, потому что я не смогу использовать эти данные из-за объема данных, хранящихся в течение года.

• Я использую Postgres, и разделение базы данных, похоже, не является ответом, поскольку мне нужно было бы разбивать таблицы по месяцам или, возможно, более детальный подход, например, по дням.

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

Что вы думаете?

Answer 1

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

2. Вы будете генерировать не более 1 ТБ в год (даже если не реализуете пункт 1), что является не очень большим объемом данных. Это означает около 30 МБ / с данных, которые может обрабатывать один диск SATA.

3. Даже простая неразделенная база данных Postgres на не слишком большом оборудовании должна справиться с этим. Единственная проблема может возникнуть, когда вам нужно будет выполнить запрос или выполнить резервное копирование - это можно решить с помощью зеркала Hot Standby с использованием Потоковая репликация - это новая функция, которая скоро появится выпустила PostgreSQL 9.0. Просто запросите / создайте резервную копию зеркала - если оно занято, оно будет временно и автоматически ставить изменения в очередь, а потом их догонит.

4. Когда вам действительно нужно разделить, делайте это, например, на device_id по модулю 256 вместо времени. Таким образом, вы бы разложили записи по каждому разделу. Если вы разделите вовремя, только один раздел будет очень занят в любой момент, а другие будут простаивать. Postgres очень хорошо поддерживает разбиение . Затем вы также можете распределить нагрузку на несколько устройств хранения, используя табличные пространства , которые также хорошо поддерживаются в Postgres.

Answer 2

Разбиение по временным интервалам - очень хорошее решение, даже если вам придется свернуть свое собственное.Поддерживать отдельные соединения с 50000 баз данных SQLite гораздо менее практично, чем с одной базой данных Postgres, даже для миллионов вставок в день.

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

Ключ к таблицам большого объема: минимизировать объем записываемых вами данных и количество индексов, которые необходимо обновить;не выполняйте ОБНОВЛЕНИЯ или УДАЛЕНИЯ, а только ВСТАВКИ (и используйте разбиение для данных, которые вы будете удалять в будущем - DROP TABLE намного быстрее, чем DELETE FROM TABLE!).

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

Answer 3

Может быть, настало время для БД, которую можно разделить на множество машин?Cassandra?Redis?Не ограничивайте себя sql db.

Answer 4

Управление разделами базы данных может быть автоматизировано; Основанное на времени разделение данных - это стандартный способ решения проблемы такого типа, , и я не уверен, что вижу причину , почему это невозможно сделать с PostgreSQL.

У вас есть приблизительно 72 млн строк в день - при условии, что идентификатор устройства, метка даты и два числа с плавающей точкой для координат будут иметь, скажем, 16-20 байт на строку плюс некоторые незначительные издержки метаданных страницы. План пропускной способности of-fag-пакетов предполагает около 1-1,5 ГБ данных в день или 400-500 ГБ в год, а также индексы, если это необходимо.

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

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

Если вам нужны данные с малой задержкой (т. Е. Отчеты по актуальным данным), также можно создать представление, в котором ведущие разделы сообщаются из операционной системы, а исторические данные - из витрины данных. , Это позволило бы выполнять массовые запросы в таблицах отчетов, оптимизированных для этого, в то время как относительно небольшие объемы текущих данных можно считывать непосредственно из операционной системы.

Большинство систем отчетов с малой задержкой используют некоторые вариации этого подхода - ведущий раздел может обновляться в режиме реального времени (возможно, триггерами) и содержит относительно мало данных, поэтому его можно быстро запрашивать, но не содержит багажа, который замедляет обновление. Остальные исторические данные могут быть сильно проиндексированы для отчетности. Разделение по дате означает, что система автоматически начнет заполнять следующий раздел, и периодический процесс может перемещать, переиндексировать или делать все, что нужно для исторических данных, чтобы оптимизировать их для составления отчетов.

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

Answer 5

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

Некоторые соображения:

• Насколько надежны устройства и насколько они подключены к программному обеспечению для запросов?
• Насколько отказоустойчивым вам требуется хранилище?
• Сколько дополнительной вычислительной мощности требуется устройствам для обработки ваших запросов?

По сути, ваша идея пространственного разделения является хорошей идеей.Это не исключает временного раздела, если это необходимо.Делаете ли вы это в postgres или sqlite, зависит от других факторов, таких как вычислительная мощность и доступные библиотеки.

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