SQL и NoSQL в одном проекте

Хотелось бы узнать мнению знающих людей по поводу скрещивания в одном проекте SQL решения (MySQL) и NoSQL (MongoDB). С одной стороны как-то не по феншую использовать и то и другое сразу. Но с другой стороны — отдельно каждое решение не полностью удовлетворяет потребностям.

С одной стороны в проекте надо использовать очень большое кол-во «документов» с переменной структурой (разное кол-во полей (поиск по которым будет обязателен)) и разного размера (от 200 байт до 200 килобайт в среднем) и при этом требуется большая скорость работы с ними. По этому MongoDB очень хорошо подходит для этого. К тому же довольно легкая организация кластера для увеличения скорости работы и отказоустойчивости (Replica Sets + Шардинг)

С другой стороны в проекте требуется использовать много четко структурированных данных, которые очень тесно связаны друг с другом. И хранить их в не реляционных БД просто не целесообразно и довольно неудобно извлекать информацию(восстановление связей может потребовать сотни подзапросов). А всё что связано с удалением, вообще вызовет очень много неудобств. При этом, этих данных — минимальное кол-во (по сравнению с кол-вом «документов»). Так что вся работа без проблем может быть организована через один MySQL сервер.

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

Кто как считает, нужно ли использовать оба подхода сразу или всё же придумать что-либо другое? И кто-нибудь использовал подобное на практике?

P.S. Проект — обычный веб сервис, но должен выдерживать большую нагрузку и должен иметь хорошую горизонтальную масштабируемость.
  • Вопрос задан
  • 4058 просмотров
Пригласить эксперта
Ответы на вопрос 6
kvabr
@kvabr
>> С одной стороны как-то не по феншую использовать и то и другое сразу

Тут, просто нужно решить что для вас важнее — феншуй или таймлайн.
Ответ написан
Комментировать
@Dreammaker
По своему проекту скажу — делалось бы сейчас, делал бы только на MongoDB. Основная проблема — это поиск. Одновременно сделать поиск по одной базе и другой нельзя, а как искать пересечение данных? То есть, нам нужно, например, найти профили юзеров (SQL со связями) с красными носами и зелёными ушами (Mongo). В итоге нам нужно или делать или запрос в РСУБД, а потом по полученными id искать по монго с параметрами, или наоборот по найденными в монго параметрам искать в MySQL (или другой базе).

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

Сейчас поиск будет переезжать на более идеалогически кошерный сфинкс, но проект будет переписывать на полный MongoDB.
Ответ написан
@dborovikov
Возможно вы упускаете еще один фактор — killer feature многих реляционных баз (хоть это и не имеет отношения к классификации sql/nosql, но на практике это так) это поддержка ACID. Используя транзакционное и не транзакционное хранилище вместе вы в итоге имеете общее не транзакционное хранилище… Это единственно НО при использовании вашего подхода. Вообще советовать довольно сложно так как есть и такие варианты:

1) Использовать только MongoDB. Каки-никакие запросы он там имеет. И возможно на практике все окажется не так страшно, как вам кажется. К примеру «сотни-подзапросов» могут оказаться быстрее тяжелого sql-ника с джойнами.

2) Использовать только РСУБД. Хранение документов можно реализовать к примеру в виде XML. Многие базы, не знаю как MySQL, а Postgresql позволяет делать даже запросы с использованием XPath. Масштабирование делать ручками на клиенте с хранением мета-информации «где какой сет лежит» в каком-нибудь Riak-е.
Ответ написан
catlion
@catlion
> как-то не по феншую использовать и то и другое

Почему вы так думаете? Если потому, что есть два враждующих лагеря поклонников, то одни любят ломать копья и троллить, другие — работать.

Об этом, кстати, сказано и на сайте Монги www.mongodb.org/display/DOCS/Use+Cases
Ответ написан
k12th
@k12th
console.log(`You're pulling my leg, right?`);
Используют же memcache (тоже ведь key-value хранилище) вместе с РСУБД — просто каждое из хранилищ отвечает за свое, за то, с чем справляется лучше.
Ответ написан
Zelgadis
@Zelgadis
С одной стороны как-то не по феншую использовать и то и другое сразу
И сразу же читаем что означаем NOSQL. Потом берем свой мозг, ставим его на место и понимает, что для каждой задачи надо использовать свои инструменты.

С другой стороны в проекте требуется использовать много четко структурированных данных, которые очень тесно связаны друг с другом. И хранить их в не реляционных БД просто не целесообразно и довольно неудобно извлекать информацию(восстановление связей может потребовать сотни подзапросов).

Вы случайно не пытаетесь модель работы с РСУБД перенести на Document Oriented Databases?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы