Сохранение в поток (постановка)
| Строка 8: | Строка 8: | ||
===Увеличение скорости=== | ===Увеличение скорости=== | ||
| − | Беглый анализ показывает, что основной проблемой сохранения | + | Беглый анализ показывает, что основной проблемой существующего сохранения является использование рекурсии и бизнес объектов. Сейчас работает так: |
| − | # начинаем сохранять запись определенного типа; | + | # начинаем сохранять запись определенного типа (запись бизнес-объекта); |
# создаем клиент датасет и переносим в него данные полей сохраняемой записи; | # создаем клиент датасет и переносим в него данные полей сохраняемой записи; | ||
| − | # | + | # записываем в поток служебную информацию и данные клиент датасета; |
| + | # находим поля-ссылки, создаем экземпляры бизнес-объектов соответствующего типа и рекурсивно вызываем процедуру сохранения в поток, т.е. переходим к п. 1; | ||
таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз. | таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз. | ||
| − | Итак, первый шаг -- мы отказываемся от рекурсии. А это значит, что мы будем повторно использовать объект одного типа, если ранее уже такой встречался. Точнее, рекурсия все же будет, но при сохранении объекта определенного типа, от которого зависит сохраняемый в данный момент времени объект, мы будем попадать (рекурсивно) в его же код! Следует быть осторожным и контролировать повторное использование ресурсов | + | Итак, первый шаг -- мы отказываемся от рекурсии. А это значит, что мы будем повторно использовать объект одного типа, если ранее уже такой встречался. Точнее, рекурсия все же будет, но при сохранении объекта определенного типа, от которого зависит сохраняемый в данный момент времени объект, мы будем попадать (рекурсивно) в его же код! Следует быть осторожным и контролировать повторное использование ресурсов. |
| − | Второй шаг -- отказаться от использования бизнес-объектов | + | Второй шаг -- отказаться от использования бизнес-объектов. Поскольку, мы не храним данных в ином месте, кроме как в реляционной базе, следовательно все должно сработать правильно и перенестись на другую базу корректно. |
| − | + | Отказавшись от бизнес объектов приходится брать на себя анализ структуры базы данных и по главной таблице бизнес объекта (GetListTable) находить все таблицы связанные связью один-к-одному, а так же таблицы элементов множества. Тут возникает интересный момент: у нас, главная таблица для любого документа -- это [[gd_document]], хотя специфические его данные хранятся в присоединенной таблице. При анализе связей таблицы gd_document находим 216 ссылающихся таблиц. Пока не ясно, стоит ли с этим смириться или каким-то образом отсекать таблицы, связанные с gd_document, но не имеющие отношения к типу сохраняемого бизнес-объекта. | |
Кроме того ускорение можно получить за счет кэширования связей таблиц. На данном этапе мы каждый раз вычисляем: | Кроме того ускорение можно получить за счет кэширования связей таблиц. На данном этапе мы каждый раз вычисляем: | ||
| Строка 29: | Строка 30: | ||
===Уменьшение размера файла=== | ===Уменьшение размера файла=== | ||
| + | |||
| + | Уменьшения размера файла мы добьемся за счет отказа от рекурсии при формировании потока данных. | ||
Версия 17:31, 13 января 2007
Требования к новому сохранению в поток:
- Увеличение скорости минимум в 10 раз;
- Уменьшение размера файла минимум в 10 раз (при использовании двоичного формата);
- Возможность сохранения в формате XML;
- Не использовать бизнес-объекты;
- Работать только с информацией о метаданных из реляционной БД. Сделать всю информацию, не укладывающуюся в реляционную схему, внешней по относительности к процессу сохранения (см. например, аттрибут "Перезаписывать данными из потока").
Увеличение скорости
Беглый анализ показывает, что основной проблемой существующего сохранения является использование рекурсии и бизнес объектов. Сейчас работает так:
- начинаем сохранять запись определенного типа (запись бизнес-объекта);
- создаем клиент датасет и переносим в него данные полей сохраняемой записи;
- записываем в поток служебную информацию и данные клиент датасета;
- находим поля-ссылки, создаем экземпляры бизнес-объектов соответствующего типа и рекурсивно вызываем процедуру сохранения в поток, т.е. переходим к п. 1;
таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз.
Итак, первый шаг -- мы отказываемся от рекурсии. А это значит, что мы будем повторно использовать объект одного типа, если ранее уже такой встречался. Точнее, рекурсия все же будет, но при сохранении объекта определенного типа, от которого зависит сохраняемый в данный момент времени объект, мы будем попадать (рекурсивно) в его же код! Следует быть осторожным и контролировать повторное использование ресурсов.
Второй шаг -- отказаться от использования бизнес-объектов. Поскольку, мы не храним данных в ином месте, кроме как в реляционной базе, следовательно все должно сработать правильно и перенестись на другую базу корректно.
Отказавшись от бизнес объектов приходится брать на себя анализ структуры базы данных и по главной таблице бизнес объекта (GetListTable) находить все таблицы связанные связью один-к-одному, а так же таблицы элементов множества. Тут возникает интересный момент: у нас, главная таблица для любого документа -- это gd_document, хотя специфические его данные хранятся в присоединенной таблице. При анализе связей таблицы gd_document находим 216 ссылающихся таблиц. Пока не ясно, стоит ли с этим смириться или каким-то образом отсекать таблицы, связанные с gd_document, но не имеющие отношения к типу сохраняемого бизнес-объекта.
Кроме того ускорение можно получить за счет кэширования связей таблиц. На данном этапе мы каждый раз вычисляем:
- какие таблицы имеют отношение один к одному к главной таблице;
- какие таблицы имеют ссылку на главную таблицу с доменом MASTERKEY;
- какие таблицы входят в SELECT-запрос бизнес-объекта;
Имеет смысл производить эти вычисления один раз для каждого класса + сабтайп.
Уменьшение размера файла
Уменьшения размера файла мы добьемся за счет отказа от рекурсии при формировании потока данных.
