Зачем использовать NoSQL поверх материализованных представлений?

В последнее время было много разговоров о NoSQL.Зачем использовать NoSQL поверх материализованных представлений?

Причина, по которой я слышу, как люди используют NoSQL, заключается в том, что они начинают де-нормализовать свои данные СУБД настолько, чтобы повысить производительность, что в итоге у них только одна таблица со всеми их данными внутри этой единственной таблицы ,

С материализованными представлениями, однако, вы можете сохранить свои данные нормализованными, но сохраните их в виде единого табличного представления по тем же причинам, почему вы используете NoSQL.

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

источник

2010-04-09 JustinT

Я думал, что истинное обоснование NoSql заключается в том, что SQL не масштабируется до> петабайт данных. Отсутствие нормализации и расширенных функций sql в целом (например, гарантированная согласованность (coff)) является результатом и, скорее, побочным эффектом распределенной архитектуры, а не фактической целью проектирования. –

Одна из причин заключается в том, что материализованные представления будут плохо работать в OLTP-ситуации, где имеется большое количество INSERT или SELECT.

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

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

источник

2010-04-09 13:47:46 RedFilter

Это неверно. Oracle заявляет, что Materialized Views значительно повышает производительность. http://www.oracle.com/technology/products/oracle9i/daily/jul05.html – JustinT

@JustinT: Конечно, их маркетинг скажет это. Реальность такова, что в некоторых случаях (чтение-тяжелые ситуации) они великолепны. В тяжелых ситуациях с записью они невелики, и это то, что я делал, указав OLTP выше. – RedFilter

Значительно увеличивает производительность по сравнению с чем? «Oracle9i значительно улучшает функциональность материализованных представлений» .. по сравнению с тем, насколько медленными они были раньше. Не сравнивается с архитектурой стиля NoSQL. – NebuSoft

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

Если у вас установлена база данных SQL с хорошо продуманной схемой, и ваше единственное новое требование - это повышение производительности, добавление индексов и представлений, безусловно, правильный подход.

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

источник

2010-04-10 10:47:05

Данные не могут быть «в SQL». Вы имели в виду «в отношениях»? Есть разница в отступлении от языка SQL и выходе из реляционной модели, хотя «NoSQL» объединяет эти два. Также обратите внимание, что индексы и представления мало помогут в сложной среде вставки/обновления. – beldaz

Другая причина - динамическая природа NoSQL. Каждый создаваемый вами вид должен быть создан заранее и «угадать», как приложение может его использовать.

С NoSQL вы можете изменить при изменении данных; динамически изменяя ваши данные в соответствии с приложением.

источник

2015-07-21 17:55:39 CKuharski

Зачем использовать NoSQL поверх материализованных представлений?

ответ

Смежные вопросы