Я просто хотел узнать, существует ли принципиальная разница между hbase, cassandra, couchdb и monogodb? Другими словами, все они конкурируют на одном и том же рынке и пытаются решить одни и те же проблемы. Или они подходят лучше всего в разных сценариях?
Все это приходит к вопросу, что я должен выбрать, когда. Вопрос вкуса?
Спасибо,
Федерико
Это несколько длинных ответов от @Bohzo. (но они хорошие ссылки)
По правде говоря, они "вроде" конкурируют. Но у них определенно есть разные сильные и слабые стороны, и они определенно не все решают одни и те же проблемы.
Например, Couch и Mongo предоставляют двигатели Map-Reduce как часть основного пакета. HBase - это (в основном) слой поверх Hadoop, поэтому вы также получаете M-R через Hadoop. Cassandra очень ориентирована на хранилище Key-Value и имеет плагины для "слоя" Hadoop поверх (так что вы можете уменьшить карту).
Некоторые из БД обеспечивают управление MVCC (Multi-версия concurrency). Монго не делает.
Все эти БД предназначены для масштабирования по горизонтали, но они делают это по-разному. Все эти БД также пытаются обеспечить гибкость по-разному. Гибкие размеры документов или API REST или высокая избыточность или простота использования, все они делают разные компромиссы.
Итак, на ваш вопрос: Другими словами, все ли они конкурируют на одном и том же рынке и пытаются решить одни и те же проблемы?
С чего начать?
Человек, это сложный вопрос. Я работаю над крупной компанией, которая подталкивает массу данных, и мы прошли через несколько лет. Мы несколько раз пытались Кассандру, и пару лет назад он не мог справиться с нагрузкой. Мы используем Hadoop повсюду, но он определенно имеет крутую кривую обучения, и он не сработал в некоторых наших средах. Совсем недавно мы попытались сделать Cassandra + Hadoop, но оказалось, что у него много работы по настройке.
Лично мой отдел перемещает несколько вещей в MongoDB. Наши причины для этого - честно простота.
Настройка Mongo в окне linux занимает минуты и не требует доступа к корню или изменения в файловой системе или чего-то необычного. Нет сумасшедших конфигурационных файлов или перекомпиляций Java. Итак, с этой точки зрения, Mongo был самым простым "шлюзовым лекарством" для того, чтобы заводить людей в магазины KV/Document.
Вот подробное сравнение между HBase и Cassandra
Вот (смещенное) сравнение MongoDB и CouchDB
Короткий ответ: тест перед использованием в процессе производства.
Я могу предложить свой опыт как с HBase (расширенный), так и MongoDB (только начиная).
Несмотря на то, что они не одни и те же магазины, они решают одни и те же проблемы:
Мы с большим энтузиазмом относились к HBase. Он построен на Hadoop (который является прочным), он находится под Apache, он активен... чего еще вы хотели? Наш опыт:
В общем, HBase был кошмаром. Не рекомендовал бы его никому, кроме наших прямых конкурентов.:)
MongoDB решает все эти проблемы и многое другое. Приятно настраивать, он делает его простым и прозрачным, а настройки по умолчанию на самом деле имеют смысл. Вы можете выполнять (горячие) резервные копии, у вас могут быть вторичные индексы. Из того, что я прочитал, я бы не рекомендовал MapReduce на MongoDB (только JavaScript, 1 поток на node), но для этого вы можете использовать Hadoop.
И это также ОЧЕНЬ активно по сравнению с HBase.
также: http://www.google.com/trends?q=HBase%2CMongoDB
Мне нужно больше сказать?:)
ОБНОВЛЕНИЕ: много месяцев спустя я должен сказать, что MongoDB доставлен на все учетные записи и многое другое. Единственный реальный недостаток заключается в том, что хостинговые компании не предлагают его так, как они предлагают MySQL.;) Также похоже, что MapReduce будет многопоточным в 2.2. Тем не менее, я бы не использовал MR таким образом. YMMV.
Кассандра хороша для записи данных. у него есть преимущество "записи никогда не сработают". Он не имеет одинарной ошибки.
HBase очень хорош для обработки данных. HBase основан на файловой системе Hadoop (HDFS), поэтому HBase не нужно беспокоиться о репликации данных, согласованности данных. HBase имеет единственную точку отказа. Я не совсем уверен, что это означает, что если у него есть одна точка отказа, тогда она так же похожа на РСУБД, где у нас есть единственная точка отказа. Возможно, я ошибаюсь, потому что я совершенно новый.
Как АБУ РИАК? У кого-то есть опыт использования RIAK. Я краснею там, где тебе нужно платить, я не уверен. Нужно объяснять.
Еще одна вещь, которую вы предпочтете использовать, когда речь идет только о чтении большого количества данных. У вас нет проблем с письмом. Представьте себе, что у вас есть база данных с pitabyte, и вы хотите сделать быстрый поиск, какую базу данных NOSQL вы бы предпочли?