Во многом это зависит от того, что вы хотите, чтобы ваше хранилище данных делало. Если вы хотите иметь возможность масштабирования в соответствии с требованиями к хранилищу или операциям, СУБД может занять у вас столько времени.
Все сводится к как вы можете масштабировать для удовлетворения спроса. СУБД действительно может масштабировать по вертикали . То есть добавьте больше оперативной памяти, добавьте больше дисков и т. Д. Распределенная (NoSQL) база данных упрощает масштабирование, позволяя добавлять больше экземпляров компьютера. Это известно как масштабирование по горизонтали .
Вот пример использования Кассандры:
Допустим, у меня есть кластер из 3 узлов, и мое пространство ключей (база данных) также настроено с коэффициентом репликации (RF), равным 3. Это означает, что каждый узел отвечает за 100% данных. Я загружаю свои данные, и это занимает 100 ГБ дискового пространства (на каждом узле). Теперь, когда в моем кластере может быть 300 ГБ данных, одна копия моих данных составляет 100 ГБ.
Итак, моя команда разработчиков приходит ко мне и говорит, что им нужно удвоить объем данных, которые они имеют. Я знаю, что я построил их кластер из 3 узлов с дисками 200 ГБ. Если бы я ничего не делал, эти диски были бы в значительной степени заполнены (и если бы они этого не сделали, они бы не оставили места для чего-то еще).
Теперь я должен масштабировать кластер для удовлетворения их потребностей в пространстве. Я начну с добавления 3 новых узлов в кластер (всего 6), но оставлю свой RF на 3. Это делает каждый узел ответственным за 50% данных или 50 ГБ. Когда моя команда разработчиков загружает больше данных, чтобы удовлетворить свои требования к «удвоению», каждый узел должен набрать примерно 100 ГБ. Одна копия данных теперь 200 ГБ. Но если каждый узел отвечает за 50%, каждый диск емкостью 200 ГБ все еще имеет только 100 ГБ.
Пример № 2:
Предположим, что кластер с 6 узлами выше способен поддерживать рабочую нагрузку в 10 000 операций в секунду (ops). Моя команда по продукту снова приходит ко мне, говоря, что в праздничный сезон они планируют поддержать 20 000 операций. Поскольку текущий кластер может поддерживать только половину этого, он будет задыхаться при высокой пропускной способности, и один или несколько узлов могут выйти из строя.
Поскольку Кассандра масштабируется линейно, способ достижения этого состоит в том, чтобы (опять же) удвоить размер кластера. Таким образом, я увеличил его с 6 до 12 узлов, сохранив при этом свой RF на 3. После выполнения некоторого тестирования производительности они подтверждают, что он действительно может поддерживать 20 000 операций. Поскольку одна копия моих данных составляет 200 ГБ, общий объем данных остается 600 ГБ. С 12 узлами каждый узел теперь отвечает только за 25% данных или 50 ГБ.
Так что масштабируемость является преимуществом. Но как насчет моделирования данных? Основная идея моделирования распределенной базы данных, состоит из двух частей:
- Создайте структуру таблицы, которая имеет ключ для правильного распределения. Нам не нужны неравные объемы данных на каждом узле.
- Создайте ключ на таблице так, чтобы он соответствовал требованиям нашего запроса.
Одним из недостатков базы данных NoSQL является то, что ваши шаблоны запросов становятся ограниченными. Стремясь сократить сетевое время, вы хотите, чтобы ваш запрос обслуживался одиночным узлом.
Обычно это означает использование натуральных ключей, так как они более соответствуют тому, что вы запрашиваете у ваших данных. Суррогатные ключи (буквенные, числовые или оба) хорошо распределяются, но не очень полезны для запросов. Пользователь "Боб Джонс" может иметь идентификатор "3582346556230" в моей системе. Но когда я хочу запросить данные Боба, я, вероятно, никогда не захочу запрашивать их по «3582346556230», потому что это ничего не значит для приложения или контекста, в котором используются данные.
Кроме того, вы хотите, чтобы ваши данные имели структуру. Неструктурированные данные - это незапрашиваемые данные. Просто как тот. Если вы хотите, чтобы неструктурированные данные можно было запрашивать, вам необходимо проанализировать их идентифицирующие аспекты, которые будут использоваться в качестве ключей. Вы не хотите «искать» или запускать SELECT * FROM запросов. Полное сканирование таблиц в базах данных NoSQL требует даже больше ресурсов, чем их аналоги из СУБД, поскольку им приходится проверять каждый узел, сортировать реплики и, таким образом, тратить дополнительное сетевое время.
Базы данных NoSQL дают вам возможность масштабирования (для увеличения данных или спроса). Но важно отметить, что их масштабируемость может сделать некоторые вещи (которые могут быть хорошими в СУБД) более сложными, чем вы привыкли.