Сохранение в поток (постановка)
SYSDBA (обсуждение | вклад) (→Сценарии использования сохранения в поток) |
SYSDBA (обсуждение | вклад) (→Сценарии использования сохранения в поток) |
||
| Строка 35: | Строка 35: | ||
|- valign="top" | |- valign="top" | ||
|Пользователь имеет головную базу и несколько перефирийных, на которых происходит редактирование данных. Периодически данные с перефирийных баз передаются на головную для консолидации, причем изменения от головной базы данных не передаются на перефирийные и изменения от одной перефирийной базы данных не передаются на другую. | |Пользователь имеет головную базу и несколько перефирийных, на которых происходит редактирование данных. Периодически данные с перефирийных баз передаются на головную для консолидации, причем изменения от головной базы данных не передаются на перефирийные и изменения от одной перефирийной базы данных не передаются на другую. | ||
| − | | | + | |Возможности инкрементной передачи данных. Т.е. перадаваться должны только объекты измененные (добавленные) с момента последней передачи. |
|- valign="top" | |- valign="top" | ||
|Пользователь имеет несколько баз между которыми необходим полный обмен информацией (репликация). | |Пользователь имеет несколько баз между которыми необходим полный обмен информацией (репликация). | ||
| − | | | + | |Замены внешней утилиты репликации. |
|} | |} | ||
Версия 14:59, 4 сентября 2007
Требования к новому сохранению в поток:
- Увеличение скорости минимум в 10 раз;
- Уменьшение размера файла минимум в 10 раз (при использовании двоичного формата);
- Возможность сохранения в формате XML;
- Не использовать бизнес-объекты;
- Работать только с информацией о метаданных из реляционной БД. Сделать всю информацию, не укладывающуюся в реляционную схему, внешней по относительности к процессу сохранения (см. например, аттрибут "Перезаписывать данными из потока").
- Предусмотреть возможность сохранения только объектов измененных после указанной даты;
- Предусмотреть возможность инкрементного сохранения объектов;
- Предусмотреть возможность расширенного и краткого отображения информации о ходе процесса. Дать пользователю возможность прервать процесс в любой момент времени;
- Предусмотреть возможность запуска процесса из командной строки;
- Предусмотреть возможность сохранения всей базы данных в потоке;
- Процедура должна обрабатывать миллион записей на компьютере с 512 Мб оперативной памяти за приемлемое время;
- Формирование потока данных и загрузка его на базу должна осуществляться не в монопольном режиме.
См. сравнение механизмов репликации и сохранения данных в поток в статье Сохранение в поток и репликация.
Содержание |
Сценарии использования сохранения в поток
| Сценарий | Чего хотим добиться |
|---|---|
| Пользователь выбирает объект или группу объектов и сохраняет их в поток. | Минимум десятикратного ускорения по сравнению с действующим алгоритмом. Меньшего размера файла. Контроля над ходом процесса. Возможности прервать процесс в любой момент времени. |
| Пользователь указывает сохранить в поток объекты, измененные после указанной даты. | Аналогично предыдущему. Система производит в базе данных поиск всех объектов, измененных после указанной даты (как быть со множествами?). |
| Разработчик сохраняет настройку в формате XML. | Текстовый файл, содержащий настройку ввиде форматированного XML, можно сравнить с прежней версией настройки и таким образом определить что было изменено. Такие настройки можно помещать в хранилище StarTeam и использовать систему контроля версий. |
| Пользователь производит загрузку потока на базу данных. | Ускорения процесса. Контроля над ходом выполнения и возможности прервать процесс в любой момент времени. Внятного разрешения конфликтных ситуаций: Обновлять записи всегда, Обновлять записи только если они новее, чем те, что находятся в базе данных, Пропускать записи. Возможности выставить действие по-умолчанию как для всего процесса, так и для объектов конкретного типа. |
| Пользователь имеет головную базу и несколько перефирийных, на которых происходит редактирование данных. Периодически данные с перефирийных баз передаются на головную для консолидации, причем изменения от головной базы данных не передаются на перефирийные и изменения от одной перефирийной базы данных не передаются на другую. | Возможности инкрементной передачи данных. Т.е. перадаваться должны только объекты измененные (добавленные) с момента последней передачи. |
| Пользователь имеет несколько баз между которыми необходим полный обмен информацией (репликация). | Замены внешней утилиты репликации. |
Увеличение скорости
Беглый анализ показывает, что основной проблемой существующего сохранения является использование рекурсии и бизнес объектов. Сейчас работает так:
- начинаем сохранять запись определенного типа (запись бизнес-объекта);
- создаем клиент датасет и переносим в него данные полей сохраняемой записи;
- записываем в поток служебную информацию и данные клиент датасета;
- находим поля-ссылки, создаем экземпляры бизнес-объектов соответствующего типа и рекурсивно вызываем процедуру сохранения в поток, т.е. переходим к п. 1.
Таким образом, в процессе сохранения объект одного и того же типа может создаваться неограниченное число раз.
Итак, первый шаг -- мы отказываемся от рекурсии и будем повторно использовать объект при необходимости. Второй шаг -- отказаться от использования бизнес-объектов. Поскольку, мы не храним данных в ином месте, кроме как в реляционной базе, следовательно все должно сработать правильно и перенестись на другую базу корректно. Отказавшись от бизнес объектов приходится брать на себя анализ структуры базы данных и по главной таблице бизнес объекта (GetListTable) находить все таблицы связанные связью один-к-одному, а так же таблицы элементов множества.
Тут возникает интересный момент: у нас, главная таблица для любого документа -- это gd_document, хотя специфические его данные хранятся в присоединенной таблице. При анализе связей таблицы gd_document находим 216 ссылающихся таблиц. Пока не ясно, стоит ли с этим смириться или каким-то образом отсекать таблицы, связанные с gd_document, но не имеющие отношения к типу сохраняемого бизнес-объекта.
Шаг третий -- относительно существующего алгоритма, ускорение можно получить за счет кэширования системной информации о связях таблиц. Сейчас для каждого объекта вычисляется:
- какие таблицы имеют отношение один-к-одному к главной таблице;
- какие таблицы имеют ссылку на главную таблицу с доменом MASTERKEY;
- какие таблицы входят в SELECT-запрос бизнес-объекта.
В новом алгоритме имеет смысл производить эти вычисления один раз для каждого класса + сабтайпа.
Почему использование бизнес-объекта замедляет процесс?
- Бизнес-объект является наследником от класса TIBDataSet и уже в силу этого он медленее при обращении к данным чем легковесный TIBSQL;
- Формирование, последующий парсинг и переформирование запроса бизнес-объекта занимают значительное время;
- При создании экземпляра бизнес-объекта в скрипт-контрол загружаются скрипт-функции перекрытых методов;
Использование пула объектов сведет к минимуму затраты по первым двум пунктам, но проблема отключения макросов для конкретного объекта остается не решенной. если решить ее, то можно работать с бизнес-объектами вместо таблиц из базы.
Отказ от использования бизнес-объектов исключает использование дополнительной функциональности присущей им. Т.е. мы сможем загрузить данные в базу, но не обработать их. Например, бизнес-объекты, отвечающие за мета-данные (таблицы, поля, домены и т.д.), не только сохраняют служебную информацию, но и изменяют структуру базы данных. При упрощенном подходе сохранения/загрузки данных в поток мы теряем данную функциональность.
Уменьшение размера файла
Уменьшения размера файла мы добьемся за счет отказа от рекурсии при формировании потока данных из-за которой мы имеем следующую внутреннюю структуру файла:
Служебная информация и заголовок датасета записываются практически перед каждой записью, что существенно раздувает файл. В новом формате, записи одного типа будут сгруппированы:
