Помогите подобрать подходящуюю БД

Подскажите пожалуйста БД обладающую следующими свойствами:

Не требуется персистентность;
Необходимо раз в 3-6 часов обновлять практически все ключи в БД (100М+ ключей объемом 50Гб);
Возможность раздавать данные по ключу (или по PK);
Это должна быть СУБД, а не встраиваемое решение;
На момент записи кластер такой базы данных в целом должен продолжать отвечать на запросы, по отдельности ноды могут блокироваться;
Not in-memory — объем данных будет превышать оперативную память;
Горизонтальное масштабирование и репликация;
Нормальная поддержка частой полной перезаписи всех данных (интересует вопрос работы с фрагментацией диска);
Совместимость с C# и Java;
Необязательно но желательно иметь auto key expire;

Наш процесс работы с такой БД:

Аналитический кластер раз в 4-6 часов выдает данные объемом 100М записей (50Гб), которые из себя представляются ключ \ массив из 20 значений, эти данные необходимо эффективно раздавать пользователям через фронт энд систему. В целом запрошено будет максимум 15% этих данных, остальные просто пролежат 4 часа и будут полностью перезаписаны после следующего цикла работы аналитической системы.

Что уже пробовали:

Раньше использовали MongoDB, но на серверах были слабые винты и пришлось перейти на Redis, сейчас винты сменили на очень быстрые, но объемы сильно выросли, поэтому думаем, что нам может еще подойти. В MongoDB смущают следующие вещи: оверхед на хранение данных (BSON, возможно это необоснованные страхи), фрагментация диска и дорогая цена дефрагментации (возможно есть выход), я не нашел возможность быстрой перезаписи всех данных так, что приходилось заливать весь массив заново после чего удалять старый.

Какую БД вы порекомендуете выбрать в нашем случае?
  • Вопрос задан
  • 3886 просмотров
Пригласить эксперта
Ответы на вопрос 8
strib
@strib
Вам чтобы бесплатно, или чтобы работало и кушать не просило?
В целом почти любая база, 50г это мелочи которые можно на mysql/innodb обмолотить.
И да, дешевле не перезаписывать данные, а писать непрерывно, а потом старые секции дропать целиком. Поэтому желательно с нормальной реализацией секционирования.
Если денег нет, то постгрес.
Ответ написан
kenny_opennix
@kenny_opennix
Если платное однозначно Oracle
Бесплатное пойдет как mysql, так и postgres, лично я бы выбрал postgres.
Ответ написан
Комментировать
@avchizh Автор вопроса
Спасибо за ответ, а если деньги есть то что?
Ответ написан
EugeneOZ
@EugeneOZ
Couchbase (там для аналитки Вам пригодится map reduce и самообновляемые views).
Ответ написан
Комментировать
@Pilat
memcached (или аналоги, да хоть mysql) и много памяти — самое дешёвое решение. Вы вот только задачу совсем не описали. Действительно непонятно зачем кластер и как 100М+ ключей обновлять за три часа.
Ответ написан
Комментировать
foxmuldercp
@foxmuldercp
Системный администратор, программист, фотограф
эм, если порядка 50гб данных, то взять хотя бы на 128 гигов ssd — уже будет дурной прирост производительности в любой бд. только надо рассчитать на сколько его хватит, чтобы предварительно заказывать новый.
Ответ написан
Комментировать
Shedal
@Shedal
Так и не понял, чем вам не подходит монга. У нее же простая и действенная масштабируемость — ключевая фича.

С оверхедом на хранение данных это вы зря. Во-первых, он есть практически везде, а во-вторых, storage сейчас очень дешевый.
По поводу фрагментации — разве BSON-документ может делиться на фрагменты? Насколько я помню, в дефолтной конфигурации монга этого не допускает.
Ответ написан
Комментировать
@avchizh Автор вопроса
Спасибо за ваши ответы.

Подумаю оп PostgreSQL, но сложно с мамсштабируемостью.
SSD — уже заказан сервер на тест с ними

MongoDB сейчас действительно фаворит в личном чарте БД под задачу. Фрагментация MongoDb я имел ввиду, что когда я дважды заливаю по 50Гб данных в колекцию а потом один раз удаляю 50Гб то на винте почему то существенно больше 50Гб занято (на самом деле там больше 100Гб занято остается)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы