Хранение пар ключ-значение в столбце базы данных

Question

В моей кодовой базе я недавно наткнулся на проектное решение, принятое командой, в которой пары ключ-значение хранятся в отформатированном виде в столбце базы данных (Relational-mysql). Существует универсальный набор метаданных, и подмножество этих метаданных может присутствовать для конкретной записи. Для данной записи ее подмножество метаданных и ее значения хранятся в столбце в следующем формате:

Key1:Value1\n\nKey2:Value2\n\nKey3:Value3\n\n.....

Чтобы получить метаданные для данного идентификатора записи, нужно просто выполнить простой выбор и затем проанализировать результат, чтобы заполнить словарь в памяти.

Обоснование этого было приведено ниже:

1. Лучшая производительность, чем поддержка денромализованной таблицы, состоящей из столбцов recordId / Key / Value.
2. Масштабируемость
3. Быть консервативным в отношении пространства на сервере базы данных.

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

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

Спасибо

Answer 1

Очевидно, что это зависит от конкретного случая, но такого рода нарушение 1NF обычно является плохим подходом. Одна из существенных проблем заключается в том, что вы никогда не сможете запрашивать метаданные. (Например, «SELECT WHERE key2 = 'value3'»). Другое - то, что вы никогда не сможете обновить один ключ / значение без анализа, настройки, отмены и перезаписи всего большого набора. Для рассмотрения претензий индивидуально:

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

2. Как они это понимают? Хранение всех пар ключ / значение в одном поле будет ухудшаться с увеличением количества пар.

3. Почти наверняка не имеет значения. Дисковое пространство дешевле плохого дизайна.

P.S. Что произойдет, если у вас есть значение с двумя символами новой строки?

Answer 2

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

Если в основном это мешок свойств, сохраняемый как name = value, и пары связаны, то сохраняютсяв одно целое экономит пространство и время.

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

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

Answer 3

Это фактически подход к эффективному превращению вашей реляционной базы данных в NoSQL базу данных .Я использовал эту технику раньше в системах, где мы пытались выкрутить всю производительность системы, и она работала очень хорошо.В одном случае информация фактически использовалась при вызове REST API и должна была передаваться в строке запроса, поэтому информация сохранялась в виде строки запроса (например, «var1 = val1 & var2 = val2»), чтобы вся строка моглапередаваться как есть в API как есть.Разбор этого формата был очень легким.Но ваш вопрос в том, каковы проблемы использования этого метода хранения данных.Я думаю, что проблемы - это те же проблемы, которые решаются путем нормализации вашей базы данных , предложенной EF Codd .Но реальность такова, что базы данных часто нормализуются для достижения желаемых результатов производительности, и подход NoSQL набирает силу из-за большого объема данных, которые необходимо обрабатывать в современных системах.

Answer 4

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

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

Если это больше архив, то ваш формат может хорошо работать в файле данных на сервере, а не в базе данных.

На самом деле все зависит от того, для чего он используется.