еще один велосипед или TreeDb — NoSQL Database startup

Хочу представить старт проекта, с рабочим названием TreeDb. Я не пиарюсь (еще далеко...) и размещаю свои мысли и рассуждения в личном блоге. Хочу в ответ получить адекватную критику, обсуждение идей, в общем все то, для чего нужны блоги ;). Просто, в последствии интересно проследить историю проекта, что задумали и что на выходе. А может кто и захочет и по участвовать. Всегда рады.

Из названия понятно, что речь пойдет о БД, основанной на деревьях. Сразу оговорюсь — на данный момент нет ни строчки кода. Сперва определюсь с концепцией.

ниже FAQ

немного о терминологии:

Ключ — уникальный идентификатор, однозначно определяющий некоторые (конкретные) данные.
ключ может содержать символы \w [azAZ09_] *
* — возможно это ограничение в будущем будет снято или расширенно на [ая]. Просьба к этому пока не придираться.
Ключ может быть полным или коротким.

Короткий ключ — это имя ноды, уникальное в пределах данного уровня. А если выразиться точнее — в составе одной Родительской ноды должны быть только уникальные имена дочерних нод (В одной большой семье нет одинаковых имен у братьев и сестер). Пример простого ключа A1, B2, C3

Полный ключ — это последовательно сконтектанированные через точку имена всех родительских нод.
Пример полного ключа A1.B2.C3 — имя Ноды C3, ее родителя B2, и пра-родителя A1

Данные — определенная последовательность байт, которую необходимо запомнить и выдать по запросу. данные могут быть как алфавитно-цифровые, так и бинарные.

Нода (узел ) — однозначно определяемая ключом совокупность данных и дочерних нод. другими словами Нода — содержит имя (ключ), данные и ссылки на дочерние ноды.

Дочерняя нода — нода, содержащаяся в Родительской ноде и имеющая одну связь. Масло масленное.

Дочерняя нода может быть неименованной, т.е цифровой ключ присваевается ей автоматически в порядке поступления. см пример…

Корневая нода — практически ее нет, есть ноды первого уровня. Теоретически — должна существовать.

Описание Протокола обмена

За основу взят Протокол обмена memcached. В первое время планируется реализовать только две команды: get & set

1) Записать ноду A1
set A1,<data_len> \r\n
\r\n
>stored или error *
*- может заменить на Ok или $

Пример:
set A1,5
12345
>stored

2) Записать несколько нод
set (<node_name>,<data_len>)+ \r\n
\r\n
>stored
....
\r\n
>stored*
*- может сделать только одно подтверждение на весь блок данных?

Пример:
set A1,5 A2,5 A3,5
12345
>stored
67890
>stored
abcde
>stored

3) извлечь ноду A1
get A1\r\n
>A1 5
>12345\r\n
>ok *
*- нужнен ли окей? (optional)

4) извлечь ноды A1,A2,A3
get A1,A2,A3\r\n
>A1 5
>12345\r\n
>A2 5
67890
>A2 5
abcde
>ok *
*- нужнен ли окей?

5) записать в ноду A группу неименованных нод (может обозвать рекордсетом?)
set A.# 5,5,5
12345
>stored
67890
>stored
abcde
>stored
Если дочерних нод в ноде А не было, то появятся ноды с именами: #1,#2,#3
если эти уже были, то появятся следующие имена: #4,#5,#6

6) просмотреть в ноде A список дочерних нод
get A.#
> A.#1,A.#2,A.#3
>ok

7) просмотреть в ноде A данные дочерних нод
get A.*
>A.#1 5
>12345\r\n
>A.#2 5
>67890\r\n
>A.#3 5
>abcde
>ok

8) добавить в ноду A группу нод
*- данный пункт под вопросом
set A: B1,5 B2,5 B3,5
12345
>stored
67890
>stored
abcde
>stored

это равнозначно:
set A.B1,5 A.B2,5 A.B3,5

Пока не допустим шаблон a.*.b.*,
но допустим a.с.b.* и a.с.*.*

Версия первая, будет урезаться и дополняться.

FAQ

почему изобретаем велосипед?
да, скучно стало... надо освоить новые технологии.

какова предполагаемая нагрузка?
да, как получится...
где-то на уровне быстродействия редиса.
главное чтоб быстрее мускуля,
иначе нет смысла заморачиваться.

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

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

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

Собираетесь использовать индексы?
пока не вижу смысла. Как такового - у меня полнотекстного поиска нет и не планируется,
моя модель больше похожа на key-value БД.
поиск будет происходить по дереву каталогов, и после нахождения необходимых нод - будет формироваться вывод.

глубина ключа ограничена?
думаю пока сделать ограничения - 32 уровня.

а длинна простого ключа?
32 символа - думаю хватит... а может 16?

В Протоколе отсутствуют операции удаления?
Удалить не сложно, былоб что удалять. Конечно добавим удаление, сперва надо хоть что-то реализовать!

а как на счет UPDATE?
ну ее заменяет простой set

а какие клиенты будут поддерживаться?
был бы продукт, а как написать клиента, всегда найдутся желающие.
лично я, как РНРник - напишу клиента для РНР.

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