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

Ответ 1

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

Что касается реляционных vs KV, вопрос, который вы должны задать, это:

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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