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

Question

В последнее время много говорят о NoSQL.

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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