Является ли MongoDB подходящей БД для сайта сообщества?

Question

Я создаю сайт сообщества с Node.JS и Express, и почти все экспресс-учебники или примеры используют MongoDB, поэтому я проверил это.Единственная БД, которую я использовал до сих пор, - это MySQL, но я не очень хорошо знаком с ней, поэтому мне не мешало бы читать в MongoDB.Mongo выглядит довольно красиво, и модель документа может быть полезной.И с мангустом это легко использовать.Но у меня есть несколько вопросов, поэтому я не трачу много времени на изучение использования MongoDB, если оно совсем не подходит:

1. Я читал, что MongoDB ненадежен, если выиспользуйте его только на одном компьютере, и вы можете столкнуться с потерей данных.Это правильно?Проект не такой большой, что я мог бы позволить себе еще один сервер, и потеря данных совершенно бесполезна!Представьте, что некоторые сообщения на форуме просто исчезают.Но я думаю, что люди не будут использовать его, если это произойдет.

2. Сайт будет содержать форум для самостоятельной сборки, и я не уверен, что реляционная БД будет лучше.Однако вы можете сохранять темы со встроенными сообщениями и так далее.Но не знаю, как искать, так как Mongo не поддерживает полнотекстовый поиск.Как вы думаете?

3. Когда использовать встроенные документы в Mongo?Пример: пользователь может публиковать обновления статуса, как в Twitter.Сохраните ли вы эти обновления в пользовательском документе?Может быть много обновлений.Или документ на обновление и связать его с идентификатором пользователя?3.1 А как сделать запрос по нескольким документам?Вы хотите получить последние 10 обновлений статуса своих друзей.Вы можете сделать это с JOIN в MySQL.

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

5. Как вы обрабатываете состояние гонкив мангуст?Вы загружаете документ из базы данных, редактируете что-то и сохраняете его позже.Но, может быть, это уже изменилось за это время.

Answer 1

Чтобы ответить на каждый вопрос в отдельности:

1. Нет, это больше не так.В более старых версиях MongoDB не было журналирования, но в текущих версиях они есть, а в версии 2 он активирован по умолчанию.Тем не менее, вы должны использовать SafeMode на уровне драйвера, который гарантирует, что связь между драйвером и базой данных была успешной.

2. Встроенные сообщения и темы могут быть не лучшим выбором.Мы создали похожую вещь, и мы используем плоскую коллекцию, в которой каждое сообщение хранит ParentId и ParentThreadId.Есть плюсы и минусы для встраивания, но аргументы для нашего решения были:

   a) Часто мы хотим получить только самые последние комментарии по всему сайту или n самые последние комментариив заданном потоке, оба из которых не могут быть выполнены с использованием встроенных документов.

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

   в) Как указывает Джо, вам придется обрабатывать полнотекстовый поиск в другомsystem.

3. Встроенные документы не очень подходят, если у вас много обновлений, потому что контейнер (элемент коллекции, содержащий встроенные объекты) будет расти.Когда он будет расти, MongoDB придется перераспределить его, что может занять больше времени и фрагментировать данные.

   3 (a).Для обновления статуса друзей, использование стратегии разветвления имеет смысл.Я ответил на аналогичный вопрос вчера .

4. Не использовать числа с автоматическим приращением.По умолчанию это некорректный дизайн, потому что он не очень хорошо работает в распределенной среде.Для БД не имеет значения, хранит ли он int со значением 0x00000001 или один со значением 0xfa9ac7335.Нет смысла держать цифры маленькими.Я бы пошел с Монго ObjectId или Guid / UUID.Первый также содержит отметку времени между прочим.

5. Я не использовал мангуст, но в целом существуют типичные стратегии пессимистических и оптимистических блокировок.

Answer 2

1. По умолчанию записи MongoDB запускаются и забываются, поэтому, если что-то пойдет не так, есть вероятность потери данных. Вы можете использовать SafeMode, который дает вам ответ, если запись была успешной или нет, а затем обрабатывать ее любым удобным для вас способом. Сказав, что я не испытал никаких потерянных данных сам. Для нескольких серверов будет использоваться репликация, которая используется для восстановления после отказа, если один узел выходит из строя, а другой автоматически назначается главным.

2. Если вы хотите полнотекстовый поиск, вы не сможете сделать это с Mongo. Вы можете маркировать каждое слово в посте и сохранять каждое слово во встроенном массиве в документе, который будет проиндексирован, вы можете запросить каждое из этих слов. Проблема в том, что тогда у вас нет релевантности. Вы можете встроить некоторую логику релевантности с помощью Map Reduce, но это замедлит ваш запрос. Если вы действительно хотите быстрый полнотекстовый поиск, вам стоит взглянуть на SOLR или Elastic Search.

3. Лично я не буду хранить обновления статуса во встроенном документе, я бы поместил их все в отдельную коллекцию с идентификатором пользователя. В Монго нет объединений, поэтому вам придется выполнить два запроса: один для получения идентификаторов ваших друзей, другой для получения обновлений статуса. В зависимости от размера вашей коллекции при наличии правильных индексов это будет очень быстро, даже если это два запроса.

4. Я не думаю, что вы можете использовать целочисленное значение с автоинкрементом для идентификатора на уровне Монго. Вы можете сами обработать это в приложении, так как вы можете использовать любое поле для идентификатора. При добавлении нового документа вам нужно будет запросить коллекцию, чтобы получить максимальный идентификатор и увеличить его. Идентификатор объекта Mongo состоит из идентификатора компьютера, идентификатора процесса, метки времени и некоторой случайности для создания уникального ключа.

5. Я не знаком с Мангустом.

Answer 3

Сравнение баз данных NoSQL с указанием их сильных и слабых сторон и типов проектов, для которых они лучше всего подходят: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis