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

Недавно было много разговоров о NoSQL.

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

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

Таким образом, почему кто-то использует NoSQL над Materialized Views?

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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