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

Question

[darkslesh]

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

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

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

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

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

P.S. Проект — обычный веб сервис, но должен выдерживать большую нагрузку и должен иметь хорошую горизонтальную масштабируемость.

Comments

[darkslesh]

Хотя данные и разного вида, но всё же они зависимы друг от друга. т.е. некоторые поля таблиц связаны с определенными полями «документов». (К примеру идентификатор владельца документа, тип документа)

Answer 1

[kvabr]

>> С одной стороны как-то не по феншую использовать и то и другое сразу

Тут, просто нужно решить что для вас важнее — феншуй или таймлайн.

Answer 2

[Dreammaker]

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

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

Сейчас поиск будет переезжать на более идеалогически кошерный сфинкс, но проект будет переписывать на полный MongoDB.

Comments

[Zelgadis]

Посмотрите в сторону ElasticSearch, вот вам и поиск по нескольким источниками.

кошерный сфинкс
Почему все от него в таком восторге? Еще не встречал ресурса где поиск сфинксом работал так как надо. Тот же habrahabr тому пример.

Answer 3

[catlion]

> как-то не по феншую использовать и то и другое

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

Об этом, кстати, сказано и на сайте Монги www.mongodb.org/display/DOCS/Use+Cases

Comments

[darkslesh]

Спасибо почитаю.

Answer 4

[Константин Китманов]

Используют же memcache (тоже ведь key-value хранилище) вместе с РСУБД — просто каждое из хранилищ отвечает за свое, за то, с чем справляется лучше.

Answer 5

[Zelgadis]

С одной стороны как-то не по феншую использовать и то и другое сразу
И сразу же читаем что означаем NOSQL. Потом берем свой мозг, ставим его на место и понимает, что для каждой задачи надо использовать свои инструменты.

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

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

Comments

[darkslesh]

Да знаю я что NOSQL (Not Only SQL). Переносить не собираюсь, потому что это не целесообразно и неудобно. По этому и хотелось бы использовать сразу две системы.

[Zelgadis]

может вам тогда будет удобнее все в одном документе хранить, а через map-reduce вытягивать нужные значения?