Комментарии 27
Мало запутанных рисунков! Требую больше рисунков с большим количеством линий.!
транзакции будут?
пока не планируется,
нужны?
нужны?
разумеется.
сделать бы без них, прикрутить блокировки, дело не хитрое (я так думаю, когда ближе к делу, то видно будет чего копать и куда рыть...).
вообще-то я планирую использовать БД как гибкий справочник.
вообще-то я планирую использовать БД как гибкий справочник.
вообще-то тут дело не в блокировках а в журналировании. что будет если клиент между двумя связанными запросами на изменение упадёт? правильно, сломанная база данных.
имеется ввиду цикл транзакции:
BEGIN TRANSACTION
set…
set…
END TRANSACTION
нет, пока этого точно не планирую. Блокировку на запись прикручу обязательно.
Если буду делать транзакции, то уже сл. этапом, как развитие системы.
BEGIN TRANSACTION
set…
set…
END TRANSACTION
нет, пока этого точно не планирую. Блокировку на запись прикручу обязательно.
Если буду делать транзакции, то уже сл. этапом, как развитие системы.
создать создать пользователя
[тут скрипт упал]
поднять для только что созданного пользователя биллинг
[опа, пользователь есть, а биллинга нет]
далее каскадно падают все скрипты использующие биллинг
[тут скрипт упал]
поднять для только что созданного пользователя биллинг
[опа, пользователь есть, а биллинга нет]
далее каскадно падают все скрипты использующие биллинг
ну, на мой взгляд — эта бд в том виде, как я ее задумывал — для биллинга навряд ли пригодится. Она ограничена размером оперативки, как редис.
держать информацию блоками на файлах, и подгружать блоки по мере необходимости — это будет сл. этап, но тут сразу появятся тормоза. Это как sedna — быстра и удобна, пока все данные сидят в оперативки (на больших объемах обгоняет мускуль на ура), но как толькопоиск выходит за пределы блока, то наступают сильные тормоза.
Думаю, что возможен учет, если БД использовать как учетную систему с нарастающим итогом, т.е. в режиме счетчика кликов (без учета времени клика)
теперь ближе к телу:
мы создаем пользователя и поднимаем биллинг в пределах одной команды set (большой мультисет): если да, то целостность сохраниться. Либо команда выполниться, либо нет.
Один поток обслуживает одного клиента. Приняли команду, распарсили и выдали на исполнение.
если несколько сетов, то тут уж извините. Хотите целостность, Старайтесь вносить данные в пределах одного мультисета.
держать информацию блоками на файлах, и подгружать блоки по мере необходимости — это будет сл. этап, но тут сразу появятся тормоза. Это как sedna — быстра и удобна, пока все данные сидят в оперативки (на больших объемах обгоняет мускуль на ура), но как толькопоиск выходит за пределы блока, то наступают сильные тормоза.
Думаю, что возможен учет, если БД использовать как учетную систему с нарастающим итогом, т.е. в режиме счетчика кликов (без учета времени клика)
теперь ближе к телу:
мы создаем пользователя и поднимаем биллинг в пределах одной команды set (большой мультисет): если да, то целостность сохраниться. Либо команда выполниться, либо нет.
Один поток обслуживает одного клиента. Приняли команду, распарсили и выдали на исполнение.
если несколько сетов, то тут уж извините. Хотите целостность, Старайтесь вносить данные в пределах одного мультисета.
>что будет если клиент между двумя связанными запросами на изменение упадёт?
перезапишет эти данные, все что до падения передалось на сервер — будет внесено.
транзакции снижают скорость (это доп буфер, доп перемещения данных), а у меня пока основной критерий — это скорость.
перезапишет эти данные, все что до падения передалось на сервер — будет внесено.
транзакции снижают скорость (это доп буфер, доп перемещения данных), а у меня пока основной критерий — это скорость.
а попонятнее можно?
хм, а финал версия вашей db это… логотип хабра?
Ого, при такой структуре удаление и добавление элементов будет очень медленным же. Особенно учитывая отсортированность. Изменение элемента — да, будет быстрым, но изменение кол-ва элементов приведет к пересортировке структуры.
Думаю, изменение и удаление не очень частые операции. Я делал упор на выборку.
Вставка нового элемента будет относительно быстро: встака элемента в список Dir + добавление нового элемента (вместо из пула ) Node + сами данные (вместо из пула )
Удаление элемента — операция специфическая, удаление элемента из 2BIdx труда не представляет. Освобождение ячейки в Dir — надо память как-то вернуть в пул. В идеале, если это был последний элемент, то без проблем. Но, идеала не бывает, по этому необходимо учитывать сегментированные куски памяти. Можно на них забить (учитывть только %%) и, например при сегментированности в 30% просто тупо восстановить данные с диска (потеря производительности на 1 транзакции). Тут конечно надо будет эксперементировать.
Ну и конечно же вылезает проблема сегментации в пуле Data.
Вставка нового элемента будет относительно быстро: встака элемента в список Dir + добавление нового элемента (вместо из пула ) Node + сами данные (вместо из пула )
Удаление элемента — операция специфическая, удаление элемента из 2BIdx труда не представляет. Освобождение ячейки в Dir — надо память как-то вернуть в пул. В идеале, если это был последний элемент, то без проблем. Но, идеала не бывает, по этому необходимо учитывать сегментированные куски памяти. Можно на них забить (учитывть только %%) и, например при сегментированности в 30% просто тупо восстановить данные с диска (потеря производительности на 1 транзакции). Тут конечно надо будет эксперементировать.
Ну и конечно же вылезает проблема сегментации в пуле Data.
а вот вставка элемента в существующую структуру будет помедленней. Действительно, потребуется дополнительное время на просмотра списка дочерних элементов Node, и встака в него данного элемента.
Сортировка, очевидно потребуется только один раз — при создании списка Node нового уровня (вставляем элемент и подэлементы).
Сортировка, очевидно потребуется только один раз — при создании списка Node нового уровня (вставляем элемент и подэлементы).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
TreeDb. Структура данных