Не требуется персистентность;
Необходимо раз в 3-6 часов обновлять практически все ключи в БД (100М+ ключей объемом 50Гб);
Возможность раздавать данные по ключу (или по PK);
Это должна быть СУБД, а не встраиваемое решение;
На момент записи кластер такой базы данных в целом должен продолжать отвечать на запросы, по отдельности ноды могут блокироваться;
Not in-memory — объем данных будет превышать оперативную память;
Горизонтальное масштабирование и репликация;
Нормальная поддержка частой полной перезаписи всех данных (интересует вопрос работы с фрагментацией диска);
Совместимость с C# и Java;
Необязательно но желательно иметь auto key expire;
Наш процесс работы с такой БД:
Аналитический кластер раз в 4-6 часов выдает данные объемом 100М записей (50Гб), которые из себя представляются ключ \ массив из 20 значений, эти данные необходимо эффективно раздавать пользователям через фронт энд систему. В целом запрошено будет максимум 15% этих данных, остальные просто пролежат 4 часа и будут полностью перезаписаны после следующего цикла работы аналитической системы.
Что уже пробовали:
Раньше использовали MongoDB, но на серверах были слабые винты и пришлось перейти на Redis, сейчас винты сменили на очень быстрые, но объемы сильно выросли, поэтому думаем, что нам может еще подойти. В MongoDB смущают следующие вещи: оверхед на хранение данных (BSON, возможно это необоснованные страхи), фрагментация диска и дорогая цена дефрагментации (возможно есть выход), я не нашел возможность быстрой перезаписи всех данных так, что приходилось заливать весь массив заново после чего удалять старый.
Какую БД вы порекомендуете выбрать в нашем случае?
Вам чтобы бесплатно, или чтобы работало и кушать не просило?
В целом почти любая база, 50г это мелочи которые можно на mysql/innodb обмолотить.
И да, дешевле не перезаписывать данные, а писать непрерывно, а потом старые секции дропать целиком. Поэтому желательно с нормальной реализацией секционирования.
Если денег нет, то постгрес.
Оракл — это суровый ентерпрайз и каждый банк/опсос да и любая крупная и не очень структура использует именно их.
Ну и да, спецы — оракловоды стоят приличных денег по з/п.
Извените, а что не так с поддержкой Oracle. Приходилось пару раз обращаться именно по БД. Один раз решили, действительно, серьезную проблему со словарем. В другой указали на ошибку софта и решили это совместно с разработчиками софта. С ms-sql почти не работал, чуть чуть с 2000 пришлось, но после Oracle, ощущение было как пересел с водительского места на пассажирское. Ты можешь подрегулировать кондиционер, опустить спинку кресла но не более, повлиять на машину ты не можешь.
memcached (или аналоги, да хоть mysql) и много памяти — самое дешёвое решение. Вы вот только задачу совсем не описали. Действительно непонятно зачем кластер и как 100М+ ключей обновлять за три часа.
эм, если порядка 50гб данных, то взять хотя бы на 128 гигов ssd — уже будет дурной прирост производительности в любой бд. только надо рассчитать на сколько его хватит, чтобы предварительно заказывать новый.
Так и не понял, чем вам не подходит монга. У нее же простая и действенная масштабируемость — ключевая фича.
С оверхедом на хранение данных это вы зря. Во-первых, он есть практически везде, а во-вторых, storage сейчас очень дешевый.
По поводу фрагментации — разве BSON-документ может делиться на фрагменты? Насколько я помню, в дефолтной конфигурации монга этого не допускает.
Подумаю оп PostgreSQL, но сложно с мамсштабируемостью.
SSD — уже заказан сервер на тест с ними
MongoDB сейчас действительно фаворит в личном чарте БД под задачу. Фрагментация MongoDb я имел ввиду, что когда я дважды заливаю по 50Гб данных в колекцию а потом один раз удаляю 50Гб то на винте почему то существенно больше 50Гб занято (на самом деле там больше 100Гб занято остается)
Это не фрагментация. Просто монго заранее preallocate'ит файлы под данные. Если посмотреть в содержимое файлов конкретной БД, то вы увидите, что когда у вас данных немногим больше 1 ГБ, то данные пишутся в следующий файл, размером 2 ГБ. На самом деле он почти пустой, просто заранее выделен в файловой системе.
Более того, монго заранее выделит и следующий файл — 4 ГБ, даже когда реальных данных в нём вообще нет. Размеры я взял с потолка — стратегию размеров для новых файлов можно настраивать.
Так вот, когда реальные данные удаляются, то на диске файлы автоматически не чистятся и новые данные продолжают писаться в конец «старых». Это как раз в частности для того, чтобы избежать фрагментации.
Если хотите почистить файлы, выполните db.repairDatabase().
Я действительно не верно выразился, все верно вы описали. Думаю что если буду использовать mongo db то буду каждый раз писать данные в новую колекцию а стараю дропать.
Простой
