Да еще как по-новому!



Posted by Аркадий Водяник on June 22, 1999 at 08:10:12:

In Reply to: Комментарий к службе каталогов ФБП. Документы будут храниться по-новому? posted by Анатолий Анимица on June 21, 1999 at 10:20:36:

Анатолий Антонович говорит:

Оптимизация алгоритмов "в N раз" никогда меня не вдохновляла,
лишь снижение порядка полиномиальной сложности способно продвинуть масштаб системы
принципиально.

Ну хорошо, вот Вам снижение порядка сложности, уже реализованное в (еще не размещенной)
версии 3.03. Наряду с заведением 12-ти каталогов в каталоге TXA (все же я считаю это
очень полезным мероприятием), я встроил в Сервер такой алгоритм:

Когда идет пересбивка баланса и обрабатыватся очередная операция, содержащая
конструкцию "создать документ", Сервер выполняет такую проверку (в этом фрагменте
используем псевдокод; тройные подчеркивания обозначают внутренние функции Сервера,
все переменные тоже внутренние):


----------------------------------------------------------------------
u=[___stamp 3] извлекаем уникальный код операции
x=[___stamp 2] извлекаем время последнего введения/изменения операции
y=[___get u] извлекаем связанное с уникальным кодом время предыдущего
введения/изменения (ИЗ ОЗУ, ПО НАШЕМУ ИНДЕКСУ - БЫСТРО!!!)
если операция еще ни разу не встречалась Серверу, переменная y
будет иметь нулевое значение
if x = y goto НЕЧЕГО_ДЕЛАТЬ Ура, никаких открытий-закрытий файлов в большинстве случаев!
* но иногда (то есть всегда при старте Сервера, a затем - только при изменении операции)
* не везет - надо поработать с файлами
[__set u,x] запоминаем новое время введения/изменения операции
* все, что написано дальше, уже есть в версии 3.02
if x = [первая строка соответсвующего *.des] goto НЕЧЕГО_ДЕЛАТЬ
.....
ну а иначе обновляем *.txa и *.des
.....
:НЕЧЕГО_ДЕЛАТЬ
------------------------------------------------------------------------

Итак, мы вплотную приблизились к теоретически возможному максимуму скорости
работы с первичными документами. И ведь с масштабируемостью все хорошо?






Пpишедшие ответы: