Имам опит с Redis и MongoDB, но не бих препоръчал нито един от тях за вашия случай на употреба. Redis е страхотен във всяко отношение, но тъй като е само за RAM и няма функции за клъстериране (все пак те са в процес на разработка), той не се мащабира много добре. 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 и т.н. Но моделът на данните е подобен на Cassandra (колона, т.е. хешове от едно ниво), което работи добре за нас, но може да не е важно за теб. Изглежда изпробвано и вярно, но както при MongoDB трябва да внимавате за проблеми с разделянето, трябва да помислите малко върху ключовете си или ще изпаднете в беда.
Има също CouchDB, Project Voldemort и безброй други възможни избори. Мисля, че ако мислите сериозно за "изключително големи обеми данни", тогава това е между Cassandra, Riak и HBase. Ударете Riak, ако чистото съхранение на ключ-стойност не е достатъчно. В зависимост от това какво имате предвид под „напълно последователна репликация“, тогава Касандра и Риак отпадат, защото има възможност (не непременно голяма и регулируема) за четене на остаряла стойност.
В крайна сметка очевидно трябва да го изпробвате във вашия конкретен случай на употреба, така че всичко, което наистина трябва да вземете от този отговор е:не се занимавайте с MongoDB.
