MongoDB против Кассандры [закрыто]
Я думаю, что это то, что вы ищете Mongoose Strict
option: strict
Строгая опция (включена по умолчанию), гарантирует, что значения, добавленные в наш экземпляр модели, которые не были указаны в нашей схеме, не сохраняются в db.
Примечание. Не устанавливайте значение false, если у вас нет веских причин.
var thingSchema = new Schema({..}, { strict: false });
var Thing = mongoose.model('Thing', thingSchema);
var thing = new Thing({ iAmNotInTheSchema: true });
thing.save() // iAmNotInTheSchema is now saved to the db!!
4 ответа
Много чтений в каждом запросе, меньше обычных записей
Обе базы данных хорошо работают при чтении, когда горячий набор данных помещается в память. Оба также делают упор на модели данных без соединения (и вместо этого поощряют денормализацию), и оба предоставляют индексы для документов или строк , хотя индексы MongoDB в настоящее время более гибкие.
Механизм хранения Cassandra обеспечивает запись в постоянное время независимо от того, насколько велик ваш набор данных. Запись более проблематична в MongoDB, отчасти из-за механизма хранения на основе b-дерева, но больше из-за многоступенчатой блокировки , которую он делает.
Для аналитики MongoDB предоставляет настраиваемую реализацию сопоставления / сокращения; Cassandra обеспечивает встроенную поддержку Hadoop, в том числе для Hive (хранилище данных SQL, построенное на Hadoop map / reduce) и Pig (специфичный для Hadoop язык анализа, который, по мнению многих, лучше подходит для сопоставить / уменьшить рабочие нагрузки, чем SQL). Cassandra также поддерживает использование Spark .
Не беспокоиться о «массовой» масштабируемости
Если вы смотрите на один сервер, MongoDB, вероятно, подойдет лучше. Для тех, кто больше озабочен масштабированием, архитектура Cassandra без единой точки отказа будет проще в настройке и более надежна. (Глобальная блокировка записи MongoDB также имеет тенденцию становиться более болезненной.) Cassandra также дает гораздо больший контроль над тем, как работает ваша репликация, включая поддержку нескольких центров обработки данных.
Больше заботит простая установка, обслуживание и код.
И то, и другое несложно настроить, с разумными готовыми настройками по умолчанию для одного сервера. Cassandra проще настроить в многосерверной конфигурации, поскольку здесь нет узлов со специальной ролью, о которых нужно беспокоиться.
Если вы сейчас используете большие двоичные объекты JSON, MongoDB безумно хорошо подходит для вашего варианта использования, учитывая, что он использует BSON для хранения данных. Вы сможете иметь более богатые и запрашиваемые данные, чем в вашей нынешней базе данных. Это была бы самая значительная победа для Монго.
Я вчера видел презентацию на mongodb. Я могу с уверенностью сказать, что установка была «простой», достаточно просто распаковать ее и запустить. Выполнено.
Я считаю, что и mongodb, и cassandra будут работать практически на любом обычном Linux-оборудовании, поэтому вы не найдете особых препятствий в этой области.
Я думаю, что в этом случае, в конце концов, все будет сводиться к тому, с чем вы лично чувствуете себя более комфортно и какой набор инструментов вам больше нравится. Что касается презентации на mongodb, докладчик указал, что набор инструментов для mongodb был довольно легким и что не было много (они сказали, что действительно) инструментов, похожих на то, что доступно для MySQL. Это, конечно, был их опыт, так что YMMV. Одна вещь, которая мне нравилась в mongodb, заключалась в том, что для нее, казалось, было много языковой поддержки (Python и .NET - это два, которые я в основном использую).
Список сайтов, использующих mongodb, довольно впечатляющий , и я знаю, что твиттер только что перешел на использование cassandra.
Я не использовал Cassandra, но я использовал MongoDB и считаю ее потрясающей.
Если вам нужна простая установка, то это то, что нужно: Вы просто распаковываете MongoDB и запускаете демон mongod, и все... он работает.
Очевидно, что это только начальный вариант, но для начала все просто.
Я активно использовал MongoDB (последние 6 месяцев), создавая иерархическую систему управления данными, и могу поручиться как за простоту установки (установить, запустить, использовать!), Так и за скорость. Если вы внимательно подумаете об индексах, он может просто кричать, если говорить о скорости.
Я так понимаю, что Cassandra, благодаря ее использованию с крупномасштабными проектами, такими как Twitter, имеет лучшую функциональность масштабирования, хотя команда MongoDB работает над обеспечением паритета. Я должен отметить, что я не использовал Кассандру после стадии пробного запуска, поэтому я не могу говорить о деталях.
Настоящим свингером для меня, когда мы оценивали базы данных NoSQL, были запросы - Cassandra, по сути, просто гигантское хранилище ключей / значений, а запросы немного неудобны (по крайней мере, по сравнению с MongoDB), так что для производительности вам нужно ' Придется дублировать довольно много данных в виде ручного индекса. MongoDB, с другой стороны, использует модель «запрос по примеру».
Например, предположим, что у вас есть Коллекция (на языке MongoDB для эквивалента таблицы RDMS), содержащая пользователей. MongoDB хранит записи как документы, которые в основном представляют собой двоичные объекты JSON. например:
{
FirstName: "John",
LastName: "Smith",
Email: "john@smith.com",
Groups: ["Admin", "User", "SuperUser"]
}
Если вы хотите найти всех пользователей по имени Смит, у которых есть права администратора, вы просто создадите новый документ (в консоли администратора, используя Javascript, или в рабочей среде, используя язык по вашему выбору):
{
LastName: "Smith",
Groups: "Admin"
}
... а затем запустите запрос. Вот и все. Добавлены операторы для сравнения, фильтрации RegEx и т. Д., Но все это довольно просто, и документация на основе Wiki довольно хороша.