Гибридная система БД: NoSQL для данных, SQL для отношений. Лучшая практика?

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

Я делаю живую систему голосования.

Мне комфортно работать с SQL и MongoDB, так что это почти не фактор решения (хотя я больше склоняюсь к структуре MongoDB и JS):

Но из всего, что я читал в Интернете, мне все еще кажется неудобным мое решение.

Что я хочу сделать, так это совместить преимущество обоих:

Наличие noSQL документов для объектов (пользователи, элементы, комментарии и т.д.)
Наличие таблиц SQL для отношений (таблицы User-Items, User-Comments и т.д.)
Дублирование результатов голосования в документе noSQL всякий раз, когда есть голосование или регулярный интервал (чтобы получить скорость также при отображении результатов голосования)

Я вижу следующие преимущества:

При запросе документа (например, пользователя для отображения его профиля) у меня есть все преимущества NoSQL (скорость, все в одном месте, гибкость схемы и т.д.).
При выполнении статистики (например, количество голосов) у меня есть все преимущества SQL.
Параллелизация: я могу получить голосование в SQL и документах в режиме aSync.
Читайте быстро, напишите медленно (и в моем случае это не имеет значения)
Отношения целостности всегда сохраняются

Мои вопросы:

Это хорошая практика? Веб выглядит довольно застенчивым.
Я оптимизирую арахис, даже при высокой нагрузке на БД? (сравнение выборки документов с полным SQL и запросов, таких как select * from table, где primary_key = XXX)

Ответ 1

Если единственная причина, по которой вы хотите использовать базу данных NoSQL вместе с RDBMS, - это увеличить скорость и гибкость, я бы предложил вместо этого использовать кеширующий сервер (например, Memcache). Вы можете создать документ/результат с помощью операторов sql и сохранить его, используя одно ключевое значение в memcache для его получения позже. Его намного проще реализовать, чем сказать MongoDB. Но это, конечно, зависит от ваших требований, если вы действительно хотите только искать документы, используя ключ или планируете использовать более сложные запросы для своих документов.

Ответ 2

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

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

Например, знание того, что данный пользователь идентифицирован определенным идентификатором, будет совместно использоваться вашей системой NoSQL и вашей базой данных. Если одна система удаляет этого пользователя, другая остается в несогласованном состоянии. Данный профиль пользователя будет разделен на две системы, и у них не будет полной картины; вам понадобится много кода синхронизации для ведения домашнего хозяйства.

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

Теперь у вас есть две точки сбоя - если сбой базы данных NoSQL или SQL, вся ваша система прерывается. И отказ может не означать сбой - это может также означать проблемы с производительностью или проблемы с обновлениями или проблемы с резервными копиями.

Для программных решений нередко есть несколько систем, каждая из которых владеет частью данных, разделение обычно осуществляется по линиям бизнес-домена (система CRM знает ваш профиль, платежную систему, данные вашей кредитной карты, система электронной торговли знает, что вы заказали); разделение подразделения по техническим линиям создало бы сложную архитектуру с несколькими точками отказа.

Я не думаю, что преимущества перевешивают эти недостатки.

Ответ 3

Я хотел бы выбросить еще одно предложение для моделирования объектов и отношений, которые будут масштабироваться.

Некоторая пища для размышлений:

Как вы сказали, моделируйте объекты/объекты в базе данных документов, такие как MongoDB.
Сохраните отношения в базе данных графа, такой как Titan или Neo4j. Эти системы более подходят, на мой взгляд, для хранения сложных отношений. Вы можете легко совершать обходы по многим сложным отношениям, а затем, когда вы найдете целевой график node/vertex на графике, вы можете загрузить документ из Mongo.
Рассмотрим что-то вроде Riak, который является хранилищем документов NoSQL, который также имеет ссылки между документами (отношениями). Они рекомендуют не создавать слишком сложные отношения, но возможно связать документы без необходимости в другой системе.