Какие типы ситуаций подходят для использования как реляционной базы данных, так и базы данных NoSQL?

Question

Это не вопрос типа NoSQL и SQL. Меня интересуют типы сценариев, в которых можно использовать комбинацию СУБД и базы данных NoSQL, а использование комбинации хорошо подходит. В общем, я понимаю, что «это зависит» от ситуации и задачи под рукой, но я думаю, что должны быть некоторые общие/общие ситуации, когда эта комбинация очень полезна.

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

На мой взгляд, можно быть электронной коммерцией. Платежи, транзакции и т. Д. На РСУБД (думаю, ACID), а также информацию о продукте и каталоги в базе данных NoSQL. Но подходит ли это?

Проблемы с поперечной средой приложения, например. Вероятно, ведение журнала хорошо подходит для решения типа NoSQL в качестве другого примера.

В качестве альтернативы, почему бы вам не использовать оба эти типа технологий в сочетании?

Редактировать: Чтобы повторить, я понимаю, что SQL и NoSQL имеют свои неотъемлемые преимущества и недостатки и что определенные типы ситуаций более подходят только для одного из вышеуказанных хранилищ данных.

Iknow гиганты, как Facebook, Google и т.д., вероятно, использовать комбинацию из них, но в почти всех большинстве случаев я не думаю, что большинство SO члены будут когда-либо работать на таких огромных решений. Более типичный повседневный материал.

RavenDB является решение NoSQL, который поддерживает ACID транзакций

Answer 1

Это не вопрос программирования, но вот что я думаю.

Если учесть теорему CAP http://en.wikipedia.org/wiki/CAP_theorem, можно предположить, что Relationnal базы данных сосредоточиться на логичность и доступности, а также NoSQL внимание на доступность и PARTITION TOLERENCE (с Eventual СОГЛАСОВАННОСТИ).

Если вы хотите, чтобы SQL-запрос был действительно последовательным, вам следует рассмотреть возможность использования РСУБД. Если это не предварительный вариант, вы можете использовать базу данных NoSQL.

Вот почему большую часть времени лучше всего использовать их, пользуясь преимуществами обоих.

Answer 2

Хорошим примером может быть любое распределенное хранилище данных, которое одновременно обновляется на нескольких узлах и должно поддерживать потенциально сложные специальные запросы. Узлы будут «в конечном итоге согласованы», что означает, что любой конкретный узел может иметь пробелы в изображении данных в любой момент времени.

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

Answer 3

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

Например, вы можете использовать документы databae, такие как RavenDB или Couch, для работы с OLTP, поскольку они предоставляют вам средства для сохранения ваших объектов и запрашивают эти объекты в сплющенных проекциях в разных документах (однопроцессорные представления). (RavenDB больше, чем CouchDB, но это ни здесь, ни там ;-))

Вы также можете использовать его для простой отчетности, используя Map/Reduce, чтобы дать вам статистику для отображения на определенных страницах (популярные продукты, облака тегов и т. Д.).

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

Например, в RavenDB вы можете использовать любой индекс и автоматически реплицировать данные в этом индексе в реляционный магазин.

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

Это всего лишь один ответ из многих, потому что есть другие примеры, когда один конкретный вид хранилища данных больше подходит для конкретной цели, в конце дня от этого не обойтись. (Если вы не верите ребятам из VoltDB)

Answer 4

Если вы не работаете в масштабе, где реляционные базы данных просто не работают, большим преимуществом NoSQL является простота разработки - такие вещи, как не нужны сценарии обновления ORM или обновления базы данных. Как только вы начнете использовать SQL для одной части системы, для его использования требуется совсем немного дополнительных усилий.

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

Answer 5

NOSQL может быть использован для репликации данных из хранилища данных SQL. В этом сценарии я хочу создавать документы из мобильных записей SQLITE и полагаться на кушетку или монго, чтобы реплицировать это на nosql на сервере. Затем сервер SQL обрабатывает входящие документы.