Сохранение в поток (постановка)
Материал из GedeminWiki
(Различия между версиями)
SYSDBA (обсуждение | вклад) (→Уменьшение размера файла) |
SYSDBA (обсуждение | вклад) |
||
| Строка 5: | Строка 5: | ||
# Не использовать бизнес-объекты; | # Не использовать бизнес-объекты; | ||
# Работать только с информацией о метаданных из реляционной БД. Сделать всю информацию, не укладывающуюся в реляционную схему, внешней по относительности к процессу сохранения (см. например, аттрибут "Перезаписывать данными из потока"). | # Работать только с информацией о метаданных из реляционной БД. Сделать всю информацию, не укладывающуюся в реляционную схему, внешней по относительности к процессу сохранения (см. например, аттрибут "Перезаписывать данными из потока"). | ||
| + | # Предусмотреть возможность сохранения только объектов измененных после указанной даты; | ||
| + | # Предусмотреть возможность инкрементного сохранения объектов. | ||
===Увеличение скорости=== | ===Увеличение скорости=== | ||
| Строка 13: | Строка 15: | ||
# создаем клиент датасет и переносим в него данные полей сохраняемой записи; | # создаем клиент датасет и переносим в него данные полей сохраняемой записи; | ||
# записываем в поток служебную информацию и данные клиент датасета; | # записываем в поток служебную информацию и данные клиент датасета; | ||
| − | # находим поля-ссылки, создаем экземпляры бизнес-объектов соответствующего типа и рекурсивно вызываем процедуру сохранения в поток, т.е. переходим к п. 1 | + | # находим поля-ссылки, создаем экземпляры бизнес-объектов соответствующего типа и рекурсивно вызываем процедуру сохранения в поток, т.е. переходим к п. 1. |
| − | + | Таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз. | |
| − | Итак, первый шаг -- мы отказываемся от рекурсии | + | Итак, первый шаг -- мы отказываемся от рекурсии и будем повторно использовать объект при необходимости. Второй шаг -- отказаться от использования бизнес-объектов. Поскольку, мы не храним данных в ином месте, кроме как в реляционной базе, следовательно все должно сработать правильно и перенестись на другую базу корректно. Отказавшись от бизнес объектов приходится брать на себя анализ структуры базы данных и по главной таблице бизнес объекта (GetListTable) находить все таблицы связанные связью один-к-одному, а так же таблицы элементов множества. |
| − | + | <pre> | |
| + | Тут возникает интересный момент: у нас, главная таблица для любого документа -- это [[gd_document]], хотя специфические его данные хранятся в присоединенной таблице. При анализе связей таблицы gd_document находим 216 ссылающихся таблиц. Пока не ясно, стоит ли с этим смириться или каким-то образом отсекать таблицы, связанные с gd_document, но не имеющие отношения к типу сохраняемого бизнес-объекта. | ||
| + | </pre> | ||
| − | + | Относительно существующего алгоритма, ускорение можно получить за счет кэширования системной информации о связях таблиц. Сейчас для каждого объекта вычисляется: | |
| − | + | # какие таблицы имеют отношение один-к-одному к главной таблице; | |
| − | + | ||
| − | # какие таблицы имеют отношение один к одному к главной таблице; | + | |
# какие таблицы имеют ссылку на главную таблицу с доменом MASTERKEY; | # какие таблицы имеют ссылку на главную таблицу с доменом MASTERKEY; | ||
| − | # какие таблицы входят в SELECT-запрос бизнес-объекта | + | # какие таблицы входят в SELECT-запрос бизнес-объекта. |
| − | + | ||
| + | В новом алгоритме имеет смысл производить эти вычисления один раз для каждого класса + сабтайпа. | ||
===Уменьшение размера файла=== | ===Уменьшение размера файла=== | ||
Версия 19:35, 13 января 2007
Требования к новому сохранению в поток:
- Увеличение скорости минимум в 10 раз;
- Уменьшение размера файла минимум в 10 раз (при использовании двоичного формата);
- Возможность сохранения в формате XML;
- Не использовать бизнес-объекты;
- Работать только с информацией о метаданных из реляционной БД. Сделать всю информацию, не укладывающуюся в реляционную схему, внешней по относительности к процессу сохранения (см. например, аттрибут "Перезаписывать данными из потока").
- Предусмотреть возможность сохранения только объектов измененных после указанной даты;
- Предусмотреть возможность инкрементного сохранения объектов.
Увеличение скорости
Беглый анализ показывает, что основной проблемой существующего сохранения является использование рекурсии и бизнес объектов. Сейчас работает так:
- начинаем сохранять запись определенного типа (запись бизнес-объекта);
- создаем клиент датасет и переносим в него данные полей сохраняемой записи;
- записываем в поток служебную информацию и данные клиент датасета;
- находим поля-ссылки, создаем экземпляры бизнес-объектов соответствующего типа и рекурсивно вызываем процедуру сохранения в поток, т.е. переходим к п. 1.
Таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз.
Итак, первый шаг -- мы отказываемся от рекурсии и будем повторно использовать объект при необходимости. Второй шаг -- отказаться от использования бизнес-объектов. Поскольку, мы не храним данных в ином месте, кроме как в реляционной базе, следовательно все должно сработать правильно и перенестись на другую базу корректно. Отказавшись от бизнес объектов приходится брать на себя анализ структуры базы данных и по главной таблице бизнес объекта (GetListTable) находить все таблицы связанные связью один-к-одному, а так же таблицы элементов множества.
Тут возникает интересный момент: у нас, главная таблица для любого документа -- это [[gd_document]], хотя специфические его данные хранятся в присоединенной таблице. При анализе связей таблицы gd_document находим 216 ссылающихся таблиц. Пока не ясно, стоит ли с этим смириться или каким-то образом отсекать таблицы, связанные с gd_document, но не имеющие отношения к типу сохраняемого бизнес-объекта.
Относительно существующего алгоритма, ускорение можно получить за счет кэширования системной информации о связях таблиц. Сейчас для каждого объекта вычисляется:
- какие таблицы имеют отношение один-к-одному к главной таблице;
- какие таблицы имеют ссылку на главную таблицу с доменом MASTERKEY;
- какие таблицы входят в SELECT-запрос бизнес-объекта.
В новом алгоритме имеет смысл производить эти вычисления один раз для каждого класса + сабтайпа.
Уменьшение размера файла
Уменьшения размера файла мы добьемся за счет отказа от рекурсии при формировании потока данных из-за которой мы имеем следующую внутреннюю структуру файла:
Служебная информация и заголовок датасета записываются практически перед каждой записью, что существенно раздувает файл. В новом формате, записи одного типа будут сгруппированы:
