Выложил простенькую Иерархическую БД

← →
Serginio (2003-05-21 16:30) [0]

http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019

Эта простенькая иерархическая БД позволяетхранить как струтурированные данные
так и неструктурированные в одном потоке (TfileStream или любом аналоге TmemorySream). Пока без индексов и полностью не протестированная.
Суть его заключается в хранении данных в связанных страницах
одинакового размера наподобии файловой системы FAT но последовательность страниц
хранится отдельно в иерархическом массиве.
Родителем всех таблиц служит TSSCustomTable. Это виртуальный стрим взаимодействующий с
основным хранилищем (стримом) через класс TSSBD.
Хранилищем цепочек последовательных страниц является класс TTableCepochki.
Это единственный класс которыйхранит ссылки на данные
в абсолютных смещениях в основном хранилище. Запись TTableCepochki имеет следующий вид
На данный момент реализованы 4 таблицы для хранения данных
TSSTable
TSSChildTable
TTableStream
TSSTableBlob

TSSTable это обычная струтурированная таблица. Отличием ее является наличие в начале
записи Номер этой записи в таблице. Который является уникальным значением для данной записи.
Это поле на данный момент может являться ссылкой на следующую удаленную запись.
Методы данной таблицы достаточно понятны.
TSSChildTable это подчиненная таблица в начале записи которой обязательно должна быть структура
PChildRecord=^TChildRecord;
TChildRecord = record
RecordNumber:TRecordNumber;
NextRecordNumber:TRecordNumber; // сылка на следующую запись
PriorRecordNumber:TRecordNumber; // ссылка на предыдущую запись
end;
Запись родительской таблицы должна содержать поле типа
PChildLines=^TChildLines;
TChildLines = Record
FirstLines:Int64;
LastLines:Int64;
end;
TTableStream, TSSTableBlob выполняют одну задачу хранение потока данных.
TTableStream данные всегда добавляются в конец таблицы. Сначала записывается длина потока а затем данные.
Но так как данные хранятся друг за другом запрещена модификация и удаление. Данная таблица хороша тогла
когда не нужна модификация данных.
TSSTableBlob это классическая блоб таблица. Данные хранятся в связанных записях имеющих вид
PSmallBlobRecord=^TSmallBlobRecord;
TSmallBlobRecord= record
NextRecord:Int64; // Ссылка на следующую запись с данными
Data:Array[0..LenRec-sizeOf(Int64)-1] of char;
end;
Где LenRec длина записи и должна быть кратна размеру страницы.
В начале первой записи прописывается длина данных.
Этот тип таблиц хорош для модификации данныз.
Хотя скорости и не оправдали моих надежд (раз 20 медленнее при записи большими блоками данных а не по одной записи. Все таки достаточно быстро.

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

← →
Serginio (2003-05-22 12:51) [1]

Помогите ссылочками на механизмы транзакций и отката. Впринципе знаю как сделать, но чужой опыт не помешает.

← →
Alexandr (2003-05-23 07:31) [2]

а зачем это все?

← →
гончий (2003-05-23 08:41) [3]

Правильно делает, что пишет, это, кстати, очень интересная область в программировании(мне нравится)

← →
Alexandr (2003-05-23 08:56) [4]

чем бы дитя не тешилось...

← →
Serginio (2003-05-23 13:22) [5]

2(Alexandr)
А хотелось уйти от реляционных баз с их нормализацией. И посмотреть на возможную скорость. Определенного результата добился, причем в лучшую сторону.Если учесть, что потратил всего 2 недели получилось не совсем уж и плохо. Надоело работать с закрытым кодом. А применение хранение любой иерархической информации где реляционные БД не совсем пригодны, а Streama не совсем хватает,от IStorage тоже не в восторге.

← →
Alexandr (2003-05-23 13:39) [6]

ну-ну... На 10 записях быстро работает? а на мильёне?
Где ты закрытый код увидел? Firebird

← →
Serginio (2003-05-23 13:41) [7]

Запись милион записей 7 секунд чтение 1 секунда.

← →
Danilka (2003-05-23 16:13) [8]

Интересно, записал, посмотрю на выходных что это за зверь.
Только, на сайте глюк какой-то с кнопкой "скачать файл", полностью закачался только на 4-й раз, первый раз - только 100 килобайт, второй и третий раз вообще файл не залился. Никаких сообщений, никаких ошибок, спрашивает, куда файл положить и отрубается. И это при том, что у меня даже не выделенка - сам провайдер.
Лучше-бы просто ссылка на файл была.

← →
Serginio (2003-05-23 16:21) [9]

Да там не очень хорошо со скачиванием. Но исторически так сложилось, что свои разработки храню там, хотя 1С уже и не пахнет.

← →
iZEN (2003-05-23 16:35) [10]

Почему бы не обратить внимание на Borland JDataStore6?

← →
Serginio (2003-05-23 16:45) [11]

А сколько Borland JDataStore6 весит. Ява машина. Я не совсем правильно выразился насчет БД. Но это скорей не БД а хранилище аналог IStorage но работа с ней как с БД. Если прикрутить транзакции и индексы, что не очень трудно есть альтернативный способ хранения данных (не обязательно промышленных объемов хотя и это возможно). А занимает она копейки.

← →
Zacho (2003-05-23 17:06) [12]

> Serginio (23.05.03 16:45)

Вот с полноценными транзакциями - самые большие проблемы и возникнут.

← →
Serginio (2003-05-23 17:17) [13]

>Zacho © (23.05.03 17:06)
По этому то и задал этот вопрос в Serginio (22.05.03 12:51).
Мое видение транзакций. Так как я веду запись через посредника и зная смещение в файле записываемого буфера я могу считать старое значение и в отдельный файл записать смещение,размер,стараязапись. Если транзакция откатилась зная предысторию вернуть все обратно. Но это самый элементарный подход. Пока о многопользовательском режиме не думаю. Но MultiReadWriteExclusive для данных скоростей вполне подходит.

← →
Zacho (2003-05-23 17:29) [14]

> Serginio (23.05.03 17:17)

Извини, честно говоря сейчас лень вникать, но мне кажется, что ты задумываешь нечто типа версионности. Если это так, то посмотри на http://www.ibase.ru/develop.htm статьи об архитектуре InterBase и транзакциях. Еще можешь посмотреть исходники IB/FB - ссылки там же, на www.ibase.ru
И подумай, осилишь ты примерно такое или нет. Если осилишь - новый кайфный версионник может получиться :-)

← →
Zacho (2003-05-23 17:38) [15]

Немного добавлю.
В однопользовательском режиме транзакции не очень-то и нужны, а как потребуется многопользовательский, так и начнется... Подумай, как (и какие) у тебя будут работать уровни изоляции транзакций. И т.д. и т.п. Вобщем, это далеко не тривиальная задача. Но очень интересная :)

← →
Serginio (2003-05-23 17:47) [16]

2(Zacho ) Это как раз все понятно.Правда MultiReadWriteExclusive снимает всю сложность. Работая напрямую с файлами 1С и перелопачивая милионы записей задержка в несколько секунд не такая уж и значительная (Если учесть скорость работы 1С). А одновременные транзакции сами очень сильно тормозят. Большое спасибо за совет. А в однопользовательском режиме транзакции нужны для отката сделанных изменений.

← →
Zacho (2003-05-23 17:59) [17]

> Serginio (23.05.03 17:47)
> А в однопользовательском режиме транзакции нужны
> для отката сделанных изменений.

Нет, imho для этого транзакции (по крайней мере то, что под ними понимается в РСУБД) не нужны. Для этого достаточно механизма типа CachedUpdates, который на порядок проще.

А все-таки, если заинтересуешься, почитай о архитектуре IB. Тем более, что и исходники доступны, а тема действительно очень любопытная. Заодно можешь почитать что-нибудь о архитектуре блокировочников - MS SQL и т.п. Но на это ссылки дать не могу, не знаю.
Будет очень интересно посмотреть, как ты реализуешь транзакции.

← →
Serginio (2003-05-23 18:12) [18]

CachedUpdates хорош, тогда когда это касается только одной таблицы. Когда на основании этих данных модифицируется множество других таблиц, как раз и нужен механизм отката. Вообще множественного чтения и записи впринципе осуществима, но и очень затратна по времени. Вот здесь и нужен выбор между MultiReadWriteExclusive. Что в итоге окажется быстрее. Есть еще один подводный камень множественного чтения и записи это индексы.
Тоесть при модификации читающая сторона должна всегда помнить, что считаная страница может быть недействительна. Итд итп.
Я за MultiReadWriteExclusive практически полное решение всех проблем. А задержка при данных скоростях минимальна. Возможно прекращение длительного чтения с востановлением данных при повторном чтении.

Выложил простенькую Иерархическую БД Найти похожие ветки