Сохранение в поток (постановка)
SYSDBA (обсуждение | вклад) |
SYSDBA (обсуждение | вклад) |
||
| Строка 1: | Строка 1: | ||
| + | Требования к новому сохранению в поток: | ||
| + | # Увеличение скорости минимум в 10 раз; | ||
| + | # Уменьшение размера файла минимум в 10 раз (при использовании двоичного формата); | ||
| + | # Возможность сохранения в формате XML; | ||
| + | # Не использовать бизнес-объекты; | ||
| + | # Работать только с информацией о метаданных из реляционной БД. Сделать всю информацию, не укладывающуюся в реляционную схему, внешней по относительности к процессу сохранения (см. например, аттрибут "Перезаписывать данными из потока"). | ||
| + | Требуется ускорить сохранение в поток. Цель: как минимум десятикратное ускорение и уменьшение размера файла. Беглый анализ показывает, что основной проблемой сохранения сейчас является использование рекурсии + бизнес объектов. Т.е. сейчас работает так: | ||
| − | + | # начинаем сохранять запись определенного типа; | |
| − | + | # создаем клиент датасет и переносим в него данные полей сохраняемой записи; | |
| − | + | # анализируем поля и для полей ссылок создаем экземпляры бизнес-объектов соответствующего типа и рекурсивно вызываем процедуру сохранения в поток, т.е. переходим к п. 1; | |
| − | + | ||
| − | + | ||
| − | + | ||
таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз. | таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз. | ||
| Строка 18: | Строка 22: | ||
отказавшись от бизнес объектов приходится брать на себя анализ структуры базы данных и по главной таблице бизнес объекта (GetListTable) находить все таблицы связанные связью один-к-одному, а так же таблицы элементов множества. тут возникает интересный момент. у нас главная таблица для любого документа -- это gd_document, хотя специфические его данные хранятся в присоединенной таблице. При анализе связей таблицы gd_document находим 216 ссылающихся таблиц. Пока не ясно, стоит ли с этим смириться или каким-то образом отсекать таблицы, связанные с gd_document, но не имеющие отношения к сохраняемому бизнес объекту. | отказавшись от бизнес объектов приходится брать на себя анализ структуры базы данных и по главной таблице бизнес объекта (GetListTable) находить все таблицы связанные связью один-к-одному, а так же таблицы элементов множества. тут возникает интересный момент. у нас главная таблица для любого документа -- это gd_document, хотя специфические его данные хранятся в присоединенной таблице. При анализе связей таблицы gd_document находим 216 ссылающихся таблиц. Пока не ясно, стоит ли с этим смириться или каким-то образом отсекать таблицы, связанные с gd_document, но не имеющие отношения к сохраняемому бизнес объекту. | ||
| − | + | Кроме того ускорение можно получить за счет кэширования связей таблиц. На данном этапе мы каждый раз вычисляем: | |
| + | # какие таблицы имеют отношение один к одному к главной таблице; | ||
| + | # какие таблицы имеют ссылку на главную таблицу с доменом MASTERKEY; | ||
| + | # какие таблицы входят в SELECT-запрос бизнес-объекта; | ||
| + | Имеет смысл производить эти вычисления один раз для каждого класса + сабтайп. | ||
Версия 20:03, 11 января 2007
Требования к новому сохранению в поток:
- Увеличение скорости минимум в 10 раз;
- Уменьшение размера файла минимум в 10 раз (при использовании двоичного формата);
- Возможность сохранения в формате XML;
- Не использовать бизнес-объекты;
- Работать только с информацией о метаданных из реляционной БД. Сделать всю информацию, не укладывающуюся в реляционную схему, внешней по относительности к процессу сохранения (см. например, аттрибут "Перезаписывать данными из потока").
Требуется ускорить сохранение в поток. Цель: как минимум десятикратное ускорение и уменьшение размера файла. Беглый анализ показывает, что основной проблемой сохранения сейчас является использование рекурсии + бизнес объектов. Т.е. сейчас работает так:
- начинаем сохранять запись определенного типа;
- создаем клиент датасет и переносим в него данные полей сохраняемой записи;
- анализируем поля и для полей ссылок создаем экземпляры бизнес-объектов соответствующего типа и рекурсивно вызываем процедуру сохранения в поток, т.е. переходим к п. 1;
таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз.
Итак, первый шаг -- мы отказываемся от рекурсии. А это значит, что мы будем повторно использовать объект одного типа, если ранее уже такой встречался. Точнее, рекурсия все же будет, но при сохранении объекта определенного типа, от которого зависит сохраняемый в данный момент времени объект, мы будем попадать (рекурсивно) в его же код! Следует быть осторожным и контролировать повторное использование ресурсов при такой организации кода.
Второй шаг -- отказаться от использования бизнес-объектов и брать данные непосредственно из базы. Поскольку, мы не храним данных в ином месте, кроме как в реляционной базе, следовательно все должно сработать правильно и перенестись на другую базу корректно.
отказавшись от бизнес объектов приходится брать на себя анализ структуры базы данных и по главной таблице бизнес объекта (GetListTable) находить все таблицы связанные связью один-к-одному, а так же таблицы элементов множества. тут возникает интересный момент. у нас главная таблица для любого документа -- это gd_document, хотя специфические его данные хранятся в присоединенной таблице. При анализе связей таблицы gd_document находим 216 ссылающихся таблиц. Пока не ясно, стоит ли с этим смириться или каким-то образом отсекать таблицы, связанные с gd_document, но не имеющие отношения к сохраняемому бизнес объекту.
Кроме того ускорение можно получить за счет кэширования связей таблиц. На данном этапе мы каждый раз вычисляем:
- какие таблицы имеют отношение один к одному к главной таблице;
- какие таблицы имеют ссылку на главную таблицу с доменом MASTERKEY;
- какие таблицы входят в SELECT-запрос бизнес-объекта;
Имеет смысл производить эти вычисления один раз для каждого класса + сабтайп.
