Стратегический вопрос: смешивание реляционных и нереляционных БД?

Было много разговоров о контрреволюционных базах данных NoSQL, таких как Cassandra, CouchDB, Hypertable, MongoDB, Project Voldemort, BigTable и многие другие. На мой взгляд, самые сильные плюсы - это масштабируемость, производительность и простота.

Я серьезно подумываю предложить использовать некоторую нереляционную базу данных для нашего следующего проекта. Тем не менее, некоторые команды состоят из фанатиков СУБД, поэтому убедить жесткий переход в некоторых случаях невозможно только по эмоциональным причинам. Кроме того, когда дело доходит до сложных моделей данных, я лично все еще верю в силу РСУБД с их низкоуровневыми механизмами обеспечения согласованности.

Теперь вот мой вопрос: мне было интересно, может ли кто-нибудь серьезно рассмотреть возможность использования как РСУБД , так и нереляционной БД в новом проекте: сложная, но не критичная для производительности модель данных все равно будет реализована с использованием реляционная модель и БД, в то время как все критичные к производительности, но простые модели будут реализованы с нереляционным БД. Более того, такую ​​мягкую смену парадигмы будет гораздо легче продать некоторым высокоэмоциональным членам команды, чем жесткую.

Кто-нибудь порекомендовал бы такой подход? Или вы бы предпочли черный или белый, то есть реляционный или нереляционный подход? Все комментарии приветствуются!


P.S .: Есть идеи, хорошо ли работает такая путаница со Spring и Hibernate / JPA?


person Ta Sas    schedule 08.07.2010    source источник


Ответы (3)


Роб Конери недавно написал о своем опыте создания своего популярное веб-приложение TekPub с MongoDB и MySQL, подчеркивая сильные стороны обоих:

Высокочитаемый материал (информация об аккаунте, постановках и эпизодах) идеально подходит для таких вещей, как MongoDb. То, что произошло вчера, идеально подходит для реляционной системы.

На высоком уровне Роб разделяет данные своего приложения на две области: данные времени выполнения и исторические данные. Например, текущее состояние корзины покупок пользователя отлично подходит для хранения в MongoDB. Это объектный blob, который постоянно видоизменяется. Вести исторический учет того, что входило и выходило из корзины для покупок; когда это случилось; состояние проверки отлично подходит для реляционных табличных данных в MySQL.

Он резюмирует следующее:

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

Обновление май 2016 г. (6 лет спустя)

Это стало более актуальным только за последние 6 лет. Сейчас обычным явлением является то, что базы данных NoSQL используются в хранилищах транзакций, а традиционные реляционные базы данных - в основе аналитических баз данных.

person Rex M    schedule 08.07.2010
comment
Спасибо за вклад, отличная запись в блоге. - person Ta Sas; 09.07.2010
comment
Однако статьи больше нет. Кажется, как и все статьи о nosql в блоге Роба. Есть ли у вас источники приложений, которые работают более одного года и до сих пор довольны? Или лучшие источники, которые перешли с SQL только на комбинацию? - person Boris Callens; 26.08.2016
comment
@BorisCallens Я думаю, что микс стал более распространенным случаем. Большинство современных приложений в большинстве компаний, которые я наблюдал, считают само собой разумеющимся, что решение будет использовать несколько типов хранилищ данных. - person Rex M; 26.08.2016

Я использую оба. СУБД хороша для комплексного анализа, отчетов и данных, к которым по-разному обращаются несколько пользователей. NOSQL отлично подходит, когда я смотрю на данные с точки зрения одного пользователя. Я задаю себе вопрос: «Кто имеет доступ к этим данным?». Если ответ - 1 пользователь, я использую NOSQL для его хранения.

Конечно, бывают и другие случаи, когда это уместно, но это лишь один пример.

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

person Mike Sherov    schedule 08.07.2010

Нереляционные базы данных "ключ-значение" лучше всего использовать для хранения и кэширования больших двоичных объектов.

person Seun Osewa    schedule 08.10.2010