TreeDb. Структура данных

[Imposeren]

Мало запутанных рисунков! Требую больше рисунков с большим количеством линий.!

[akalend]

излишняя детализация — вредна

[tenshi]

транзакции будут?

[akalend]

пока не планируется,
нужны?

[tenshi]

разумеется.

[akalend]

сделать бы без них, прикрутить блокировки, дело не хитрое (я так думаю, когда ближе к делу, то видно будет чего копать и куда рыть...).
вообще-то я планирую использовать БД как гибкий справочник.

[tenshi]

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

[akalend]

имеется ввиду цикл транзакции:
BEGIN TRANSACTION
set…
set…
END TRANSACTION

нет, пока этого точно не планирую. Блокировку на запись прикручу обязательно.

Если буду делать транзакции, то уже сл. этапом, как развитие системы.

[tenshi]

создать создать пользователя
[тут скрипт упал]
поднять для только что созданного пользователя биллинг
[опа, пользователь есть, а биллинга нет]

далее каскадно падают все скрипты использующие биллинг

[akalend]

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

держать информацию блоками на файлах, и подгружать блоки по мере необходимости — это будет сл. этап, но тут сразу появятся тормоза. Это как sedna — быстра и удобна, пока все данные сидят в оперативки (на больших объемах обгоняет мускуль на ура), но как толькопоиск выходит за пределы блока, то наступают сильные тормоза.

Думаю, что возможен учет, если БД использовать как учетную систему с нарастающим итогом, т.е. в режиме счетчика кликов (без учета времени клика)

теперь ближе к телу:
мы создаем пользователя и поднимаем биллинг в пределах одной команды set (большой мультисет): если да, то целостность сохраниться. Либо команда выполниться, либо нет.

Один поток обслуживает одного клиента. Приняли команду, распарсили и выдали на исполнение.

если несколько сетов, то тут уж извините. Хотите целостность, Старайтесь вносить данные в пределах одного мультисета.

[tenshi]

сделаешь тьюринг-полный мультисет? х)

[akalend]

постараюсь
а помочь не хочешь?

[tenshi]

неее %-)

[akalend]

а чего боишься?
Си — знаешь?

[tenshi]

угу, а ещё я знаю своего соседа… но это не значит, что я хочу с ним ебаться х)

[akalend]

ладно, буду ждать критики
вчера почвилась первая строчка кода

[akalend]

>что будет если клиент между двумя связанными запросами на изменение упадёт?
перезапишет эти данные, все что до падения передалось на сервер — будет внесено.

транзакции снижают скорость (это доп буфер, доп перемещения данных), а у меня пока основной критерий — это скорость.

[tenshi]

ну да, а целостность данных — сущий пустяк х))

[akalend]

приведи пример в контексте этой БД

[akalend]

можешь не приводить, примером выше ты правильно описал ситуацию

[stas_agarkov]

а попонятнее можно?

[akalend]

что конкретно непонятно?
предыстория вопроса в предыдущем посте (ссылка в самом начале поста).

[Homakov]

хм, а финал версия вашей db это… логотип хабра?

[akalend]

юмор оценен,
держи пять!

[xtender]

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

[akalend]

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

Вставка нового элемента будет относительно быстро: встака элемента в список Dir + добавление нового элемента (вместо из пула ) Node + сами данные (вместо из пула )

Удаление элемента — операция специфическая, удаление элемента из 2BIdx труда не представляет. Освобождение ячейки в Dir — надо память как-то вернуть в пул. В идеале, если это был последний элемент, то без проблем. Но, идеала не бывает, по этому необходимо учитывать сегментированные куски памяти. Можно на них забить (учитывть только %%) и, например при сегментированности в 30% просто тупо восстановить данные с диска (потеря производительности на 1 транзакции). Тут конечно надо будет эксперементировать.
Ну и конечно же вылезает проблема сегментации в пуле Data.

[akalend]

а вот вставка элемента в существующую структуру будет помедленней. Действительно, потребуется дополнительное время на просмотра списка дочерних элементов Node, и встака в него данного элемента.

Сортировка, очевидно потребуется только один раз — при создании списка Node нового уровня (вставляем элемент и подэлементы).