Использование MongoDB против MySQL с большим количеством полей JSON?

Существует приложение для микроблогов. Два основных базовых хранилища баз данных: MySQL или MongoDB.

Я планирую денормализовать массу данных I.e. Голосование, сделанное по почте, хранится в таблице для голосования, а также счет увеличивается в таблице главных должностей. Есть и другие действия, связанные с этим сообщением (например, "Голос" ).

Если я использую MySQL, некоторые данные лучше подходят для JSON, чем для фиксированной схемы, для более быстрого поиска.

например.

POST_ID   |  activity_data

213423424 | { 'likes': {'count':213,'recent_likers' :
             ['john','jack',..fixed list of recent N users]} , 'smiles' : 
             {'count':345,'recent_smilers' :
             ['mary','jack',..fixed list of recent N users]}  }

Существуют и другие компоненты приложения, где предлагается использование JSON. Итак, чтобы обновить поле JSON, последовательность:

Прочитайте JSON в python script.
Обновите JSON
Сохраните JSON обратно в MySQL.

Это была бы единственная операция в MongoDB с атомными операциями типа $push, $inc, $pull и т.д. Также документальная структура MongoDB хорошо подходит для моих данных.

Мои соображения при выборе хранилища данных.

Относительно MySQL:

Стабильный и знакомый.
Резервное копирование и восстановление легко.
Некоторые будущие изменения схемы можно избежать, используя некоторые поля в качестве схемы JSON.
Возможно, придется сначала использовать слой memcached.
JSON blobs будет статичным в некоторых таблицах, таких как основные сообщения, однако будет обновляться в некоторых других таблицах, таких как "Голоса и пожелания".

Относительно MongoDB:

Лучше подходит для хранения схемы меньше данных в качестве документов.
Кэширование можно было бы избежать до более позднего этапа.
Иногда приложение может интенсивно писать записи, MongoDB может работать лучше в тех точках, где небезопасные записи не являются проблемой.
Не уверен в стабильности и надежности.
Не уверен, насколько легко выполнить резервное копирование и восстановление.

Вопросы:

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

Стабильность, резервное копирование, моментальные снимки, восстановление, более широкое внедрение. Ядерность базы данных. - причины, указывающие на меня использовать MySQL в качестве RDBMS + NoSql, даже если хранилище документов NoSQL может служить моей цели лучше.

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

ОБНОВЛЕНИЕ. Начиная с MySQL 5.7, MySQL поддерживает богатый собственный тип данных JSON, который обеспечивает гибкость данных, а также богатый запрос JSON.

https://dev.mysql.com/doc/refman/5.7/en/json.html

Ответ 1

Итак, чтобы прямо ответить на вопросы...

Можно ли выбрать mongodb, если половина данных является схематичной и хранится как JSON при использовании MySQL?

Неплохое хранилище, безусловно, является веской причиной для работы с MongoDB, но, как вы уже указали, довольно легко хранить JSON в СУБД. Сила MongoDB находится в богатых запросах от хранения без схем.

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

С MongoDB транзакций нет. Но операции почти всегда могут быть структурированы таким образом, чтобы обеспечить получение атомных обновлений. Обычно это связано с некоторыми драматическими сдвигами от парадигм SQL, но, на мой взгляд, они довольно очевидны после того, как вы перестали пытаться заставлять объекты в таблицы. По крайней мере, многие другие люди столкнулись с теми же проблемами, с которыми вы столкнетесь, и монгольское сообщество имеет тенденцию быть достаточно открытым и вокальным в отношении проблем, которые они преодолели.

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

В разделе "safe write" я предполагаю, что вы имеете в виду возможность включить автоматическую "getLastError()" после каждой записи. У нас очень тонкая оболочка над DBCollection, которая позволяет нам осуществлять мелкозернистый контроль, когда вызывается getLastError(). Однако наша политика основана не на том, как "важные" данные, а скорее на то, будет ли код, следующий за запросом, ожидать, что любые изменения будут немедленно видны в следующих чтениях.

Вообще говоря, это все еще плохой индикатор, и мы вместо этого перешли на findAndModify() для того же поведения. В случае, когда мы все еще явно вызываем getLastError(), это когда база данных скорее всего отклонит запись, например, когда мы вставляем() с _id, который может быть дубликатом.

Насколько легко отслеживать, создавать резервные копии и восстанавливать Mongodb по сравнению с mysql? Нам нужно планировать периодические резервные копии (скажем, ежедневно) и легко восстанавливать их в случае катастрофы. Какие лучшие варианты у меня есть с mongoDb, чтобы сделать его безопасным для приложения?

Боюсь, я не могу сказать, эффективна ли наша политика резервного копирования/восстановления, поскольку нам еще не удалось восстановить ее. Мы следим за рекомендациями MongoDB для резервного копирования; @mark-hillick проделал большую работу по их обобщению. Мы используем набор реплик, и мы перенесли версии MongoDB, а также представили новые члены реплики. До сих пор у нас не было простоев, поэтому я не уверен, что смогу хорошо говорить по этому поводу.

Стабильность, резервное копирование, моментальные снимки, восстановление, более широкое внедрение. Долговечность базы данных - это причины, указывающие на то, что я использую MySQL как RDBMS + NoSql, хотя хранилище документов NoSQL может лучше служить моей цели.

Таким образом, по моему опыту, MongoDB предлагает хранить данные схемы с набором примитивов запросов, достаточно богатыми, что транзакции часто могут быть заменены атомными операциями. Было трудно отучить опыт SQL на 10+ лет, но каждая проблема, с которой я столкнулась, была напрямую решена сообществом или 10gen. Мы не потеряли данные или имели время простоя, которое я могу вспомнить.

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

Я не работаю для 10gen, но я очень благодарен тем, кто это делает.

Ответ 2

Я не буду комментировать сравнения (я работаю для 10gen и не считаю нужным это делать), однако я отвечу на конкретные вопросы MongoDB, чтобы вы могли лучше принять решение.

Back-Up

Документация здесь является очень тщательной, охватывающей многие аспекты:

Методы блочного уровня (LVM делает это очень легко, и довольно много людей делают это)
С/Без ведения журнала
Снимки EBS
Общие снимки
Репликация (технически не резервное копирование, однако, множество наборов реплик для народного использования для их избыточности и резервного копирования - не рекомендуется, но это делается)

До недавнего времени не было эквивалента MongoDB mylvmbackup, но хороший парень написал один:) В его словах

Ранние дни: это просто прославленная оболочка script и требует дополнительной проверки ошибок. Но уже это работает для меня, и я решил, что разделю радость. Сообщения об ошибках, исправления и предложения приветствуются.

Получите копию здесь.

Восстановление

Форматы и т.д.

mongodump полностью зарегистрирован здесь и mongorestore здесь.

mongodump не будет содержать индексы, но содержит коллекцию system.indexes, поэтому mongorestore может перестроить индексы при восстановлении файла bson. Файл bson - это фактические данные, тогда как mongoexport/mongoimport не являются безопасными для типов, поэтому может быть что угодно (с технической точки зрения):)

Мониторинг

Документировано здесь.

Мне нравится Cacti, но afaik, шаблоны Cacti не справились с изменениями в MongoDB и поэтому полагаются на старый синтаксис, поэтому post 2.0.4, я считаю, что есть проблемы.

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

Я слышал о некоторых людях, которые смотрели на Zappix, но я никогда не использовал его, поэтому не могу комментировать.

Кроме того, вы можете использовать MMS, который является бесплатным и размещается снаружи. Ваши экземпляры MongoDB запускают агент, и один из этих агентов обменивается данными (используя код Python) на https до mms.10gen.com. Мы используем MMS для просмотра всех статистических данных о производительности на экземплярах MongoDB, и это очень полезно из широкого обзора на высоком уровне, а также предлагает возможность развернуть. Он прост в установке, и для этого вам не нужно запускать какое-либо оборудование. Многие клиенты запускают его, а некоторые дополняют его как Cacti/Nagios.

Информацию о MMS можно найти здесь (это очень подробный, включающий документ).

Ответ 3

Одним из недостатков решения mysql с сохраненным json является то, что вы не сможете эффективно искать данные json. Если вы храните все в mongodb, вы можете создавать индексы и/или запросы для всех ваших данных, включая json.

Mongo пишет работу очень хорошо, и на самом деле единственное, что вы теряете в сравнении с mysql, это поддержка транзакций, и, таким образом, возможность отката multipart сохраняет. Однако, если вы можете совершать свои изменения в атомных операциях, тогда нет проблемы безопасности данных. Если вы реплицированы, mongo обеспечивает "в конечном итоге последовательное" обещание, так что рабы в конечном итоге будут зеркально отображать мастера.

Mongodb не обеспечивает собственное принудительное выполнение или каскадирование определенных конструкций db, таких как внешние ключи, поэтому вам нужно управлять ими самостоятельно (например, с помощью композиции, которая является одной из мощностей монго) или с использованием dbrefs.

Если вам действительно нужна поддержка транзакций и надежные "безопасные" записи, но все же желайте гибкости, предоставляемой nosql, вы можете рассмотреть гибридное решение. Это позволит вам использовать mysql в качестве основного хранилища сообщений, а затем использовать mongodb в качестве вашего магазина "schemaless". Вот ссылка на документ, обсуждающий гибридные решения mongo/rdbms: http://www.10gen.com/events/hybrid-applications Статья взята с сайта 10gen, но вы можете найти другие примеры просто выполнив быстрый поиск в Google.