Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Если ты говоришь о проблеме с variant. При выполнении запроса для многих операций нужна информация о типе. Ну не может быть построен план запроса, если нет точной информации о типе полей. Максимум что есть в РСУБД — LOB, с которыми практически ничего нельзя сделать. Разве что явно получить, и явно сохранить. Сейчас появились система хранения xml — но это уже отдельный механизм.
S> Глеб пойми меня интересует как организовано хранение данных в Объектно-ориентированные БД. S> Меня РСУБД мало интересуют, я с локальными БД работаю в том числе и на прямую через API. S> В конце концов хочу свою Объектно-ориентированные БД залудить
Во блин, народу прибыло. Сколько народу писал, пишет и будет писать OODB.
Со своей стороны я поступил так. Рассмотрел модель хранения MS SQL (тогда еще 7.0), и Oracle (по какой версии уже не помню). Модель хранения на диске, в принципе у них нормально описаны в доках(за некоторыми для меня не важными исключениями). За основу взял MS SQL в силу простоты. После этого построил модель адресации. Чтобы один и тот же объект можно было адресовать как на диске, так и в памяти. Получил при этом два типа OID — логический OID для адресации извне, и физический OID с помощью которою получал адрес в памяти. При маршализации OID из логического в физический объект поднимался с диска (если он не был уже загружен). Менеджер памяти пользовался достаточно сложной структурой — что-то между хэш-таблицей и B+ деревом. На этом мой интерес кончился, продолжились будни.
С уважением, Gleb.
Re[11]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
S>> Глеб пойми меня интересует как организовано хранение данных в Объектно-ориентированные БД. S>> Меня РСУБД мало интересуют, я с локальными БД работаю в том числе и на прямую через API. S>> В конце концов хочу свою Объектно-ориентированные БД залудить GZ>Во блин, народу прибыло. Сколько народу писал, пишет и будет писать OODB. GZ>Со своей стороны я поступил так. Рассмотрел модель хранения MS SQL (тогда еще 7.0), и Oracle (по какой версии уже не помню). Модель хранения на диске, в принципе у них нормально описаны в доках(за некоторыми для меня не важными исключениями). За основу взял MS SQL в силу простоты. После этого построил модель адресации. Чтобы один и тот же объект можно было адресовать как на диске, так и в памяти. Получил при этом два типа OID — логический OID для адресации извне, и физический OID с помощью которою получал адрес в памяти. При маршализации OID из логического в физический объект поднимался с диска (если он не был уже загружен). Менеджер памяти пользовался достаточно сложной структурой — что-то между хэш-таблицей и B+ деревом. На этом мой интерес кончился, продолжились будни.
Я проще. Объекты это просто обертка над записью, привязанные к какому либо хранилищу. В записи прописывается точное место в подстриме.
Задача объекта считать данные, через свойства обратиться к полям, в том числе и ссылочным и вариантным.
Однотипные объекты хранились ввиде птаблиц (подстримов). Вся БД в едином стриме.
Для обмена хотел применить аналог твоего OID.
Связь подчинения ввиде двухнаправленных списков. Итд. Хотел транзации приделать. А потом "Да кому это нужно"
и забросил это дело. А руки чешуться
Хотя для некоторых задач применяю ее.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[12]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S> Я проще. Объекты это просто обертка над записью, привязанные к какому либо хранилищу. В записи прописывается точное место в подстриме. S> Задача объекта считать данные, через свойства обратиться к полям, в том числе и ссылочным и вариантным. S> Однотипные объекты хранились ввиде птаблиц (подстримов). Вся БД в едином стриме. S> Для обмена хотел применить аналог твоего OID. S> Связь подчинения ввиде двухнаправленных списков. Итд. Хотел транзации приделать. А потом "Да кому это нужно" S> и забросил это дело. А руки чешуться S> Хотя для некоторых задач применяю ее.
У меня руки чешутся сделать подобный DTO объект.
Что касается стрима — то он сильно подвержен дефрагментации. Страничная адресация с балансировкой по B+ tree типу в данном случае значительно более устойчивее. Всегда знаешь сколько байт поднимаешь с диска, быстрый поиск свободного пространства. А если еще задвинуть экстент по размеру кластера диска, то скорость доступа увеличивается на порядок. Есть конечно некоторый недостаток в избыточности, если объекты не попадают на границу экстента, и проблема организации хранения объекта большего чем экстент. Но в первом случае — производительность значительно важней, во втором случае — решабельно.
С уважением, Gleb.
Re[6]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Serginio1, Вы писали:
E>>Фишка в том, что в объектных БД объекты могут очень легко изменять свой размер. А хранилище должно с этим эффективно справляться. E>>А могут легко изменять свой размер потому, что в одном объекте может быть масса других объектов совершенно по разному организованных. S> Прежде всего объекты это ссылки и поля имеют некую структуру позволяющие определить местонахождение объекта, но сам он должен оптимально хранится, иначе можно на такую фрагментацию нарваться. Кстати изменение размера достигается очень легко, если представить объект как некоторый связный список кусков определенного размера.
Объекты -- ссылки?
Атрибуты объектом могут быть ссылками.
А так же объект может агрегировать другие объекты (которые не могут рассматриваться в БД как отдельные сущности).
E>> Например, объект может иметь в качестве атрибута вектор переменного размера из других объектов. Эти подчиненные объекты могут сами иметь в качестве атрибутов, скажем, множество других объектов и т.д. При отображении этого хозяйства в таблицы РСУБД требуются дополнительные усилия. А в ООСУБД объект сериализуется в двоичный блок и этот блок запихивается в файл хранилища. И, обычно, чтение/запись производится одной операцией, а не поиском нужных компонентов по разным табличкам (но и здесь возможны варианты, если ООСУБД поддерживает продвинутые ссылки между объектами). S> Да уж представляю как некое дерево с миллионами вершин сериализуется и десериализуется. В данном случае я говорю лишь об оптимальном хранении объектов, а не доступе к объектам.
Да нормально сериализуется. Особенно, если сериализация идет непосредственно на диск. В чем проблемы-то?
S>>> Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти. S>>> Или уже есть файловый GC ?????
E>>Конечно. У меня, например, хранилище реализовано так, чтобы переиспользовать место от удаленных объектов. И не нужно делать явных уплотнений файлов БД. S> Это обычная оочень старая техника, которая применяется как в Менеджерах памяти, так и в БД.
Так а тебя что интересует? Чтобы освободившиеся блоки затем объединялись в крупные свободные фрагменты?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Объектно-ориентированные БД: основные принципы, орга
GZ>У меня руки чешутся сделать подобный DTO объект. GZ>Что касается стрима — то он сильно подвержен дефрагментации. Страничная адресация с балансировкой по B+ tree типу в данном случае значительно более устойчивее. Всегда знаешь сколько байт поднимаешь с диска, быстрый поиск свободного пространства. А если еще задвинуть экстент по размеру кластера диска, то скорость доступа увеличивается на порядок. Есть конечно некоторый недостаток в избыточности, если объекты не попадают на границу экстента, и проблема организации хранения объекта большего чем экстент. Но в первом случае — производительность значительно важней, во втором случае — решабельно.
Чтение и запись идет страницами. Сначала хотел организовать кэширование страниц, но посмотрев на то, что система сама их кэширует отказался (пока). Для каждой таблицы свой набор страниц. Так что если запись находится на двух страницах особенно и не сказывается.
. За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
Эх а все равно интересно помучиться
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[7]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
E>>>Фишка в том, что в объектных БД объекты могут очень легко изменять свой размер. А хранилище должно с этим эффективно справляться. E>>>А могут легко изменять свой размер потому, что в одном объекте может быть масса других объектов совершенно по разному организованных. S>> Прежде всего объекты это ссылки и поля имеют некую структуру позволяющие определить местонахождение объекта, но сам он должен оптимально хранится, иначе можно на такую фрагментацию нарваться. Кстати изменение размера достигается очень легко, если представить объект как некоторый связный список кусков определенного размера.
E>Объекты -- ссылки? E>Атрибуты объектом могут быть ссылками. E>А так же объект может агрегировать другие объекты (которые не могут рассматриваться в БД как отдельные сущности).
В терминологии Валуе и Ссылочных типов. Смотря в какой БД. В самопальной можно все,что угодно. E>>> Например, объект может иметь в качестве атрибута вектор переменного размера из других объектов. Эти подчиненные объекты могут сами иметь в качестве атрибутов, скажем, множество других объектов и т.д. При отображении этого хозяйства в таблицы РСУБД требуются дополнительные усилия. А в ООСУБД объект сериализуется в двоичный блок и этот блок запихивается в файл хранилища. И, обычно, чтение/запись производится одной операцией, а не поиском нужных компонентов по разным табличкам (но и здесь возможны варианты, если ООСУБД поддерживает продвинутые ссылки между объектами). S>> Да уж представляю как некое дерево с миллионами вершин сериализуется и десериализуется. В данном случае я говорю лишь об оптимальном хранении объектов, а не доступе к объектам.
E>Да нормально сериализуется. Особенно, если сериализация идет непосредственно на диск. В чем проблемы-то?
Не спорю. Только такое хранение данных не оптимально.
S>>>> Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти. S>>>> Или уже есть файловый GC ?????
E>>>Конечно. У меня, например, хранилище реализовано так, чтобы переиспользовать место от удаленных объектов. И не нужно делать явных уплотнений файлов БД. S>> Это обычная оочень старая техника, которая применяется как в Менеджерах памяти, так и в БД.
E>Так а тебя что интересует? Чтобы освободившиеся блоки затем объединялись в крупные свободные фрагменты?
Нет в данном случае разговор идет об оптимальном хранении, был выдвинут тезис что в ООБД таблицы отсутствуют, как класс
А раз так, то должен быть некий менеджер файловой памяти или что типа GC.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[8]: Объектно-ориентированные БД: основные принципы, орган
<...> E>>Да нормально сериализуется. Особенно, если сериализация идет непосредственно на диск. В чем проблемы-то?
S> Не спорю. Только такое хранение данных не оптимально.
<...> S>>> Это обычная оочень старая техника, которая применяется как в Менеджерах памяти, так и в БД.
E>>Так а тебя что интересует? Чтобы освободившиеся блоки затем объединялись в крупные свободные фрагменты? S> Нет в данном случае разговор идет об оптимальном хранении, был выдвинут тезис что в ООБД таблицы отсутствуют, как класс S> А раз так, то должен быть некий менеджер файловой памяти или что типа GC.
Тогда нужно озвучить критерий оптимальности.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, eao197, Вы писали:
E>Тогда нужно озвучить критерий оптимальности.
Да критерий то один. Минимизация фрагментации памяти, и быстрый поиск свободного места.
Чем в общем и занимаются менеджеры памяти. Табличная (или в связных массивах) Организация хранения записей одинакового размера оптимизируют эту задачу.
Вот в общем то и все.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[14]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S> Чтение и запись идет страницами. Сначала хотел организовать кэширование страниц, но посмотрев на то, что система сама их кэширует отказался (пока). Для каждой таблицы свой набор страниц. Так что если запись находится на двух страницах особенно и не сказывается. За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
Здоровски.
Только сразу вопрос: каким образом адресуется единичный объект?
Отложенная запись без транзакционного механизма увеличит вероятность ошибки файла за счет недописанной полностью записи. S> Эх а все равно интересно помучиться
Re[10]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Тогда нужно озвучить критерий оптимальности. S> Да критерий то один. Минимизация фрагментации памяти, и быстрый поиск свободного места. S> Чем в общем и занимаются менеджеры памяти. Табличная (или в связных массивах) Организация хранения записей одинакового размера оптимизируют эту задачу. S> Вот в общем то и все.
Понятно.
Только мне кажется, что быстрый поиск свободного места и фрагментация напрямую не связаны.
Так же не считаю, что для всех задач фрагментация является проблемой. Например, есть некий маршрутизатор получает из одного канала запрос, сохраняет его ID в базу (типа BerkeleyDB) и передает в другой канал уже со своим ID. При получении ответа должен по своему ID найти исходный ID и отослать ответ в исходный канал. После этого удалить информацию из БД. При стабильной нагрузке окажется, что все изменения вносятся в один и тот же фрагмент файла данных БД (пусть и большой, если нагрузка велика). И даже если в какой-то момент этот фрагмент сильно фрагментирован, то это не будет играть роли, т.к. ОС закэширует этот фрагмент.
А как вы записями одинакового размера будете хранить атрибуты-строки, которые могут изменять свой размер?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S> . За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
А какой размер одной записи?
S> Эх а все равно интересно помучиться
Это точно, солидарен.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Serginio1, Вы писали:
S>> Чтение и запись идет страницами. Сначала хотел организовать кэширование страниц, но посмотрев на то, что система сама их кэширует отказался (пока). Для каждой таблицы свой набор страниц. Так что если запись находится на двух страницах особенно и не сказывается. За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было. GZ>Здоровски. GZ>Только сразу вопрос: каким образом адресуется единичный объект?
Есть номер записи в каждой записи. По нему находится страница на которыю (с которой) прописывается. GZ>Отложенная запись без транзакционного механизма увеличит вероятность ошибки файла за счет недописанной полностью записи.
Согласен, но чем только не пожертвуешь ради скорости. Подождем быструю энэргонезависимую память для введения быстрого транзакционного механизма.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[15]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> . За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
E>А какой размер одной записи?
Там такой тест, считывается имя файла, размер и подчиненные строки которые разбиваются на связанные записи по 24 символа.
Сама запись вроде 48 байт (24 байта , номер строки, prev, next Int64 чего мелочиться то) S>> Эх а все равно интересно помучиться
E>Это точно, солидарен.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[16]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
GZ>>Отложенная запись без транзакционного механизма увеличит вероятность ошибки файла за счет недописанной полностью записи. S> Согласен, но чем только не пожертвуешь ради скорости. Подождем быструю энэргонезависимую память для введения быстрого транзакционного механизма.
Если БД не гарантирует надежной фиксации транзакции, то как же ее БД-то называть?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, Serginio1, Вы писали:
S>>> . За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
E>>А какой размер одной записи? S> Там такой тест, считывается имя файла, размер и подчиненные строки которые разбиваются на связанные записи по 24 символа. S> Сама запись вроде 48 байт (24 байта , номер строки, prev, next Int64 чего мелочиться то)
А результат в 7 секунд был получен на пустой БД или уже на фрагментированной?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, eao197, Вы писали:
E>>>Тогда нужно озвучить критерий оптимальности. S>> Да критерий то один. Минимизация фрагментации памяти, и быстрый поиск свободного места. S>> Чем в общем и занимаются менеджеры памяти. Табличная (или в связных массивах) Организация хранения записей одинакового размера оптимизируют эту задачу. S>> Вот в общем то и все.
E>Понятно.
E>Только мне кажется, что быстрый поиск свободного места и фрагментация напрямую не связаны. E>Так же не считаю, что для всех задач фрагментация является проблемой. Например, есть некий маршрутизатор получает из одного канала запрос, сохраняет его ID в базу (типа BerkeleyDB) и передает в другой канал уже со своим ID. При получении ответа должен по своему ID найти исходный ID и отослать ответ в исходный канал. После этого удалить информацию из БД. При стабильной нагрузке окажется, что все изменения вносятся в один и тот же фрагмент файла данных БД (пусть и большой, если нагрузка велика). И даже если в какой-то момент этот фрагмент сильно фрагментирован, то это не будет играть роли, т.к. ОС закэширует этот фрагмент.
E>А как вы записями одинакового размера будете хранить атрибуты-строки, которые могут изменять свой размер?
А почему на Вы????
Вот описание. Прошу сильно не смеяться
Эта простенькая иерархическая БД позволяетхранить как струтурированные данные
так и неструктурированные. Пока без индексов и полностью не протестированная.
Основным классом для всего этого безобразия послужил TSSStream.
Суть его заключается в хранении данных в связанных страницах
одинакового размера наподобии файловой системы FAT но последовательность страниц
хранится отдельно в иерархическом массиве.
Родителем всех таблиц служит TSSCustomTable. Это виртуальный стрим взаимодействующий с
основным хранилищем (стримом) через класс TSSBD. Суть его таже, что и TSSStream.
Хранилищем цепочек последовательных страниц является класс TTableCepochki.
Это единственный класс которыйхранит ссылки на данные
в абсолютных смещениях в основном хранилище. Запись TTableCepochki имеет следующий вид
TCepochki=Record
CurrentRecord:Int64;// ссылка на смещение текущей страницы
NextCepochka:Int64;// сылка на следующую страницуend;
и должна быть обязательно кратна размеру страницы, чтобы запись не попадала на разрыв
страниц т.к. чтение идет напрямую в основном хранилище.
За информацию о таблицах отвечает класс TTableInfoOFTables структура его записи
PInfoOfTable=^TInfoOfTable;
TInfoOfTable= record
Cappacity:Int64; // Емкость таблицы
Size:Int64; // Объем записанных данных
RecordCount: Int64; // Количество записей в таблице если данные хранятся записями одинакового размера
FirstCepochka:Int64; // Абсолютный адрес первой цепочки
LastCepochka: Int64; // Абсолютный адрес последней цепочки
FirstDeleted: Int64; // Сыллка на первую удаленную запись в таблице
LastDeleted: Int64; // Сыллка на последнюю удаленную запись в таблицеend;
За запись, чтение, Открытие таблиц Отвечает класс TSSBD; Он имеет следующие поля класса
TSSBd=Class
Private
FStream:TStream; // Основное хранилище данных
CriticalSection:TCriticalSection; // На всякий случай на будущее
TableInfoOfTables:TTableInfoOFTables; // Информация о таблицах
TableCepochki:TTableCepochki; // Информация о цепчках
ArrayLocalInfo:Array of TLocalInfo; // Массив информации о таблицах
---------------------------------------------------------------------
TLocalInfo= Record
InfoOfTable:TInfoOFTable;
IndexArray:TBDArIndex;
end;
InfoOfTable:TInfoOFTable; // Это запись информации о таблице в памяти с
которой взамодействуют таблицы которая затем записывается в TTableInfoOFTables
IndexArray:TBDArIndex; // Это динамический иерархический масси (наподобии первичного индекса
таблиц Pasradox). В нем хранится последовательность страниц таблицы для быстрого поиска.
При открытии таблицы информация о страницах загружаетя из TCepochki и затем паралельно модифицируются.
Все таблицы одного типа имеют ссылки на эти данные.
Поиск страницы осуществляется следующим образом
//Const
// StranicaSize=1 shl 12;
i:=NewPosition shr 12;
CurrentStranica:=IndexArray[i];
indexInStranica:=NewPosition mod StranicaSize;
что достаточно быстро.
-------------------------------------------------------------------
На данный момент реализованы 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;
Небольшойпример записи в данные таблицы
j:=FindFirst(FileDir+'*.pas',faArchive,SearchRec);
While j=0 Do begin
MyTable2.ClearRecord; // очистка записи
// Заполнение полей записи данными
MyTable2.TableRecord.Int:=i;
MyTable2.TableRecord.Doub:=i;
MyTable2.FileName:=searchrec.Name;
//-----------------------------
StringList.LoadFromFile(FileDir+searchrec.Name);
For i:=0 to Stringlist.Count-1 Do
Begin
If Length(Stringlist[i])>0 Then
Begin
ChildTable.ClearRecord;
ChildTable.Stroka:=Stringlist[i];
ChildTable.AddRecord(MyTable2.TableRecord.Lines);// Добавление записи ChildTable и
// модификация поля записи MyTable2.TableRecord.Lines
inc(m);
end;
end;
MyTable2.AddRecord; // Добавление записи в MyTable2
J:=findNext(searchrec);
end;
//----------------------------------------------------------------------------------------
TTableStream, TSSTableBlob выполняют одну задачу хранение потока данных.
TTableStream данные всегда добавляются в конец таблицы. Сначала записывается длина потока а затем данные.
Но так как данные хранятся друг за другом запрещена модификация и удаление. Данная таблица хороша тогла
когда не нужна модификация данных.
TSSTableBlob это классическая блоб таблица. Данные хранятся в связанных записях имеющих вид
PSmallBlobRecord=^TSmallBlobRecord;
TSmallBlobRecord= record
NextRecord:Int64; // Ссылка на следующую запись с данными
Data:Array[0..LenRec-sizeOf(Int64)-1] of char;
end;
Где LenRec длина записи и должна быть кратна размеру страницы.
В начале первой записи прописывается длина данных.
Удобно работать со стримами в таком виде
TMyChildTable= class(TSSChildTable)
TableRecord:TMyChildRecord;
protected
procedure SetStroka(const Value: String);
function GetStroka: String;
public
Constructor Create(SSBd:TSSBd); Override;
Property Stroka:String read GetStroka write SetStroka;
end;
function TMyChildTable.GetStroka: String;
begin
if TableRecord.Str>0 Then
Result:=SmallBlobTable.ReadAsString(TableRecord.Str)
Else
result:='';
end;
procedure TMyChildTable.SetStroka(const Value: String);
begin
if TableRecord.Str>0 Then
SmallBlobTable.ModifyFromString(TableRecord.Str,Value)
else
TableRecord.Str:=SmallBlobTable.WriteFromString(Value);
end;
где SmallBlobTable является наследником TSSTableBlob.
Каждая таблица должна именть свой уникальный ID который является номером записи в TTableInfoOFTables
type
TTablesID=(soTableInfoOFTables,soTableCepochki,soTableStream,soSmallBlobTabble,somyTable,somyTable2,soChildTable,soChildTable2,sotableCount);
Первыедва номера зарезервированы за TableInfoOFTables,TableCepochki.
Нужно в конструкторе определить начальные данные
constructor TmyTable.Create(SSBd: TSSBd);
begin
TableId:=integer(soMyTable);
Self.CurrentRecord:=@Self.tableRecord;
Self.SizeRecord:=SizeOf(TMyRec);
inherited Create(SSBd);
end;
Для теста была выбрана слетующая структура бд.
myTable хранит название файлов;
MyChildTable хранит ссылки на строки данного файла в SmallBlobTable или TStreamTable;
То есть задействованы все виды таблиц.
У меня Athlon XP 2400+, память 750 МБ РС 3200, частота шины 133 и Винт Сигейт St3820021А (7500 оборотов),
Файловая система NTFS (FAT у меня быстрее на 10-15%)
были показаны следующие данные
------------- Проверка стрим таблы --------------------------------------------
Время записив в стрим табле=3.891
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер стрим табле=8259756
Время чтения и сравнения в стрим табле=1.375
------------- Проверка блоб таблы --------------------------------------------
Время записив в блоб табле=4.437
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер смал блоб табле=14212000
Количество записей в смал блоб табле=444125
Время чтения и сравнения в смал блоб табле=1.484
=========== Модификация Блоб таблы ===========
Время модификации в блоб табле=3.468
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер смал блоб табле=14242816
Количество записей в смал блоб табле=445088
Время чтения и сравнения в смал блоб табле=1.516
То же но хранеие данных в пмяти
------------- Проверка блоб таблы в TSSStream --------------------------------------------
Время записив в блоб табле=1
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер смал блоб табле=14212000
Количество записей в смал блоб табле=444125
Время сохранения TSSStream в файл=0.109
Время загрузки из файла в TSSStream=0.11
Время чтения и сравнения в смал блоб табле=0.625
=========== Модификация Блоб таблы ===========
Время модификации в блоб табле=1
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер смал блоб табле=14242816
Количество записей в смал блоб табле=445088
Время чтения и сравнения в смал блоб табле=0.641
Скорость записи и чтения в память у меня получилась всего в 4 раза быстрее чем на диск
(Чтение файлов составляет 0.2 сек). У кого диски не очень быстрые и размер БД небольшой
есть смысл хранить данные в памяти а затем скидывать на диск.
Затем был проведен тест хранение всего потока данных файлов в SmallBlobTable и TStreamTable;
------------- Проверка записи файлов стрим таблы --------------------------------------------
Время записи в стрим табле=0.282
Количество Файлов =133
Размер стрим табле=7033394
Время чтения и сравнения в стрим табле=0.203
------------- Проверка записи файлов блоб таблу --------------------------------------------
Время записив в стрим табле=1
Количество Файлов =133
Размер стрим табле=9376352
Время чтения и сравнения в стрим табле=0.687
------------- Модификации записи файлов блоб таблу --------------------------------------------
Время модификации в блоб табле=1.328
Количество Файлов =266
Размер блоб табле=9376352
Количество записей в блоб табле=293011
------------- Проверка Модификации файлов блоб таблу --------------------------------------------
Время чтения и сранения в блоб табле=0.656
Размер блоб табле=9376352
Количество записей в блоб табле=293011
Сдесь следует отметить, что размер блоб табле составляетвего 32 байта и при увеличении
размера до размера страницы скорость будет такой же как и стрим таблы.
Имеет смысл хранить полчиненные данные ввиде потоков данных. Например строчную часть
документа записывать в стрим и передавать его для записи в главную таблицу.
Также проведен тест на скорость храненияи чтения обыкновенной таблицы
=========== Запись в MyTable ===========
Время Записи=7.547
Количество записей в MyTable =1000001
=========== Чтение в MyTable ===========
Время Чтения=1.407
Количество записей в MyTable =1000001
Хотя скорости и не оправдали моих надежд (слишком много накладных расходов) но
по сравнению с 1С это самолет.
Хотя пока индексы еще не прикручены и достаточна сырая и полностью не протестированная система но
вполне работоспособна. Буду рад любым замечаниям, предложением.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Если БД не гарантирует надежной фиксации транзакции, то как же ее БД-то называть?
Если подойти буквоедчески, то БД — это просто совокупность объектов. В данном случае, вы наверно хотели сказать СУБД. Но пока мы и не говорили о полноценности решения Serginio1 как современной СУБД и исполнению каких либо стандартов.
С уважением, Gleb.
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
GZ>>>Отложенная запись без транзакционного механизма увеличит вероятность ошибки файла за счет недописанной полностью записи. S>> Согласен, но чем только не пожертвуешь ради скорости. Подождем быструю энэргонезависимую память для введения быстрого транзакционного механизма.
E>Если БД не гарантирует надежной фиксации транзакции, то как же ее БД-то называть?
Ну за 2 недели это называется просто поделкой. У нее была простая задача переноса сложных иерархических данных с быстрым чтением и записью.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>А результат в 7 секунд был получен на пустой БД или уже на фрагментированной?
На пустой. Да смысл даже не в этом. Фрагментация роли не играет. Это просто маленький задача эффективного обмена данных сложной иерархии.
Т.К. XML, Аксессы и прочие локальные Бд были отметены из за медлительности и малопригодности.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Сколько народу писал, пишет и будет писать OODB. 
