У меня есть опыт работы с Redis и MongoDB, но я бы не рекомендовал ни один для вашего случая использования. Redis великолепен во всех отношениях, но поскольку он предназначен только для оперативной памяти и не имеет функций кластеризации (пока они находятся в разработке), он не очень хорошо масштабируется. MongoDB Я бы никогда больше не использовал для чего-либо, кроме небольшого набора реплик.
По сути, MongoDB является незрелым и совершенно не подходит для любых требований к большим объемам и высокой производительности. Он имеет глобальную блокировку записи, которая удерживается во время очистки диска, что означает, что производительность может сильно отличаться в зависимости от того, что вы делаете. На практике это делает обновления, которые увеличивают объем документов, невозможным, и вы также должны быть очень осторожны с удалениями. Говоря об удалениях, они сильно фрагментируют базу данных, поэтому, если вы сделаете много удалений, производительность снизится.
Раздевание в 1.8.0 через 1.8.1 было катастрофой. Были полные баги, которые никогда не должны были превращаться в стабильный релиз. Конфигурация не была сброшена должным образом, и было очень легко привести вашу базу данных в плохое состояние, чтобы куски никогда не перемещались из основного сегмента. 1.8.2 решает большинство из них и кажется более стабильным, но я не доверяю реализации шардинга. Добавьте к этому, что шардинг труден, даже когда все работает, не всегда легко выбрать естественный ключ шарда, и если ты не шардишь, это вызовет у тебя много горя.
С MongoDB действительно легко работать, а набор функций действительно хорош. Документация, драйверы и сообщество - все отлично. MongoDB работает как замена для MySQL, но не используйте его для всего, что нужно масштабировать.
В настоящее время мы смотрим на переезд на Кассандру. Я нахожу динамо-модель (например, отсутствие мастер-узлов; нигде не пишите и не читайте; просто добавляйте узлы для роста кластера), и эти функции более или менее подходят нам. Модель данных менее похожа на схему, как MongoDB, хотя и немного более ограничена (в основном вы можете выбирать между одним или двумя уровнями хэшей). Я уверен, что сообщество хорошо, когда вы в него вступаете, но мне пока трудно найти хорошую информацию о том, как решать общие проблемы, а документации не хватает. Большая часть информации, которую вы находите в блогах, - это год, и с тех пор произошло много событий (0,7 и 0,8 кажутся действительно значимыми обновлениями, но большинство из них - около 0,6). Драйверы также не очень зрелые или хорошо документированные, из того, что я видел до сих пор, и все, кажется, спорят о том, следует ли использовать Thrift, Avro или CQL (и этот показатель изменился с 0,6 до 0,7 до 0,8) ,
Riak интересен по тем же причинам, что и Cassandra, но для нас недостаточно простого хранилища ключей-значений, нам нужно иметь возможность обновляться без предварительного чтения. С Riak это невозможно, так как значения - это просто капли. Похоже, это не будет проблемой для вас.
HBase - другой претендент. Кажется, что настраивать и запускать из-за большого количества разных частей, ZooKeeper, HDFS и т. Д. Это сложно важно для тебя. Это кажется проверенным и правдивым, но, как и в MongoDB, вам нужно остерегаться проблем с шардингом, вы должны немного подумать о своих ключах, иначе у вас возникнут проблемы.
Существует также CouchDB, Project Voldemort и множество других возможных вариантов. Я думаю, что если вы серьезно относитесь к "чрезвычайно большим объемам данных", то это между Cassandra, Riak и HBase. Ударьте Риака, если чистого хранилища ключ-значение недостаточно. В зависимости от того, что вы подразумеваете под «полностью согласованной репликацией», Cassandra и Riak выходят, поскольку существует возможность (не обязательно большого и настраиваемого) чтения устаревшего значения.
В конце концов, вам, очевидно, придется опробовать его на вашем конкретном сценарии использования, поэтому все, что вы действительно должны взять домой из этого ответа, это: не связывайтесь с MongoDB.