Metastocle — децентрализованное хранилище данных / Хабр

Что делать, если нужно хранить разнообразные данные децентрализованно? Объекты, массивы, даты, числа, строки, да что угодно. Обязательно ли придумывать мощную СУБД для этого? Ведь часто нам просто нужно хранить и получать данные распределенно, открыто, но максимально просто и без особых притязаний.

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

Немного предыстории

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

Metastocle — один из слоев, позволяющий хранить и получать много типов данных (но не файлы), в противовес слою storacle, который реализует работу именно с файлами.

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

В итоге, все это было приведено к некому универсальному виду, и система состоит из трех основных сущностей:

Коллекции — аналогично популярным nosql базам данных, сущность для определения структуры данных, различных опций и.т.п.
Документы — непосредственно сами данные, в виде объектов.
Действия (инструкции) — набор правил для обработки требуемых данных: фильтрация, сортировка, лимитирование и.т.д.

Давайте посмотрим пару примеров:

Сервер:

const Node = require('metastocle').Node;

(async () => {
  try {
    const node = new Node({
      port: 4000,
      hostname: 'localhost'
    });

    // Создаем коллекцию
    await node.addCollection('test', { limit:  10000, pk:  'id' });
    await node.init();
  }
  catch(err) {
    console.error(err.stack);
    process.exit(1);
  }
})();

Клиент:

const Client = require('metastocle').Client;

(async () => {
  try {
    const client = new Client({
      address: 'localhost:4000'
    });
    await client.init();

    // Добавляем документ
    const doc = await client.addDocument('test', { text: 'hi' });

    // Обновляем этот документ
    await client.updateDocuments('test', { text: 'bye' }, {
      filter: { id: doc.id }
    });

    // Добавляем еще один документ
    await client.addDocument('test', { id: 2, text: 'new' });

    // Получаем второй документ
    const results = await client.getDocuments('test', {
      filter: { id: 2 }
    });

    // Получаем его иначе
    const doc2 = await client.getDocumentById('test', 2));

    // Добавляем еще документов
    for(let i = 10; i <= 20; i++) {
      await client.addDocument('test', { id: i, x: i });
    }

    // Получаем документы, соответствующие всем условиям
    const results2 = await client.getDocuments('test', {
      filter: { id: { $gt: 15 } },
      sort: [['x', 'desc']],
      limit:  2,
      offset:  1,
      fields: ['id']
    });

    // Удаляем документы, у которых id > 15
    await client.deleteDocuments('test', {
      filter: { id: { $gt: 15 } }
    });
  }
  catch(err) {
    console.error(err.stack);
    process.exit(1);
  }
})();

Клиенты не могут создавать коллекции, сеть сама устанавливает структуру, а пользователи лишь работают с документами. Коллекции можно описывать и декларативно, через опции узла:

const node = new Node({
   port: 4000,
   hostname: 'localhost',
   collections: {
     test: { limit: 10000, pk: 'id' }
   }
 });

Основные настройки коллекции:

pk — поле первичного ключа. Можно не указывать, если таковое не требуется. Если поле указано, то, по умолчанию, создается uuid хэш, но при желании можно прокинуть любую строку или число.
limit — максимальное количество документов на одном узле
maxSize — максимальная память на данную коллекцию
queue — режим очереди: если включен, то при достижении лимита определенные документы удаляются, чтобы записать новые
limitationOrder — если лимитирование и очередь включены, то можно указать правила сортировки для определения удаляемых документов. По умолчанию, удаляются те, с которыми уже давно не работали.
schema — структура полей документов
defaults — значения по умолчанию полей документов.
setters — хуки полей документов при сохранении.
getters — хуки полей документов при получении.
preferredDuplicates — можно указать предпочтительное количество дубликатов документа в сети.

Структура полей коллекции (schema) может быть описана в виде:

{ 
  type: 'object',
  props: {
    count: 'number',
    title: 'string',
    description: { type: 'string' },
    priority: {
      type: 'number',
      value: val => val >= -1 && val <= 1
    },
    goods: {
      type: 'array',
      items: {
        type: 'object',
        props: {
          title: 'string',
          isAble: 'boolean'
        }
      }
    }
  }
}

Полный набор всех правил можно найти в функции utils.validateSchema() в https://github.com/ortexx/spreadable/blob/master/src/utils.js

Значения по умолчанию и хуки могут быть в виде:

{ 
  defaults: {
    date: Date.now
    priority: 0
    'nested.prop': (key, doc) => Date.now() - doc.date
  },
  setters: {
    priority: (val, key, doc, prevDoc) => prevDoc? prevDoc.priority + 1: val
  },
  getters: {
    priority: (val, key, doc) => val - 1
  }
}

Основные особенности библиотеки:

Работа по принципу CRUD
Хранение всех типов данных Javascript, которые можно сериализовать, в том числе вложенных.
Данные могут добавляться в хранилище через любой узел
Данные могут дублироваться для большей надежности
Запросы могут содержать вложенные фильтры

Изоморфность

Клиент написан на javascript и изоморфен, его можно использовать прямо из браузера.

Можно загрузить файл https://github.com/ortexx/metastocle/blob/master/dist/metastocle.client.jsкак скрипт и получить доступ к window.ClientMetastocle либо импортить через систему сборки и.т.п.

Api клиента

async Client.prototype.addDocument() — добавление документа в коллекцию
async Client.prototype.getDocuments() — получение документов из коллекции по каким-либо инструкциям
async Client.prototype.getDocumentsСount() — получение количества документов в коллекции
async Client.prototype.getDocumentByPk() — получение документа из коллекции по первичному ключу
async Client.prototype.updateDocuments() — обновление документов в коллекции по каким-либо инструкциям
async Client.prototype.deleteDocuments() — удаление документов из коллекции по каким-либо инструкциям

Основные действия (инструкции):

.filter — фильтрация данных, пример:

{ 
  a: { $lt: 1 },
  $and: [
    { x: 1 },
    { y: { $gt: 2 } },
    { 
      $or: [
        { z: 1 },
        { "b.c": 2 }
      ] 
    }
  ]
}

.sort — сортировка данных, пример:

{ sort: [['x', 'asc'], ['y.z', 'desc']] }

.limit — количество данных

.offset — начальная позиция отбора данных

.fields — необходимые поля в документах

Более подробно все инструкции и возможные значения описаны в readme.

Работа через командную строку

Библиотеку можно использовать через командную строку. Для этого нужно установить ее глобально: npm i -g metastocle --unsafe-perm=true --allow-root. После этого можно запускать нужные экшены из директории с проектом, где узел.

Например, metastocle -a getDocumentByPk -o test -p 1 -c ./config.js, чтобы получить документ с первичным ключом 1 из коллекции test. Все экшены можно найти в https://github.com/ortexx/metastocle/blob/master/bin/actions.js

Ограничения

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

К выбору стека и этим ограничениям я пришел сознательно, поскольку цели и возможности создавать полноценную СУБД не было.

Хоть библиотека пока сыровата в плане оптимизации запросов на получение данных, но если придерживаться определенных правил, то особых проблем нет:

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

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

По любым вопросам обращайтесь: