Кассандра против Amazon SimpleDB - PullRequest
       16

Кассандра против Amazon SimpleDB

14 голосов
/ 03 декабря 2009

Я работаю над приложением, в котором размер данных и запросы SQL будут тяжелыми. Я думаю между Кассандрой или Амазонкой SimpleDB. Подскажите, пожалуйста, какой вариант больше подходит для такого сценария?

Индексирование данных Cassandra выглядит лучше, чем Amazon simpleDB, но у запросов меньше вариантов по сравнению с Amazon SimpleDB. Кажется, Amazon SimpleDB имеет высокие скорости ввода-вывода.

Мало кто из сложных вариантов использования - это пользовательские действия с различными фильтрами, которые пользователь может установить для сужения некоторых интересных действий.

Если вы считаете, что есть что-то более чистое и лучшее решение, кроме этих двух, предложите.

Ответы [ 2 ]

9 голосов
/ 10 декабря 2009

SimpleDB может масштабироваться только с помощью шардинга, имеет ограничение размера данных 10 ГБ на таблицу и производительность запросов параллельна количеству записей (например, плохо, если у вас 1 миллион записей) И хранилище данных Google работает медленнее, чем Simpledb. Cassandra гораздо более масштабируема, сайты с высоким трафиком начали использовать ее, нет ничего лучше бесплатного, если вам нужны высокие скорости записи с большими объемами данных. Кассандровский опрос

Если ваше отношение чтения / записи составляет что-то вроде% 90 для чтения и% 10 для записи, то лучше использовать терракоту или бесконечность с postgres. Для postgresql есть несколько бесплатных вариантов кластеризации, но ни один из них не является зрелым (в основном прототипы).

Другим вариантом является шардинг. Hiberntae и NHibernate имеют поддержку шардера. Вы можете использовать их с postgres или mysql, но вы теряете соединения.

Привет

4 голосов
/ 06 мая 2011

Следует учесть, что любая нестандартная настройка nosql (Cassandra, mongodb, redis и т. Д.) Будет на лигах быстрее при малой громкости, чем простая БД, но вы берете на себя всю нагрузку на всю конфигурацию управления сервером, аварийное восстановление, резервное копирование и т. д.

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

Простые базы данных (и эквивалентные хранилища данных) снимают эту проблему с вас при масштабировании.

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

...