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

Question

Наш сервер (несколько приложений Java на Debian) обрабатывает входящие данные (наблюдения GNSS), которые должны быть:

1. немедленно (задержка <200 мс) доставлено другим приложениям, </li>
2. хранится для дальнейшего использования.

Иногда (возможно, несколько раз в день) из базы данных извлекается около миллиона архивных записей. Размер записи составляет около 12 полей двойной точности + отметка времени и некоторые идентификаторы. Там нет обновлений; УДАЛЕНИЯ очень редки, но массивны. Входящий поток составляет до ста записей в секунду. Поэтому мне пришлось выбрать механизм хранения для этих данных.

Я пытался использовать MySQL (InnoDB). Одно приложение вставляет, другие постоянно проверяют идентификатор последней записи и, если оно обновляется, извлекают новые записи. Эта часть отлично работает. Но я встречал следующие проблемы:

1. Записи довольно большие (около 200-240 байт на запись).
2. Получение миллионов архивных записей недопустимо медленно (десятки минут и более).

Файловое хранилище будет работать нормально (поскольку в середине БД нет вставок, а выборки в основном похожи на «ГДЕ ИД = 1 И ВРЕМЯ МЕЖДУ 2000 И 3000», но есть и другие проблемы:

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

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

MongoDB неприемлем, поскольку размер БД ограничен на 32-битных машинах. Любой механизм, который не обеспечивает быстрый доступ к недавно вставленным данным, также неприемлем.

Answer 1

Я бы рекомендовал использовать TokuDB механизм хранения для MySQL.Он бесплатен для хранения до 50 ГБ пользовательских данных, и его ценовая модель не является ужасной, что делает его отличным выбором для хранения больших объемов данных.

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

Он также совместим с ACID и поддерживает несколько кластерных индексов (что было бы отличным выбором для массовых УДАЛЕНИЙ, которые вы планируете делать).Кроме того, поддерживаются горячие изменения схемы (ALTER TABLE не блокирует таблицы, и изменения выполняются быстро для больших таблиц - я говорю о таблицах размером в гигабайты, которые изменяются в считанные секунды).

Из-за моего личного использования, я использовал дисковое сжатие TokuDB примерно в 5-10 раз, и это намного, намного быстрее, чем MyISAM или InnoDB.Хотя это звучит так, как будто я пытаюсь рекламировать этот продукт, но это не так, это просто удивительно, поскольку вы можете использовать монолитное хранилище данных без дорогостоящих планов масштабирования, таких как разбиение по узлам для масштабирования записей.

Answer 2

На самом деле нет смысла тратить время на загрузку миллионов записей с диска.Ваше 32-битное требование означает, что вы ограничены в объеме ОЗУ, который вы можете использовать для структур данных на основе памяти.Но если вы хотите использовать MySQL, вы сможете добиться хорошей производительности, используя несколько типов таблиц.

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

Поскольку вы не выполняете ОБНОВЛЕНИЯ, я думаю, что MyISAM будет лучше, чем Innodb в этом сценарии.,Вы можете использовать тип таблицы MERGE для MyISAM (недоступно для Innodb).Не уверен, на что похож ваш набор данных, но вы можете иметь по 1 таблице в день (час, неделя?), Тогда ваша таблица MERGE будет расширенным набором этих таблиц.Предполагая, что вы хотите удалить старые данные по дням, просто повторно объявите таблицу MERGE, чтобы не включать старые таблицы.Это действие происходит мгновенно.Удаление старых таблиц также выполняется очень быстро.

Чтобы проверить новые данные, вы можете смотреть на «сегодняшнюю» таблицу напрямую, а не просматривать таблицу MERGE.