Стратегический вопрос: смешивание реляционных и нереляционных БД? - PullRequest
13 голосов
/ 09 июля 2010

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

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

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

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


PS: Есть идеи, если такое сочетание хорошо работает с Spring и Hibernate / JPA?

Ответы [ 3 ]

14 голосов
/ 09 июля 2010

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

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

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

Он резюмирует это так:

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

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

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

3 голосов
/ 09 июля 2010

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

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

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

0 голосов
/ 08 октября 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...