Стратегическая проблема: смешивание реляционных и нереляционных db?
Было много разговоров о контрреволюционных базах данных NoSQL, таких как Cassandra, CouchDB, Hypertable, MongoDB, Project Voldemort, BigTable и так много других. Насколько мне известно, самыми сильными плюсами являются масштабируемость, производительность и простота.
Я серьезно подумываю предложить использовать некоторые нереляционные db для нашего следующего проекта. Тем не менее, некоторые команды включают в себя некоторых фанатиков РСУБД, поэтому убедительный жесткий переключатель может быть в некоторых случаях невозможным только по эмоциональным причинам. Кроме того, когда речь заходит о сложных моделях данных, я лично все еще верю в способность РСУБД с их механизмами обеспечения соблюдения на низком уровне.
Теперь вот мой вопрос: мне было интересно, может ли кто-то серьезно рассмотреть возможность использования как RDBMS, так и нереляционной БД в новом проекте: сложная, но не критичная по производительности модель данных все равно будет реализована с использованием реляционной модели и db, тогда как все критически важные для производительности, но простые модели будут реализованы с нереляционным db. Кроме того, такой мягкий сдвиг парадигмы будет намного проще продать некоторым высоко эмоциональным членам команды, чем тяжелый.
Кто-нибудь может рекомендовать такой подход? Или вы предпочитаете использовать черный или белый, т.е. Реляционный или нереляционный подход? Все комментарии приветствуются!
P.S.: Любая идея, если такая комбинация хорошо работает с Spring и Hibernate/JPA?
Ответы
Ответ 1
Недавно Роб Коньери написал о своем опыте создания своего популярного веб-приложения TekPub с MongoDB и MySQL, подчеркивая сильные стороны обоих:
Высоко читаемый материал (информация об учетной записи, постановки и информация о эпизоде) идеально подходит для "прямо сейчас", такого как MongoDb. "Что произошло вчера" отлично подходит для реляционной системы.
На высоком уровне Rob разбивает свои данные приложений на две области: данные времени выполнения и исторические данные. Например, текущее состояние пользовательской корзины покупок отлично подходит для хранения в MongoDB. Это объект blob, который постоянно мутирует. Хранить исторический отчет о том, что было в корзине; когда это произошло; состояние проверки отлично подходит для реляционных табличных данных в MySQL.
Он суммирует с этим:
Он отлично работает. Я не мог быть счастливее с нашей настройкой. Это невероятно низкое обслуживание, мы можем поддержать его, как и любое другое решение, и у нас есть данные, которые нам нужны, когда нам это нужно.
Обновление до 2016 года (6 лет спустя)
Это стало более актуальным в последние 6 лет. В настоящее время распространено мнение о том, что базы данных NoSQL поддерживают транзакционные хранилища и традиционные реляционные базы данных, питающие аналитические базы данных.
Ответ 2
Я использую оба. РСУБД хороша для комплексного анализа, отчетов и данных, доступ к которым осуществляется разными способами несколькими пользователями. NOSQL отлично работает, когда я просматриваю данные с точки зрения пользователей. Вопрос, который я задаю себе, это: "Кто обращается к этим данным?". Если ответ 1 пользователь, я использую NOSQL для его сохранения.
Конечно, есть и другие времена, когда это уместно, но это всего лишь один пример.
Как вы уже упоминали, NOSQL - это более простое хранилище, и это может привести к тому, что вам нужно будет использовать сложный код для хранения данных... Например, сохранение списка соединений.
Ответ 3
Реляционные базы данных с ключом лучше всего использовать для хранения и кэширования памяти.
