«Руководство по SirixDB»

«1. Обзор

В этом руководстве мы дадим обзор того, что такое SirixDB, и наиболее важные цели его разработки.

Далее мы рассмотрим низкоуровневый транзакционный API на основе курсора.

2. Возможности SirixDB

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

В настоящее время SirixDB предлагает две встроенные собственные модели данных, а именно двоичное хранилище XML и хранилище JSON.

2.1. Цели разработки

Некоторые из наиболее важных основных принципов и целей разработки:

Параллелизм — SirixDB содержит очень мало блокировок и стремится максимально подходить для многопоточных систем. Асинхронный REST API — операции могут выполняться независимо. ; каждая транзакция привязана к определенной ревизии, и только одна транзакция чтения-записи на ресурсе разрешена одновременно с N транзакциями только для чтения до минимума. Производительность чтения и записи настраивается. Это зависит от типа управления версиями, который мы можем указать для создания ресурса Целостность данных — SirixDB, как и ZFS, хранит полные контрольные суммы страниц на родительских страницах. Это означает, что почти все повреждения данных могут быть обнаружены при чтении в будущем, поскольку разработчики SirixDB стремятся в будущем разделять и реплицировать базы данных Семантика копирования при записи — аналогично файловым системам Btrfs и ZFS, SirixDB использует CoW семантики, что означает, что SirixDB никогда не перезаписывает данные. Вместо этого фрагменты страниц базы данных копируются и записываются в новое место. Версии для каждой версии и для каждой записи — SirixDB создает версии не только для каждой страницы, но и для каждой записи. Таким образом, всякий раз, когда мы меняем потенциально небольшую часть записей на странице данных, не нужно копировать всю страницу и записывать ее в новое место на диске или флэш-накопителе. Вместо этого мы можем указать одну из нескольких стратегий управления версиями, известных из систем резервного копирования, или алгоритм скользящего моментального снимка во время создания ресурса базы данных. Указанный нами тип управления версиями используется SirixDB для управления версиями страниц данных. Гарантированная атомарность (без WAL) — система никогда не перейдет в несогласованное состояние (за исключением аппаратного сбоя), а это означает, что неожиданное отключение питания никогда не повредит система. Это достигается без накладных расходов, связанных с журналом упреждающей записи (WAL). Структурированный журнал и удобный для SSD — SirixDB выполняет пакетную запись и синхронизацию всего последовательно на флэш-накопитель во время фиксации. Он никогда не перезаписывает зафиксированные данные

Сначала мы хотим представить низкоуровневый API на примере данных JSON, прежде чем в будущих статьях переключить внимание на более высокие уровни. Например, XQuery-API для запросов к базам данных XML и JSON или асинхронный временный RESTful API. По сути, мы можем использовать один и тот же низкоуровневый API с небольшими отличиями для хранения, просмотра и сравнения ресурсов XML.

Чтобы использовать SirixDB, нам как минимум нужно использовать Java 11.

3. Зависимость Maven для встраивания SirixDB

Чтобы следовать примерам, мы сначала должны включить зависимость sirix-core, например, через Maven:

<dependency>
    <groupId>io.sirix</groupId>
    <artifactId>sirix-core</artifactId>
    <version>0.9.3</version>
</dependency>

Или через Gradle:

dependencies {
    compile 'io.sirix:sirix-core:0.9.3'
}

4. Древовидное кодирование в SirixDB

Узел в SirixDB ссылается на другие узлы с помощью кодировки firstChild/leftSibling/rightSibling/parentNodeKey/nodeKey: ~ ~~ Числа на рисунке представляют собой автоматически сгенерированные уникальные, стабильные идентификаторы узлов, сгенерированные с помощью простого генератора последовательных чисел.

У каждого узла может быть первый дочерний узел, левый одноуровневый узел, правый одноуровневый узел и родительский узел. Кроме того, SirixDB может хранить количество дочерних узлов, количество потомков и хэши каждого узла.

В следующих разделах мы представим основной низкоуровневый JSON API SirixDB.

5. Создайте базу данных с одним ресурсом

«Во-первых, мы хотим показать, как создать базу данных с одним ресурсом. Ресурс будет импортирован из файла JSON и сохранен во внутреннем двоичном формате SirixDB:

Сначала мы создадим базу данных. Затем мы открываем базу данных и создаем первый ресурс. Существуют различные варианты создания ресурса (см. официальную документацию).

var pathToJsonFile = Paths.get("jsonFile");
var databaseFile = Paths.get("database");

Databases.createJsonDatabase(new DatabaseConfiguration(databaseFile));

try (var database = Databases.openJsonDatabase(databaseFile)) {
    database.createResource(ResourceConfiguration.newBuilder("resource").build());

    try (var manager = database.openResourceManager("resource");
         var wtx = manager.beginNodeTrx()) {
        wtx.insertSubtreeAsFirstChild(JsonShredder.createFileReader(pathToJsonFile));
        wtx.commit();
    }
}

Затем мы открываем одну транзакцию чтения-записи для ресурса, чтобы импортировать файл JSON. Транзакция предоставляет курсор для навигации по методам moveToX. Кроме того, транзакция предоставляет методы для вставки, удаления или изменения узлов. Обратите внимание, что API XML даже предоставляет методы для перемещения узлов в ресурсе и копирования узлов из других ресурсов XML.

Чтобы правильно закрыть открытую транзакцию чтения-записи, менеджер ресурсов и базу данных, мы используем оператор Java try-with-resources.

Мы привели пример создания базы данных и ресурса на основе данных JSON, но создание базы данных и ресурса XML практически идентично.

В следующем разделе мы откроем ресурс в базе данных и покажем навигационные оси и методы.

6. Открытие ресурса в базе данных и навигация

6.1. Навигация по предварительному заказу в ресурсе JSON

Для навигации по древовидной структуре мы можем повторно использовать транзакцию чтения-записи после фиксации. Однако в следующем коде мы снова откроем ресурс и начнем транзакцию только для чтения с самой последней ревизией:

Мы используем ось потомков для перебора всех узлов в предварительном порядке (сначала в глубину) . Хэши узлов строятся снизу вверх для всех узлов по умолчанию в зависимости от конфигурации ресурса.

try (var database = Databases.openJsonDatabase(databaseFile);
     var manager = database.openResourceManager("resource");
     var rtx = manager.beginNodeReadOnlyTrx()) {
    
    new DescendantAxis(rtx, IncludeSelf.YES).forEach((unused) -> {
        switch (rtx.getKind()) {
            case OBJECT:
            case ARRAY:
                LOG.info(rtx.getDescendantCount());
                LOG.info(rtx.getChildCount());
                LOG.info(rtx.getHash());
                break;
            case OBJECT_KEY:
                LOG.info(rtx.getName());
                break;
            case STRING_VALUE:
            case BOOLEAN_VALUE:
            case NUMBER_VALUE:
            case NULL_VALUE:
                LOG.info(rtx.getValue());
                break;
            default:
        }
    });
}

Узлы массива и узлы объекта не имеют ни имени, ни значения. Мы можем использовать одну и ту же ось для перебора XML-ресурсов, различаются только типы узлов.

SirixDB предлагает набор осей, таких как, например, все оси XPath для навигации по ресурсам XML и JSON. Кроме того, он предоставляет LevelOrderAxis, PostOrderAxis, NestedAxis для оси цепочки и несколько вариантов ConcurrentAxis для одновременной и параллельной выборки узлов.

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

6.2. Ось потомков посетителей

Поскольку очень часто поведение определяется на основе различных типов узлов, SirixDB использует шаблон посетителей.

Мы можем указать посетителя в качестве аргумента построителя для специальной оси с именем VisitorDescendantAxis. Для каждого типа узла существует эквивалентный метод посещения. Например, для ключевых узлов объекта это посещение метода VisitResult (узел ImmutableObjectKeyNode).

Каждый метод возвращает значение типа VisitResult. Единственной реализацией интерфейса VisitResult является следующее перечисление:

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

public enum VisitResultType implements VisitResult {
    SKIPSIBLINGS,
    SKIPSUBTREE,
    CONTINUE,
    TERMINATE
}

SKIPSIBLINGS означает, что обход должен продолжаться без посещения правых братьев и сестер текущего узла курсор указывает на SKIPSUBTREE означает продолжение без посещения потомков этого узла Мы используем CONTINUE, если обход должен продолжить в предварительном порядке Мы также можем использовать TERMINATE для немедленного прекращения обхода

Реализация по умолчанию каждого метода в интерфейсе посетителя возвращает VisitResultType.CONTINUE для каждого типа узла. Таким образом, нам нужно только реализовать методы для узлов, которые нас интересуют. Если мы реализовали класс, который реализует интерфейс посетителя с именем MyVisitor, мы можем использовать VisitorDescendantAxis следующим образом:

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

var axis = VisitorDescendantAxis.newBuilder(rtx)
  .includeSelf()
  .visitor(new MyVisitor())
  .build();

while (axis.hasNext()) axis.next();

6.3. Ось путешествий во времени

«

var axis = new PastAxis(resourceManager, rtx);
if (axis.hasNext()) {
    var trx = axis.next();
    // Do something with the transactional cursor.
}

new FilterAxis<JsonNodeReadOnlyTrx>(new ChildAxis(rtx), new JsonNameFilter(rtx, "a"))

var axis = new VisitorDescendantAxis.Builder(rtx).includeSelf().visitor(myVisitor).build();
var filter = new JsonNameFilter(rtx, "foobar");
for (var filterAxis = new FilterAxis<JsonNodeReadOnlyTrx>(axis, filter); filterAxis.hasNext();) {
    filterAxis.next();
}

var axis = new PostOrderAxis(rtx);
var axisStream = StreamSupport.stream(axis.spliterator(), false);

axisStream.filter((unusedNodeKey) -> new JsonNameFilter(rtx, "a"))
  .forEach((unused) -> /* Do something with the transactional cursor */);

if (wtx.isObjectKey()) wtx.setObjectKeyName("foo");
if (wtx.isStringValue()) wtx.setStringValue("foo");

wtx.insertObjectRecordAsFirstChild("foo", new StringValue("bar"))
   .moveToParent().trx()
   .insertObjectRecordAsRightSibling("baz", new NullValue());

var json = "{\"foo\": \"bar\",\"baz\": [0, \"bla\", true, null]}";
wtx.insertSubtreeAsFirstChild(JsonShredder.createStringReader(json));

wtx.copySubtreeAsRightSibling(rtx);

resourceManager.beginNodeTrx(TimeUnit.SECONDS, 30);
resourceManager.beginNodeTrx(1000);
resourceManager.beginNodeTrx(1000, TimeUnit.SECONDS, 30);

resourceManager.beginNodeTrx().revertTo(2).commit();

var rtxOpenedByRevisionNumber = resourceManager.beginNodeReadOnlyTrx(2);

var dateTime = LocalDateTime.of(2019, Month.JUNE, 15, 13, 39);
var instant = dateTime.atZone(ZoneId.of("Europe/Berlin")).toInstant();
var rtxOpenedByTimestamp = resourceManager.beginNodeReadOnlyTrx(instant);

DiffFactory.invokeJsonDiff(
  new DiffFactory.Builder(
    resourceManager,
    2,
    1,
    DiffOptimized.HASHED,
    ImmutableSet.of(observer)));

public interface DiffObserver {
    void diffListener(DiffType diffType, long newNodeKey, long oldNodeKey, DiffDepth depth);
    void diffDone();
}

var writer = new StringWriter();
var serializer = new JsonSerializer.Builder(resourceManager, writer).build();
serializer.call();

var serializer = new
JsonSerializer.Builder(resourceManager, writer, 1, 2).build();
serializer.call();

var serializer = new
JsonSerializer.Builder(resourceManager, writer, -1).build();
serializer.call();