Когда использовать хранилище данных ключ-значение по сравнениюболее традиционная реляционная база данных?

Question

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

Answer 1

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

Что касается relational vs KV, то вопрос, который вы следует спрашивать - это:

С чего бы мне не хотите использовать реляционную модель для этого сценария:...

Поскольку вы не описали сценарий, никто не может сказать вам, почему вы не должны его использовать.Причина KV "охватить все" - это масштабируемость, которая сейчас не является проблемой.Знаете ли вы правила оптимизации?

1. Не делай этого.
2. (только для экспертов) Не делайте этого сейчас.

KV - это весьма оптимизированное решение для масштабируемости, которое, скорее всего, будет совершенно не нужно для вашего приложения.

Answer 2

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

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

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

Answer 3

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

Простой тест:можете ли вы представить свои данные и все их взаимосвязи в виде связанного списка или хэш-таблицы?Если да, то KVS может сработать.Если нет, то вам нужна база данных RDB.

Вам все еще нужно найти KVS, который будет работать в вашей среде.Поддержка KVSE, даже основных, далека от того, что она есть, скажем, для PostgreSQL и MySQL / MariaDB.

Answer 4

Традиционная реляционная база данных имеет проблемы с масштабированием за пределы определенной точки.Где находится эта точка, немного зависит от того, что вы пытаетесь сделать.

Все (большинство?) поставщики облачных вычислений предоставляют хранилища данных типа "ключ-значение".

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

Answer 5

IMO, пара ключевых значений (напримерБазы данных NoSQL) работает лучше всего, когда базовые данные неструктурированы, непредсказуемы или часто меняются.Если у вас нет структурированных данных, с реляционной базой данных будет больше проблем, чем пользы, потому что вам нужно будет внести множество изменений в схему и / или перепрыгивать через обручи, чтобы привести ваши данные в соответствие со структурой.

KVP / JSON / NoSQL хороши тем, что изменения в структуре данных не требуют полного рефакторинга модели данных.Добавление поля к вашему объекту данных - это просто вопрос добавления его к данным.Другая сторона медали заключается в том, что в базе данных KVP / Nosql меньше ограничений и проверок достоверности, чем в реляционной базе данных, поэтому ваши данные могут запутаться.

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

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

Answer 6

Если вы хотите O (1) поиск значений на основе ключей, то вам нужно хранилище KV.Это означает, что если у вас есть данные вида k1={foo}, k2={bar}, и т.д., даже если значения больше / вложенные структуры и требуется быстрый поиск, вам нужно хранилище KV.Даже при правильной индексации вы не можете добиться O (1) поиска произвольных ключей в реляционной базе данных.Иногда это называют "случайным поиском".

Аллитеративно заявлено, что если вы когда-либо выполняете запрос только по одному столбцу, "первичному ключу", если хотите, для извлечения остальных данных, то использование этого столбца в качестве ключевого пространства, а остальных данных в качестве значения в хранилище KV является наиболее эффективным способом выполнения поиска.

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