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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Что касается реляционного и КВ, то вопрос, который вы должны задать, будет:

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

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

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

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

Answer 6

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

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

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