Когда следует использовать MongoDB и MySQL вместе?

Варианты использования:

Вы можете использовать MySQL в качестве системы отчетности, поддерживающей MongoDB

Вы можете использовать MongoDB в качестве back-end для архивирования целых записей для MySQL.

Вы можете использовать MongoDB для хранения вещей, которые требуют нулевых транзакций, и MySQL для транзакционных элементов. В Mongo лучше использовать сессионный ключ, например, с индексом TTL.

Вы можете использовать Mongo для наиболее частых запросов и копировать данные в базу данных MySQL.

Вы можете использовать Mongo в основном для чтения и переносить записи из MySQL в Mongo.

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

Любой запрос, где для ответа требуется сравнение записей с записями, а не записей со значениями, должен выполняться в MySQL. И наоборот.

Таким образом, вы можете иметь пользовательскую таблицу в любой ситуации, но какой вариант вы выберете, зависит от ваших планируемых/ожидаемых запросов.

Для полной ясности. Между этими двумя базами данных у вас есть два вида дизайна вокруг записи. В одной из них деловая запись хранится как единое целое (иногда называемое агрегатом), а в другой - запись сегментируется на компоненты. Компонентная модель означает, что при каждом запросе компоненты, по сути, частично или полностью собираются заново.

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

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

В то же время, сила реляционной системы заключается в том же сегментировании записи. С помощью такой сегментации вы можете ответить на любое количество вопросов о ваших данных.

Эти два средства вместе могут составить мощную комбинацию.

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

Я следую модели, которую используют многие люди: создаю набор архетипических пользователей и решаю, что им нужно. Разработчик, обычный пользователь, составитель отчетов и так далее. Затем посмотрите, что им нужно делать. Пользователю нужно создать учетную запись, какие CRUD-операции будут необходимы? Пользователю нужно сбросить пароль, какие CRUD-операции будут необходимы?

И так далее.

Надеюсь, все это поможет.