Какая база данных подходит моему приложению mysql или mongodb? используя Node.js, Backbone, Now.js

Ответ 1

С MongoDB вы можете просто хранить объекты JSON и получать их полностью сформированные, поэтому вам не нужен уровень ORM, и вы тратите меньше времени на процессор, переводя свои данные обратно и вперед. Разработчики MongoDB также сделали горизонтальное масштабирование базы данных более высоким приоритетом и позволяют запускать произвольный код Javascript для предварительной обработки данных на стороне БД (позволяя фильтрацию данных с учетом размера карты).

Но вы теряете некоторые из этих выгод: вы не можете присоединяться к записям. Фактически, структуру JSON, которую вы храните, может выполняться только с помощью соединений в SQL, но в MongoDB у вас есть только одна структура для ваших данных, тогда как в SQL вы можете запросить по-другому и получить ваши данные в альтернативных вариантах намного проще, поэтому, если вы необходимо сделать много аналитики в вашей базе данных, MongoDB сделает это сложнее.

Язык запросов в MongoDB является, по моему мнению, "более грубым", чем SQL, отчасти потому, что он менее знаком, а отчасти потому, что функции запроса "чувствуют" беспорядочно собраны, частично, чтобы сделать его действительным JSON, а частично потому, что там это буквально несколько способов сделать одно и то же, а некоторые - более старые способы, которые не так полезны или регулярно отформатированы, как другие. И там добавлена ​​сложность типов массивов и под-объектов над SQL-простейшей конструкцией на основе строк, поэтому синтаксис должен иметь возможность обрабатывать запросы для массивов, которые содержат некоторые из значений, которые вы определили, содержат все значения, которые вы определили, содержат только указанные вами значения и не содержат ни одного из значений, которые вы определили. Те же различия применяются к объектным ключам и их значениям, и это затрудняет понимание синтаксиса запроса. (И хотя я вижу необходимость в крайних случаях, параметр запроса $where, который принимает функцию javascript, которая запускается на каждой записи данных и возвращает логическое значение, является песней Siren, потому что вы можете легко определить, какие объекты вы хотите вернуться или нет, но он должен запускаться на каждой записи в базе данных, никакие индексы не могут использоваться.)

Итак, это зависит от того, что вы хотите сделать, но, поскольку вы говорите это для клона Google Docs, вы, вероятно, не заботитесь о каком-либо представлении, а о представлении документа, и вы, вероятно, будете только запрашивать на основе идентификатора документа, имени документа или идентификатора/имени владельца, ничего сложного в запросе.

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

Ответ 2

Я также боролся с этим выбором, глядя на шумиху, созданную с помощью MongoDB, для задач, для которых он не был создан. Итак, мои 2 цента:

• Сохранение и извлечение иерархических объектов, возможно, что ваши документы, проще в MongoDB, как говорит Дэвид. Это становится более сложным, если вы хотите хранить документы размером более 16 Мб, хотя ответ MongoDB - GridFS.

• Упорядочить документы в папках, группах, отслеживать, какой пользователь владеет, какие документы и кто он/она предоставил им доступ, определенно проще с MySQL - у вас есть преимущество мощных SQL-запросов с объединениями и т.д., встроенных в оптимизации EXPLAIN, триггерах, функциях, хранимых процедурах и т.д. MongoDB нигде не близок.

Итак, что мешает вам использовать MySQL для организации документов и MongoDB для хранения одной коллекции документов, идентифицированных идентификатором (или несколькими коллекциями - по одному для каждого типа документа)? Мне кажется, лучший выбор и использование двух баз данных в одном приложении - это не проблема, действительно.

MySQL будет хранить пользователей, группы, папки, разрешения - все, что вам нравится, и для каждого документа будет храниться ссылка на коллекцию и идентификатор документа (у MongoDB есть специальный формат - DBRefs). MongoDB будет хранить сами документы в коллекциях, если они все меньше 16 МБ, или предварительные просмотры и метаданные документов в коллекциях и все документы в GridFS.

Ответ 3

Давид дал хороший ответ. Несколько вещей, чтобы добавить к нему.

• Возможность гибкого природоохранного разрешения MongoDB обеспечивает легкую гибкую/итеративную разработку.
• MongoDB, как node.js, является асинхронным по своей природе и очень хорошо работает в асинхронных средах.
• Mongoose - хороший ODM (object document mapper), который делает работу с MongoDB с node.js очень естественной. В отличие от ORM это очень тонкий слой.

Для функций Google Doc, гибкость и очень богатая структура данных, предоставляемая MongoDB, выглядит намного лучше.

Вы можете найти несколько хороших примеров сообщений, выполнив поиск mongoose, node и MongoDB.

Здесь тот, который также использует backbone.js и выглядит хорошо http://mattkopala.com/blog/2012/02/12/getting-started-with-nodejs/