Какой сценарий имеет больший смысл - разместить несколько экземпляров EC2 с установленным MongoDB или, скорее, использовать веб-сервис Amazon SimpleDB?
При наличии нескольких экземпляров EC2 с MongoDB у меня возникает проблема установки экземпляра самостоятельно.
При использовании SimpleDB у меня есть проблема с блокировкой меня в структуре данных Amazons?
Каковы различия в развитии? Разве я не могу просто переключить DAO моих слоев обслуживания, чтобы либо написать MongoDB, либо AWS SimpleDB?
SimpleDB имеет некоторые ограничения масштабируемости. Вы можете масштабировать только по шкале, и она имеет более высокую задержку, чем mongodb или cassandra, у нее есть предел пропускной способности и она выше, чем другие. Масштабируемость - это ручная (вы должны оштрафовать).
Если вам нужны более широкие параметры запроса, и у вас высокая скорость чтения, и у вас не так много данных mongodb. Но для долговечности вам нужно использовать как минимум 2 экземпляра сервера mongodb как master/slave. В противном случае вы можете потерять последнюю минуту своих данных. Масштабируемость - ручная. Это намного быстрее, чем simpledb. Автопродажа реализована в версии 1.6.
Cassandra имеет слабые варианты запросов, но столь же прочен, как и postgresql. Это быстрее, чем mongo и быстрее при более высоком размере данных. Операции записи выполняются быстрее, чем операции чтения на кассандре. Он может автоматически масштабироваться, активируя экземпляры ec2, но вам нужно немного изменить файлы конфигурации (если я правильно помню). Если у вас есть терабайты данных, то кассандра - ваш лучший выбор. Нет необходимости очерчивать ваши данные, он был разработан с 1-го дня. У вас может быть любое количество копий для всех ваших данных, и если некоторые серверы мертвы, он автоматически вернет результаты из живых и распределит данные мертвого сервера другим. Он сильно виноват. Вы можете включить любое количество экземпляров, это намного проще, чем другие параметры. Он имеет сильные параметры .net и java. У них есть пул соединений, балансировка нагрузки, маркировка мертвых серверов,...
Другим вариантом является hasoop для больших данных, но это не так, как в режиме реального времени, как и другие, вы можете использовать hasoop для datawarehousing. Ни кассандра, ни монго не имеют транзакций, поэтому, если вам нужны транзакции, postgresql лучше подходит. Другим вариантом является Amazon RDS, но производительность плохая, а цена высокая. Если вы хотите использовать базы данных или simpledb, вам может понадобиться кэширование данных (например, memcached).
Для веб-приложений, если ваши данные небольшие, я рекомендую mongo, если это большая кассандра. Вам не нужен слой кеширования с монго или кассандра, они уже бывают быстрыми. Я не рекомендую simpledb, он также блокирует вас до Amazon, как вы сказали.
Если вы используете С#, java или scala, вы можете написать интерфейс и реализовать его для mongo, mysql, cassandra или чего-нибудь еще для уровня доступа к данным. Это проще в динамических языках (например, rub, python, php). Вы можете написать провайдера для двух из них, если хотите, и можете изменить хранилище, возможно, во время выполнения, только с изменением конфигурации, они все возможны. Разработка с mongo, cassandra и simpledb проще, чем база данных, и они свободны от схемы, это также зависит от используемой клиентской библиотеки/соединителя. Самый простой - это манго. В кассандре есть только один указатель на таблицу, поэтому вам нужно управлять другими индексами самостоятельно, но с добавлением 0,7 выпуска вторичных индексов cassandra будет возможно, как я знаю. Вы также можете начать с любого из них и заменить его в будущем, если вам нужно.
Я думаю, у вас есть как вопрос времени, так и скорости.
MongoDB/Cassandra будут намного быстрее, но вам нужно будет инвестировать $$$, чтобы заставить их двигаться. Это означает, что вам нужно запустить/настроить экземпляры сервера для всех них и выяснить, как они работают.
С другой стороны, вам не нужно платить за "транзакцию" напрямую, вы просто платите за оборудование, которое, вероятно, более эффективно для крупных служб.
В Cassandra/MongoDB сражайтесь здесь, что вы найдете (на основе тестирования, с которым я лично занимаюсь в течение последних нескольких дней).
Cassandra:
MongoDB:
Честно говоря, учитывая время настройки, необходимое для наших 10-х ГБ данных, мы отправились вместе с MongoDB на наш конец. Я могу представить, используя SimpleDB для "должны получить эти запущенные" случаи. Но настройка node для запуска MongoDB настолько смехотворно проста, что может стоить пропустить маршрут "SimpleDB".
В терминах DAO уже имеется множество библиотек для Mongo. Рамка Thrift для Cassandra хорошо поддерживается. Вероятно, вы можете написать простую логику для абстрагирования соединений. Но сложнее абстрагироваться от вещей, более сложных, чем простой CRUD.
Теперь через 5 лет нетрудно настроить Mongo на любой ОС. Документация легко следовать, поэтому я не вижу, как Монго как проблема. Другие ответы затрагивали вопросы масштабируемости, поэтому я постараюсь решить вопрос с точки зрения разработчика (какие ограничения имеют каждая система):
Я буду использовать S для SimpleDB и M для Mongo.
Одна из самых важных вещей, которую вы должны учитывать, это то, что SimpleDB имеет очень рудиментарный язык запросов. Даже базовые вещи, такие как group by, sum average, distinct, а также обработка данных не поддерживаются, поэтому функциональность на самом деле не намного богаче, чем Redis/Memcached. С другой стороны, Mongo поддерживает богатый язык запросов.