Базы данных «ключ-значение» великолепные — ультрабыстрые, простые, почти линейно масштабируемые по количеству узлов. Но с ними все не так просто. Команда VK Cloud Solutions перевела статью о том, какие у таких баз есть проблемы и как их решить с помощью Wide-column-хранилищ.
Проблемы с базами данных «ключ-значение»
Основная концепция базы данных «ключ-значение» в том, что сами значения ее не беспокоят. Ее работа основана на некоторых допущениях, например, как у Redis, но на структуру данных она вообще не обращает внимания. Из-за этого могут возникнуть три проблемы.
1. База не может фильтровать поля атрибутов. Ведь с ее точки зрения значение — это большой блок двоичных данных.
2. Возвращает целое значение. Если это не кажется проблемой, то вспомните, что главное преимущество баз «ключ-значение» — скорость. Посмотрите на процесс извлечения данных из базы:
Производительность большинства этапов зависит от размера передаваемых данных, а не от них самих. Именно поэтому команда
SELECT * говорит о том, что человек ничего не смыслит в производительности.3. Значение можно обновить только целиком. Из-за этого нам приходится:
- выводить клиенту полные данные;
- работать с данными целиком;
- отправлять в базу данные целиком.
Это звучит даже хорошо, ведь мы обновляем объект целиком, разве нет? Но подумайте о вариантах, когда нужно:
- обновить дату последнего входа пользователя в систему;
- прикрепить элемент к списку (например, в корзине интернет-магазина);
- заменить цены на некоторые товары по акции.
Как решить эти задачи и не потерять в скорости?
Wide-column-базы данных
В основе такой базы лежит простой принцип работы: давайте снова структурировать данные (то есть их значения) в пары «ключ-значение». Вот что у нас есть в базах «ключ-значение»:
А вот как представляют данные Wide-Column-базы:
Столбцы позволяют определять подмножество данных, которое нужно вывести клиенту или обновить. В чем здесь отличие от обычной таблицы реляционной базы данных? В большинстве Wide-column-баз столбцы определяются на уровне одного элемента. Здесь нет схемы на уровне всей БД, что наводит на мысль о некоторых интересных характеристиках Wide-column-баз.
Преимущества Wide-column-баз данных
У Wide-column-баз данных в основном те же плюшки, что и у баз «ключ-значение». Но есть и дополнительные преимущества, пускай они заметны и не в каждой реализации:
-
частичные операции. Можно добавить или обновить значение столбца;
-
сжатие данных. При работе с разреженными данными не нужно хранить пустые значения или null. Можно сэкономить обычно зарезервированное место, так как значения определяет схема;
-
предложение WHERE. Эта функция редко встречается в базах этого типа, но появляется фильтрация данных.
Команда VK Cloud Solutions развивает собственные Big-Data-решения. Будем признательны, если вы их протестируете и дадите обратную связь. Для тестирования пользователям при регистрации начисляем 3000 бонусных рублей.
Что еще почитать:
Комментарии (8)
abutorin
13.07.2022 12:51+4Что-то мне подсказывает что Wide-Column-базы это частный случай базы "ключ-значение" где просто к ключу можно добавить суффикс с названием колонки.
Myateznik
14.07.2022 20:34По сути так и есть Wide-Column - частный случай Key-Value. Причём многие почему-то рассматривают ключи как какой-то один идентификатор, хотя ключи также как и значения могут иметь структуру. @keich ниже привёл примеры и оставил ссылку на статью в этом же блоге.
Собственно иногда от Key-Value даже остаётся только Key (какое-нибудь дерево B/R/LSM), в котором есть как техническая информация для сканирования, так и само значение (например, различные индексы, графы в триплетах и т.д.).
Собственно таже Amazon DynamoDB база Key-Value, при работе с которой внешне может быть даже похоже на Wide-Column/Document Oriented.
keich
13.07.2022 15:30Есть стандартные способы хранения данных в key-value и они все(не уверен) перечислены в статье https://habr.com/ru/company/vk/blog/480850/
1) Если не нужен поиск по содержимому данных и получение частичных данных, то структура ключа как обычно.
Key1 | {Field1:Val1,Field2:Val2}
2) Если нужно получения только части данных. Естественно база должна уметь scan с первого совпадения части ключа.
Key1.Filed1 | {Val1}
Key1.Filed2 | {Val2}
3) Если нужен поиск по содержимому
Key1.Field1.Val1|NULL
Key1.Field2.Val2|NULL
hard_sign
14.07.2022 09:56Справедливости ради, «документо-ориентированные» БД также решают все перечисленные проблемы.
Badiboy
14.07.2022 10:12А вот как представляют данные Wide-Column-базы:
Redis Hashes решает эту задачу не выходя за принцип базы "ключ-значением".
FoxisII
14.07.2022 13:58+1Все зависит от задачи:
если надо найти одну строку и в ней что то поискать
- Ключ значение вполне подойдет
если надо найти по атрибуту все строки
- Wide-Column
Те кто пробуют искать что то внутри полей json ....
ну такое на любителя.....
потому что у колонок есть фишки которых нет в Key Value
- Тип данных
- Статистика по колонке
- Индексы
OlegZH
Начало более длинной статьи, оборванное на середине постановки задачи. Было бы неплохо дописать до конца. Тема-то актуальная!