Что лучше всего соответствует моим потребностям: MongoDB, CouchDB или MySQL. Критерии, определенные в вопросе

Question

Наш сайт нуждается в системе управления контентом. Например, администраторы хотят создавать рекламные страницы на лету. Они предоставят текст и изображения для страницы, а также URL-адрес, на котором должна быть страница. Нам нужно хранилище данных для этого. Критерии для хранилища данных просты и определены ниже. Я не знаком с CouchDB или MongoDB, но думаю, что они могут лучше подходить для этого, чем MySQL, но ищу кого-то с большим знанием MongoDB и CouchDB, чтобы присоединиться.

По шкале от 1 до 10, как бы вы оценили MongoDB, CouchDB и MySQL для следующего:

• Java-клиент
• Отслеживание веб-кликов
• CMS как система
• Хранить загруженные файлы
• Простота настройки аварийного переключения
• Поддержка
• Документация

Что бы вы выбрали при этих обстоятельствах?

Answer 1

Каждый подходит для разных случаев использования. Но на сайтах с низким трафиком mysql / postgresql лучше.

Java-клиент: у всех есть клиенты

Отслеживание веб-кликов: Монго и Кассандра больше подходят для такой высокой ситуации записи

Храните загруженные файлы: подходит mongo с gridfs. Кассандра может хранить до 2 ГБ на каждый столбец, разделенный на 1 МБ. mysql не подходит. сохранение только местоположения файла и сохранение файла в файловой системе предпочтительнее для cassandra и mysql.

Простота настройки восстановления после отказа: Кассандра - лучшая, вторая секунда

Поддержка: у всех есть хорошая поддержка, у MySQL самое большое сообщество, Монго - второй

Документация: 1-й MySQL, 2-й монго

Я предпочитаю MongoDB для аналитики (веб-клики, счетчики, журналы) (вам нужна 64-битная система) и mysql или postgresql для основных данных. на компаниях, использующих страницу Монго на сайте Монго, вы можете увидеть, что большинство из них используют Монго для аналитики. Монго может подойти для основных данных после версии 1.8. проблема с Кассандрой в том, что она плохо работает с запросами (не подходит для cms). и проблема с mysql не так легко масштабируется и HA, как cassandra & mongo, а также mysql медленнее, особенно при записи. Я не рекомендую couchdb, он самый медленный.

мой лучший

Сердар Ирмак

Answer 2

Вот несколько быстрых ответов, основанных на моем опыте с Монго.

Java-клиент

Не уверен, но он существует и хорошо поддерживается. Много документов , даже несколько Оболочек POJO , чтобы упростить процесс.

Отслеживание веб-кликов

8 или 9. Благодаря «запускать и забывать» действительно легко выполнять вставки и обновления. MongoDB имеет встроенные инструменты для отображения-сокращения данных и простые инструменты для экспорта данных в SQL для анализа (если Mongo не достаточно хорош).

CMS как система

8 или 9. Легко хранить весь контент веб-страницы. Это действительно легко "зацепить" дополнительные столбцы. Это действительно «хлеб с маслом» Монго.

Хранить загруженные файлы

Здесь есть кривая обучения, но у Mongo есть система GridFS , разработанная специально для сохранения и обслуживания двоичных данных.

Простота настройки отработки отказа

Запустите ваш основной сервер: ./mongo --bindip 1.2.3.4 --dbpath /my/data/files --master Начни свой раб: ./mongo --bindip 1.2.3.5 --dbpath /my/data/files --slave --source 1.2.3.4

Поддержка

10gen имеет список рассылки: http://groups.google.com/group/mongodb-user. У них также есть платная поддержка.

Их время отклика обычно находится где-то между отличным и удивительным.

Документация

Средняя. Это все есть, но все еще немного дезорганизовано. Перепихните это до большого количества новых разработок в прошлом.

Answer 3

Мой взгляд на CouchDB:

Java-клиент: великолепно, используйте ektorp, который довольно прост и полное отображение объектов. В любом случае, все API - это просто Json over HTTP, так что все просто.

Отслеживание веб-кликов: возможно, Redis - лучший инструмент для этого. CouchDB здесь не лучший вариант.

CMS-подобная система: это замечательно, поскольку вы можете легко комбинировать шаблоны, динамические формы, данные и т. Д. И сопоставлять их с помощью представлений.

Хранение загруженных файлов. Любой документ в couchdb может иметь произвольные вложения, так что это вполне естественно.

Простота настройки аварийного переключения: главная / главная репликация гарантирует, что вы всегда будете готовы к работе, база данных никогда не будет повреждена, поэтому в случае сбоя это всего лишь вопрос запуска кушетки и он вступит во владение там, где остановится (минимальное время простоя) и репликация поймает изменения.

Поддержка: есть список рассылки и платная поддержка.

Документация: используйте открытую книгу http://guide.couchdb.org и вики.

Answer 4

Я не вижу здесь ничего подобного "должен обрабатывать миллионы запросов / с", что указывало бы на то, что лучше было бы катиться самостоятельно, чем использовать что-либо с полки, такое как Drupal.

Answer 5

Я думаю, что есть много других сообщений, связанных с этой темой. Тем не менее, я буду вмешиваться, так как я перешел с mysql на mongodb. Это быстро, очень быстро, но это не значит, что оно идеально. Мой совет, используйте то, что вам удобно. Если вам потребуется больше времени для рефакторинга кода, чтобы привести его в соответствие с mongo или couch, тогда придерживайтесь mysql, если вы знакомы с этим. Если это то, что вы хотите использовать в качестве набора навыков, то обязательно изучите mongodb или couchdb.

Для меня я выбрал mongodb по нескольким причинам: хранение файлов через gridfs и геолокацию. Да, я мог бы использовать mysql, но я хотел посмотреть, о чем идет речь. Я должен сказать, что я впечатлен, и у меня все еще есть пути, прежде чем я могу сказать, что мне комфортно с монго.

Из того, что вы перечислили, я могу вам сказать, что монго будет соответствовать большинству ваших потребностей.