Ключ-значение

Записаться

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

Начнем с простейшего типа, который называется key, value по-английски, или по-русски типа «ключ-значение». Свойства баз типа «ключ-значение» - это действительно простейшее хранилище, оно хранит только соответствие между ключом и значением по этому ключу. Ключи являются строками, они хорошо индексируются, значение же является непрозрачным для механизма базы данных бинарным значением. Это означает, что вы не можете никакими средствами стандартными самой базы или запросами обратиться к тем данным, которые у вас лежат внутри объекта. При этом существует решение, когда вы выносите часть значений в ключ, то есть добавляете ключу какие-то свои атрибуты своих объектов, и таким образом подвергаете их индексации. Соответственно, такая база очень легко масштабируется, поскольку внутри очень простая, масштабируется простейшим способом, как master/slave, обычная мгновенная репликация, которая увеличивает скорость на чтение, но из-за простоты самих данных скорость записи тоже очень велика. Кроме прочего, скорость достигается за счет того, что чаще всего эти базы располагаются в памяти и иногда синхронизируются с диском. Идеально данное приложение для работы с большими массивами простейших данных, например, это могут быть значения датчиков, курсы валют, логи файл системы очень простые, какие-то численные записи в большом количестве.

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

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

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

Хеш-таблица - это классические ассоциативные массивы, тоже очень длинные могут быть, и те же самые множества, только упорядоченные по особому параметру могут быть полезны для разработчиков. Здесь отображены простейшие операции с данными, мы видим простейшие операции со строками set get, с множествами get set, то есть вернуть множество, установить значение, переименовать ключ, проверить на существование, удалить или просто вернуть все ключи объекта. Как мы видим, в данном случае используется объектно-ориентированный язык для запросов, все достаточно прозрачно.

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

Мы говорили, что система управления однопоточная, но, если у вас есть несколько потоков, которые работают с базой данных, ты вы можете отсылать и получать сообщения из потока в поток. Здесь показан как раз тип репликации master/slave, запись идет только в мастер узел, остальная репликация со слейвами происходит, слейвов мы можем читать, что ускоряет чтение неизмененных за это время данных.