MongoDB на сервере EC2 или AWS SimpleDB? - PullRequest
50 голосов
/ 03 августа 2010

Какой сценарий имеет больше смысла - разместить несколько экземпляров EC2 с установленной MongoDB или, скорее, использовать веб-сервис Amazon SimpleDB?

Когда у меня несколько экземпляров EC2 с MongoDB, у меня возникает проблема с настройкой экземпляра самостоятельно.

При использовании SimpleDB у меня возникает проблема с привязкой меня к структуре данных Amazons, верно?

Какие различия существуют при разработке?Разве я не должен иметь возможность просто переключать DAO своих сервисных уровней для записи в MongoDB или AWS SimpleDB?

Ответы [ 3 ]

58 голосов
/ 03 августа 2010

SimpleDB имеет некоторые ограничения по масштабируемости. Вы можете масштабировать только с помощью шардинга, и у него более высокая задержка, чем у mongodb или cassandra, у него есть предел пропускной способности, и его цена выше, чем у других вариантов. Масштабируемость ручная (нужно осколок).

Если вам нужны более широкие возможности запроса, у вас высокая скорость чтения и у вас не так много данных, лучше использовать mongodb. Но для долговечности вам нужно использовать как минимум 2 экземпляра сервера mongodb в качестве главного / подчиненного. В противном случае вы можете потерять последнюю минуту ваших данных. Масштабируемость ручная. Это намного быстрее, чем просто. Автошардинг реализован в версии 1.6.

Cassandra имеет слабые параметры запросов, но она так же надежна, как и postgresql. Это так же быстро, как монго и быстрее при больших объемах данных. Операции записи выполняются быстрее, чем операции чтения на Кассандре. Он может автоматически масштабироваться путем запуска экземпляров ec2, но вам нужно немного изменить конфигурационные файлы (если я правильно помню). Если у вас есть терабайты данных, лучше всего использовать Кассандру. Нет необходимости расшаривать ваши данные, они были разработаны с 1-го дня. У вас может быть любое количество копий для всех ваших данных, и если некоторые серверы мертвы, они автоматически возвращают результаты из живых и передают данные мертвого сервера другим. Это очень отказоустойчиво. Вы можете включить любое количество экземпляров, его гораздо легче масштабировать, чем другие варианты. У этого есть сильные параметры клиента .net и java. У них есть пул соединений, балансировка нагрузки, маркировка мертвых серверов, ...

Другим вариантом является hadoop для больших данных, но он не такой реальный, как другие, вы можете использовать hadoop для хранилища данных. Ни у Кассандры, ни у Монго нет транзакций, поэтому, если вам нужны транзакции, лучше подойдет postgresql. Другой вариант - Amazon RDS, но у него плохая производительность и высокая цена. Если вы хотите использовать базы данных или simpledb, вам также может понадобиться кэширование данных (например, memcached).

Для веб-приложений, если ваши данные маленькие, я рекомендую Монго, если это большая Кассандра, тем лучше. Вам не нужен слой кэширования с монго или кассандрой, они уже быстрые. Я не рекомендую Simpledb, он также блокирует вас на Amazon, как вы сказали.

Если вы используете c #, java или scala, вы можете написать интерфейс и реализовать его для mongo, mysql, cassandra или чего-либо еще для уровня доступа к данным. В динамических языках это проще (например, rub, python, php). Вы можете написать провайдера для двух из них, если хотите, и можете изменить хранилище, возможно, во время выполнения, просто изменив конфигурацию, они все возможны. Разработка с использованием mongo, cassandra и simpledb проще, чем базы данных, и они свободны от схемы, это также зависит от используемой клиентской библиотеки / коннектора. Самый простой - это монго. В cassandra есть только один индекс для каждой таблицы, так что вам нужно самим управлять другими индексами, но с выпуском 0.7 вторичных индексов cassandra, насколько я знаю, это станет возможным. Вы также можете начать с любого из них и заменить его в будущем, если потребуется.

21 голосов
/ 03 августа 2010

Я думаю, у вас есть вопрос времени и скорости.

MongoDB / Cassandra будут работать намного быстрее, но вам придется потратить $$$, чтобы они заработали. Это означает, что вам нужно будет запустить / настроить экземпляры сервера для всех них и выяснить, как они работают.

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

В битве Cassandra / MongoDB вот что вы найдете (основываясь на тестировании, с которым я лично принимал участие в последние несколько дней).

Кассандра:

  • Масштабирование / Избыточность очень важны
  • Конфигурация может быть очень интенсивной
  • Чтобы составлять отчеты, вам нужно уменьшить карту, для этого вам нужно запустить слой hadoop. Это была боль, чтобы быть настроенным и большая боль, чтобы стать исполнителем.

MongoDB:

  • Настройка относительно проста (даже для нового шардинга на этой неделе)
  • Избыточность все еще "достигается"
  • Map-Reduction является встроенным и легко вывести данные.

Честно говоря, учитывая время конфигурации, необходимое для наших 10 ГБ данных, мы перешли к MongoDB с нашей стороны. Я могу вообразить использование SimpleDB для случаев, которые должны быть запущены. Но настройка узла для запуска MongoDB настолько смехотворно проста, что, возможно, стоит пропустить маршрут «SimpleDB».

С точки зрения DAO, для Mongo уже есть тонны библиотек. Платформа Thrift для Cassandra хорошо поддерживается. Вы можете написать простую логику для абстрагирования от соединений. Но будет сложнее абстрагироваться от более сложных вещей, чем простой CRUD.

1 голос
/ 27 сентября 2015

Теперь 5 лет спустя нетрудно установить Mongo на любую ОС. Документация проста для отслеживания, поэтому я не вижу проблемы с настройкой Mongo.Другие ответы касались вопросов масштабируемости, поэтому я попытаюсь ответить на этот вопрос с точки зрения разработчика (какие ограничения имеет каждая система):

Я буду использовать S для SimpleDB и M для Mongo.

  • M написано на C ++, S написано на Erlang (не самый быстрый язык)
  • M - это открытый исходный код, установлен везде, S проприетарен, может работать только на Amazon AWS.Вы также должны заплатить за целую группу сотрудников для S
  • S имеет целую группу странных ограничений .M ограничения являются более разумными.Наиболее странные ограничения:
    • максимальный размер домена (таблицы) составляет 10 ГБ
    • длина значения атрибута (размер поля) составляет 1024 байта
    • максимальное количество элементов в ответе "Выбрать"- 2500
    • максимальный размер ответа для выбора (максимальный объем данных S может вернуть вас) - 1Mb
  • S поддерживает только несколько языков (java, php, python, ruby, .net), M поддерживает намного больше
  • оба поддерживают REST
  • S имеет синтаксис запроса, очень похожий на SQL (но способменее мощный).С M вам нужно выучить новый синтаксис, который выглядит как json (также просто освоить основы)
  • с M вы должны узнать, как вы строите свою базу данных.Поскольку многие люди думают, что отсутствие схемы означает, что вы можете выбросить любой мусор в базу данных и извлечь его с легкостью, они могут быть удивлены тем, что максима Junk in, Junk out работает.Я предполагаю, что то же самое в S, но не могу утверждать это с уверенностью.
  • оба не разрешают поиск без учета регистра.В M вы можете использовать регулярные выражения, чтобы каким-то образом (некрасиво / без индекса) преодолеть это ограничение, не вводя дополнительную строчную строку / логику приложения.
  • в S сортировка может быть выполнена только для одного поля
  • из-за ограничения времени 5s счетчик в S может вести себя странно .Если прошло 5 секунд, а запрос еще не завершен, вы получите неполный номер и токен, позволяющий продолжить запрос.Прикладная логика отвечает за сбор всех этих данных суммированием.
  • все является строкой UTF-8 , что затрудняет работу с нестроковыми значениями (например, числами), даты) в S. Поддержка типа M намного богаче .
  • и не имеют транзакций, и объединений
  • M поддерживает сжатие , что на самом делеполезно для хранилищ nosql, где одно и то же имя поля сохраняется снова и снова.
  • S поддерживает только один индекс, M имеет один, составной, многоключевой, геопространственный и т. д. .
  • и поддерживает репликацию и шардинг

Одна из самых важных вещей, которую вы должны учитывать, это то, что SimpleDB имеет очень простой язык запросов.Даже базовые вещи, такие как group by, sum average, distinct, а также манипулирование данными не поддерживаются, поэтому функциональность на самом деле не намного богаче, чем в Redis / Memcached.С другой стороны, Mongo поддерживает богатый язык запросов.

...