Гибридный NoSQL: варианты использования значения ключа

Я говорил о том, как поставщики баз данных NoSQL пытаются поддерживать больше моделей данных из других типов баз данных NoSQL. Я называю эти гибридные базы данных NoSQL. В этой статье серии Hybrid NoSQL я рассказываю о том, как другие типы баз данных NoSQL могут обрабатывать случаи использования Key-Value.

Что такое хранилище ключей?

Хранилище KV — это относительно простая модель данных, но позволяющая ослепительно быстро обрабатывать данные Поскольку скорость важна, более продвинутая функциональность обычно не поддерживается.

Большинство вещей может быть хранилищем ключей. Файловая система вашего ноутбука — это хранилище ключей и значений. Ключ — это имя файла, а значение — содержимое файла. Ваш ноутбук (как правило) ничего не знает о файле и не обрабатывает его специально — он просто позволяет открывать, читать, изменять и сохранять содержимое. Никаких модных операций вообще.

Что могут делать магазины KV?

Вот операции, которые могут выполнять все магазины KV:

• Сохраните это двоичное значение с этим ключевым идентификатором
• Получить двоичное значение для этого ключевого идентификатора
• Разделите мои данные между несколькими серверами, равномерно распределяя мои пары KV, чтобы обеспечить производительность

Вот некоторые не очень распространенные функции:

• Увеличить / уменьшить значение этого ключа (Redis DECR, DECRBY, INCR, INCRBY, INCRBYFLOAT)
• Проверьте ключ существует (Redis EXISTS)
• Добавить эти данные в список (или набор), содержащийся в значении этого ключа (Redis APPEND)
• Стековые операции (Redis LPUSH и LPOP)
• Операции с хеш-полями (команды Redis, начинающиеся с H * — их много!)
• Геопространственные полевые операции (бета-тестирование, функция Redis с GEOADD, GEODIS, GEOHASH, GEORADIUS, GEOPOS)
• Опубликовать / подписаться (Redis позволяет клиентам подписываться на уведомления о ключах! Классно!)

Зачем мне делать эти операции в другом типе базы данных NoSQL?

Возможно, потому что у вас уже есть его, или у вас также есть необходимость в хранилище документов или хранилище столбцов в другом приложении — и вам интересно, можете ли вы использовать его повторно. Конечно, он никогда не будет таким ослепительно быстрым, как чистый магазин KV, но, возможно, вам не нужно обрабатывать 400 000 транзакций в секунду на сервер.

Что я могу и не могу сделать?

Я собираюсь использовать MarkLogic Server для сравнения. MarkLogic — это гибридная база данных NoSQL, поддерживающая операции Document, Search и Triple store. Он также может использоваться для хранения произвольных двоичных данных, а также текста, json и XML, для которых он был изначально создан. Многие исходные документы являются бинарными, как PDF-файлы. Это означает, что он обладает основными возможностями хранения и извлечения произвольных данных, как и хранилище KV.

Магазин и выборка

MarkLogic можно использовать для хранения двоичных данных, просто используя его REST API. Сделайте  POST для /v1/documents?uri=/some/doc/uri.bin  с Content-Type: установите соответствующий тип MIME для того, что вы хотите. Используйте  GET / v1 / documents? Uri = что угодно,  чтобы получить его в оригинальном типе контента.

URI в MarkLogic является нашим ключевым идентификатором. Вы можете назначить один самостоятельно, как указано выше, или попросить сервер сгенерировать случайный. В этом случае URI возвращается в ответе POST.

Sharding

Большие двоичные файлы MarkLogic (по умолчанию любые файлы размером более 1 МБ, хотя это можно настроить) хранятся в файловой системе как есть. Изменения заносятся в журнал, и данные реплицируются по причинам высокой доступности в пределах границы транзакции — это совместимо с ACID. Репликация базы данных и резервные копии также работают для двоичных данных, поэтому не стоит беспокоиться.

Машина, которая получает новый документ (или значение), случайным образом помещает документ в сегмент (называемый лесом) на сервер в кластере. MarkLogic Server также имеет функцию, называемую автоматической перебалансировкой, поэтому, если вы случайно добавите все свои документы на один сервер, MarkLogic автоматически перебалансирует их по всему кластеру. Все без дублирования или недоступности данных.

Увеличение / Уменьшение

MarkLogic может использоваться для хранения данных XML и JSON. Эти документы могут быть простыми или сложными, как вам нравится. Они могут быть одним значением, если хотите, как магазин KV, но это не очень эффективно (как магазин KV!). Каждый документ MarkLogic имеет небольшие издержки — около 750 байтов. Таким образом, хранение 2-байтового значения означает, что накладные расходы являются дорогостоящими.

Лучше создать документ со многими значениями и изменить часть этого документа. Например, вместо того, чтобы иметь ключ для продукта для каждого атрибута — например, PRODUCT1234-QuantityInStock — вместо этого у вас есть документ для Product1234, который содержит количество на складе, название продукта, название, штрих-код и все другие метаданные. (Вот почему магазины KV также поддерживают хеши, о которых я расскажу позже в этой статье…)

Но как управлять этими данными? REST API MarkLogic поддерживает  операцию PATCH . Это может сделать несколько вещей. В нашем сценарии его можно использовать для увеличения или уменьшения значения на 1 или любой другой суммы. Используйте  механизм замены патча с операцией  ml.add,  но вы также можете умножать, делить, выполнять поиск и замену по регулярному выражению, объединять строки или выполнять операцию с подстрокой.

Проверьте ключ существует

Если ваш документ в MarkLogic содержит все ваше значение ключа, вы можете просто сделать  HEAD для / v1 / documents? Uri = что угодно . Если вы получите ответ 404, то этот документ не существует.

Если вы хотите проверить значение в пределах одного элемента в документе XML или JSON, это немного сложнее.

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

По сути, вы создаете поиск, ограниченный одним документом — URI, который вас интересует. Кроме того, вы используете элемент-запрос (теперь называемый контейнерным запросом), чтобы проверить существование элемента. Если ваши результаты поиска возвращают один URI — ваш документ — тогда он существует. В противном случае это не так.

Вы создаете это с помощью POST / v1 / search. Я не проверял ниже, но что-то вроде этого в теле POST должно работать:

{
  "search": {
    "query" : {
      "queries": [{
        "and-query": {
          "queries": [
            {"document-query": {"uri": [ "/my/doc/uri.bin" ]},      // does my doc exist?
            {"container-query": {"json-property": "mypropertykey"}} // does my property exist?
          ]
        }
      }]
    }, 
    "options" : { "return-results" : false, "return-metrics" : false } 
  } 
}

{
  "field1": "some value",
  "field2": "some other value",
  "field3": 45
}