Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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


Serginio ©   (2003-05-21 16:30:00) 

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-23 18:12:00) [1]

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


Zacho   (2003-05-23 17:59:00) [2]

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

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

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


Serginio   (2003-05-23 17:47:00) [3]

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


Zacho   (2003-05-23 17:38:00) [4]

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


Zacho   (2003-05-23 17:29:00) [5]


> Serginio (23.05.03 17:17)

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


Serginio   (2003-05-23 17:17:00) [6]

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


Zacho   (2003-05-23 17:06:00) [7]


> Serginio (23.05.03 16:45)

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


Serginio   (2003-05-23 16:45:00) [8]

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


iZEN   (2003-05-23 16:35:00) [9]

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


Serginio   (2003-05-23 16:21:00) [10]

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


Danilka   (2003-05-23 16:13:00) [11]

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


Serginio   (2003-05-23 13:41:00) [12]

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


Alexandr   (2003-05-23 13:39:00) [13]

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


Serginio   (2003-05-23 13:22:00) [14]

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


Alexandr   (2003-05-23 08:56:00) [15]

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


гончий   (2003-05-23 08:41:00) [16]

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


Alexandr   (2003-05-23 07:31:00) [17]

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


Serginio   (2003-05-22 12:51:00) [18]

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


Наверх

Титульная страница Поиск, карта сайта Написать письмо