Есть что-то вроде Redis DB, но не ограничивается объемом оперативной памяти?

Я ищу базу данных, соответствующую этим критериям:

  • Может быть непостоянным;
  • Почти все ключи БД необходимо обновлять один раз в 3-6 часов (ключи 100 М + с общим размером 100 ГБ).
  • Возможность быстрого выбора данных с помощью ключа (или основного ключа)
  • Это должна быть СУБД (поэтому LevelDB не подходит)
  • Когда данные записываются, кластер БД должен иметь возможность обслуживать запросы (отдельные узлы могут быть заблокированы)
  • Не в памяти - наш набор данных превысит пределы RAM
  • Горизонтальное масштабирование и репликация
  • Поддержка полной перезаписи всех данных (MongoDB не очищает пространство после удаления данных)
  • Поддержка С# и Java

Здесь мой процесс работы с такой базой данных: У нас есть аналитический кластер, который производит 100 М записей (50 ГБ) данных каждые 4-6 часов. Данные представляют собой "ключевой массив" [20] ". Эти данные должны быть распределены пользователям через внешнюю систему со скоростью 1-10 тыс. Запросов в секунду. В среднем запрашивается только ~ 15% данных, остальная часть будет перезаписана через 4-6 часов при создании следующего набора данных.

Что я пробовал:

  • MongoDB. Накладные расходы на хранение, высокая стоимость дефрагментации.
  • Redis. Выглядит отлично, но он ограничен оперативной памятью, и наши данные превышают ее.

Итак, вопрос: есть ли что-то вроде Redis, но не ограничивается объемом ОЗУ?

Ответы

Ответ 1

Да, есть две альтернативы Redis, которые не ограничены размером ОЗУ, оставаясь совместимыми с протоколом Redis:

Ardb (С++), репликация (Master-Slave/Master-Master): https://github.com/yinqiwen/ardb

Резидентный сервер хранения данных, совместимый с протоколом redis, поддерживает LevelDB/KyotoCabinet/LMDB как механизм хранения.

Edis (Erlang): http://inaka.github.io/edis/

Edis - это совместимая с протоколом замена сервера для Redis, написанная на Erlang. Целью Edis является замещение Redis, когда настойчивость важнее, чем хранение данных в памяти. Edis (в настоящее время) использует Googledddb как бэкэнд.

И для полноты здесь есть другая база данных данных:

Гипердекс (строки, целые числа, поплавки, списки, наборы, карты): http://hyperdex.org/doc/latest/DataTypes/#chap:data-types

HyperDex:

  • Быстрый: HyperDex имеет более низкую задержку, более высокую пропускную способность и ниже чем другие хранилища ключей.
  • Масштабируемость: HyperDex масштабируется как в систему добавлено больше машин.
  • Согласование: гарантии HyperDex линеаризуемость для операций с ключами. Таким образом, чтение всегда возвращается последнее значение, вставленное в систему. Не только "в конце концов", но немедленно и всегда.
  • Отказоустойчивость: HyperDex автоматически реплицирует данные на нескольких машинах, так что одновременные сбои вверх к пределу, установленному приложением, не приведет к потере данных. Доступный для поиска:
  • HyperDex обеспечивает эффективный поиск вторичных данных атрибутов.
  • Простота использования: HyperDex предоставляет API для различных сценариев и родных языков.
  • Самообслуживание: HyperDex - это самообслуживания и требует небольшого обслуживания пользователей.

Ответ 2

Да, SSDB (https://github.com/ideawu/ssdb), он имеет очень похожие API для Redis: http://www.ideawu.com/ssdb/docs/php/

SSDB поддерживает хэш, zset. Он использует leveldb как механизм хранения, большинство данных хранится на диске, оперативная память используется для кеша. В нашем экземпляре SSDB с данными 300 ГБ он использует только ОЗУ 800 МБ.

Ответ 3

В эти дни вы можете легко найти серверы с объемом памяти более 100 ГБ для размещения одного экземпляра, или вы можете обмануть свои данные и использовать несколько серверов с меньшей оперативной памятью. Хранение 100 ГБ с Redis (в ОЗУ) на самом деле не проблема.

Теперь, если вы действительно хотите, чтобы клон Redis не ограничивался размером ОЗУ, есть NDS (Matt Palmer):

Обратите внимание, что база данных хранилища NDS переместилась из Киотского кабинета в LMDB (очень хороший пакет, который также поддерживает OpenLDAP), именно из-за проблем с возвратом пространства после удаленных ключей.

Другие решения, не совместимые с Redis, также могут удовлетворить ваши потребности: Couchbase и Aerospike, например, могут легко поддерживать вашу пропускную способность. Кассандра и Риак, вероятно, будут работать, если у вас будет достаточно узлов.