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

[dborovikov]

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

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

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

Comments

[darkslesh]

Пробовал реализовывать некоторые моменты на MongoDB, многие вещи довольно сложно реализовать в ней особенно если большая связанность таблиц. К тому же довольно сложно контролировать все связи. Если в РСУБД ON DELETE CASCADE решает все проблемы, то в монго будут проблемы. Если использовать и то и другое, то получается только контроль документа и всё.

[dborovikov]

on delete cascade тоже не всегда катит… Неплохое решение — логическое удаление корневых сущностей. Во-первых просто. Во-вторых если что-то не то задизейблится, можно восстановить. Эту же практику можно перенести и на монго.

Answer 4

[catlion]

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

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

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

Comments

[darkslesh]

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

Answer 5

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

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

Comments

[dborovikov]

С мемкешом чуть проще. Он не дает гарантий на сохранность записей, поэтому БД — всегда первичный источник информации, отсюда и пляшем. В итоге не нужно полностью согласовывать записи, достаточно инвалидировать. Согласовывать 2 персистентных хранилища гораздо сложнее.

Answer 6

[Zelgadis]

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

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

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

Comments

[darkslesh]

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

[Zelgadis]

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