MongoDB на сервере EC2 или AWS SimpleDB?
Какой сценарий имеет больше смысла - размещают несколько экземпляров EC2 с MongoDB, установленным, или очень скорее используют веб-сервис Amazon SimpleDB?
При наличии нескольких экземпляров EC2 с MongoDB у меня есть проблема установки экземпляра один.
При использовании SimpleDB у меня есть проблема блокировки меня в право структуры данных Амазонок?
Какие различия там мудры разработкой? Разве я не должен мочь просто переключить ДАО своих уровней служб, или записать в MongoDB или AWS SimpleDB?
2 ответа
SimpleDB имеет некоторые ограничения масштабируемости. Вы можете масштабироваться только путем сегментирования, и у него более высокая задержка, чем у mongodb или cassandra, у него есть предел пропускной способности, и он стоит выше, чем другие варианты. Масштабируемость ручная (нужно шард).
Если вам нужны более широкие параметры запроса, высокая скорость чтения и не так много данных, лучше использовать mongodb. Но для долговечности вам необходимо использовать как минимум 2 экземпляра сервера mongodb в качестве главного / подчиненного. В противном случае вы можете потерять последнюю минуту своих данных. Масштабируемость ручная. Это намного быстрее, чем simpledb. Автошардинг реализован в версии 1.6.
У Cassandra слабые параметры запроса, но он такой же надежный, как и postgresql. Это так же быстро, как mongo, и быстрее при больших объемах данных. Операции записи быстрее, чем операции чтения на кассандре. Он может масштабироваться автоматически, запуская экземпляры ec2, но вам нужно немного изменить файлы конфигурации (если я правильно помню). Если у вас есть терабайты данных, лучше всего использовать кассандру. Не нужно сегментировать ваши данные, он был разработан с первого дня. У вас может быть любое количество копий для всех ваших данных, и если некоторые серверы не работают, он автоматически вернет результаты с живых и распространит данные с мертвого сервера другим. Это очень отказоустойчивый. Вы можете включать любое количество экземпляров, это намного проще масштабировать, чем другие варианты. Он имеет сильные клиентские опции .net и java. У них есть пулы соединений, балансировка нагрузки, маркировка неработающих серверов, ...
Другой вариант - hadoop для больших данных, но он не в реальном времени, как другие, вы можете использовать hadoop для хранения данных.Ни у cassandra, ни у mongo нет транзакций, поэтому, если вам нужны транзакции, лучше подойдет postgresql. Другой вариант - Amazon RDS, но у него плохая производительность и высокая цена. Если вы хотите использовать базы данных или simpledb, вам также может потребоваться кэширование данных (например, memcached).
Для веб-приложений, если у вас мало данных, я рекомендую mongo, если он большой, лучше cassandra. Вам не нужен слой кеширования с mongo или cassandra, они уже работают быстро. Я не рекомендую simpledb, он также блокирует вас, как вы сказали.
Если вы используете C #, java или scala, вы можете написать интерфейс и реализовать его для mongo, mysql, cassandra или чего-либо еще для уровня доступа к данным. Это проще на динамических языках (например, rub, python, php). Вы можете написать поставщика для двух из них, если хотите, и можете изменить хранилище, возможно, во время выполнения, только изменив конфигурацию, все они возможны. Разработка с использованием mongo, cassandra и simpledb проще, чем база данных, и они не содержат схемы, это также зависит от клиентской библиотеки / коннектора, которые вы используете. Самый простой - монго. В cassandra есть только один индекс для каждой таблицы, поэтому вы должны сами управлять другими индексами, но с выпуском 0.7 вторичных индексов cassandra, насколько я знаю, возможно. Вы также можете начать с любого из них и при необходимости заменить его в будущем.
Думаю, у вас есть и вопрос времени, и скорости.
MongoDB / Cassandra будет намного быстрее, но вам придется вложить $ $ $, чтобы заставить их работать. Это означает, что вам нужно запустить / настроить экземпляры серверов для всех них и выяснить, как они работают.
С другой стороны, вам не нужно напрямую платить за транзакцию, вы просто платите за оборудование, что, вероятно, более эффективно для более крупных услуг.
В битве Cassandra / MongoDB вы найдете вот что (на основе тестирования, в котором я лично участвовал в течение последних нескольких дней).
Кассандра:
- Масштабирование / Избыточность очень важны
- Конфигурация может быть очень сложной
- Для составления отчетов вам понадобится map-reduce, для этого вам нужно запустить слой HADOoop. Это было сложно настроить, и еще сложнее было добиться высокой производительности.
MongoDB:
- Конфигурация относительно проста (даже для нового сегментирования, на этой неделе)
- Избыточность все еще «приближается»
- Map-reduce встроена, и данные легко получать.
Честно говоря, учитывая время, необходимое для настройки наших 10 ГБ данных, мы выбрали MongoDB. Я могу представить себе использование SimpleDB для случаев, когда «необходимо запустить эти». Но настройка узла для запуска MongoDB настолько смехотворно проста, что, возможно, стоит пропустить маршрут «SimpleDB».
Что касается DAO, для Mongo уже существует множество библиотек. Фреймворк Thrift для Cassandra хорошо поддерживается. Вероятно, вы можете написать простую логику, чтобы абстрагироваться от соединений. Но будет труднее абстрагироваться от вещей более сложных, чем простой CRUD.