Как разгрузить базу?!

[Duedev]

Вообщем проблема следующая:
Есть база в которой ведется регистрация клиентов, история взаимоотношений и прочее.
У каждого клиента есть свой менеджер, ответственный за клиента(осуществляющий с ним деловые контакты и прочее).
Так вот что получается: динамика работы с клиентами бешенная, документов в базе накапливается туча, но ведь по идее каждому менеджеру нет необходимости знать(если только опционально) о работе других менеджеров... Может кто-то сталкивался с подобной проблемой?
Первое, что приходит в голову оставить общую базу и для каждого менеджера создать свою, наладить механизм синхронизации данных, и грузить только те документы из общей базы которые нужны данному менеджеру(в документах есть поле "ответственный менеджер").
Может кто даст совет как лучше быть или какие подводные камни могут возникнуть в моем варианте?

PS: Приследуемая цель лишь одна - увеличить производительность базы или скорость работы менеджеров(что, впринципе, одно и тоже)

 

[GROMILA]

Ну тебе решать, посоветовать особо нечего.

Можешь реплики на локал каждому менеджеру сделать.
Нужен будет классификатор, по которому ты бужешь выгребать документы, или сделай права видимости по ролям или конкретному менеджерскому рыльцу.

Если менеджеры на локале будут править один и тот же док, то возникнут конфликты в центральной базе, вот с ними и повозишься.

Ну что тут еще советовать, нужно с задачей знакомиться и с методами решения, которые применял программист (может он на что-то жестко уповал и не все отрабатывать на локале будет)

 

[Domino6]

1.Разграничения по видимости длдя менджеров
2. Стандартная оптимизация (до 1 - 10 Mдок) нормально будет работать . При необходимости можно разгрузить данные клиента и взаимодействия

 

[Elena Nefedova]

Так вот что получается: динамика работы с клиентами бешенная, документов в базе накапливается туча, но ведь по идее каждому менеджеру нет необходимости знать(если только опционально) о работе других менеджеров... Может кто-то сталкивался с подобной проблемой?

1. Первое - это собственно оптимизация посредством выставления/снятия флажков на вкладке Advanced свойств базы.
2. Проблему разрастания базы можно решить стандартным архивированием.
НО если потребуется считать статистику - надо будет аккуратно все перепрограммировать с учетом поиска документов в архивах.
3. Дополнительно можно выиграть, если не использовать в агентах Document Selection - тут есть множество обходных путей, но идея в том, чтоб реже пользоваться полнотекстовым поиском (даже если база проиндексирована). Изжить db.Search как класс из кода разрастающейся базы, а вместо него использовать отбор по ключам из вьюх
4. Если есть агенты, работающие по расписанию, то их можно вынести в отдельную базу, содержащую только настроечные документы (принципиально, что настроек мало, и нет тенденции к разрастанию базы)
5. По возможности уменьшить частоту индексирования базы.
6. Уменьшить отбор документов для пользователей можно с помощью @SetViewInfo, либо используя встроенные виды с ограничением по категории

РЕЗЮМЕ: без программирования как следует оптимизировать не всегда удается.
Чем дальше в лес ...

 

[Constantin A Chervonenko]

3. ... Изжить db.Search как класс из кода разрастающейся базы, а вместо него использовать отбор по ключам из вьюх

А вот тут не соглашусь. Технологические View-хи в базе на 2000 000 документов - непозволительная роскошь. А db.Search c непустым вторым параметром замечательно работает; т.е. поиски в этом монстре (2000000) происходят за секунды. Спасает то, что в этом параметре стоит что-то вроде Now-TimeValue(1,0,0)

 

[Elena Nefedova]

А вот тут не соглашусь. Технологические View-хи в базе на 2000 000 документов - непозволительная роскошь. А db.Search c непустым вторым параметром замечательно работает; т.е. поиски в этом монстре (2000000) происходят за секунды. Спасает то, что в этом параметре стоит что-то вроде Now-TimeValue(1,0,0)

Ну правы, правы на все 100 - я некорректно сформулировала мысль!

Имелось в виду конечно же отсутствие ограничений в db.Search.
Также имелось в виду, что для "отбора по ключам из вьюх", где это возможно, используются существующие вьюхи, а не то, что под каждый единичный случай новые создаются

ЗЫ: у нас это касается в основном отбора настроек для обработки данных, а там ограничение по дате не прокатывает

 

[Duedev]

Попутно возникло несколько вопросов:
================================================
<!--QuoteBegin-Elena Nefedova+26:07:2006, 10:51 -->
<span class="vbquote">(Elena Nefedova @ 26:07:2006, 10:51 )</span><!--QuoteEBegin-->Проблему разрастания базы можно решить стандартным архивированием.

[snapback]41043" rel="nofollow" target="_blank[/snapback]​

[/quote]

Всмысле есть стандартная опция архивирования(что-то вроде того) или Вы про идеологические "стандарты" разгрузки базы?

================================================
================================================
<!--QuoteBegin-Elena Nefedova+26:07:2006, 10:51 -->
<span class="vbquote">(Elena Nefedova @ 26:07:2006, 10:51 )</span><!--QuoteEBegin-->Уменьшить отбор документов для пользователей можно с помощью @SetViewInfo

[snapback]41043" rel="nofollow" target="_blank[/snapback]​

[/quote]

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

<!--QuoteBegin-Elena Nefedova+26:07:2006, 10:51 -->
<span class="vbquote">(Elena Nefedova @ 26:07:2006, 10:51 )</span><!--QuoteEBegin-->либо используя встроенные виды с ограничением по категории

[snapback]41043" rel="nofollow" target="_blank[/snapback]​

[/quote]
Похоже это единственный выход, чтобы механизм фильтрации сводился к выбору конкретного, уже существующего представления, но тогда
<!--QuoteBegin-Elena Nefedova+26:07:2006, 10:51 -->
<span class="vbquote">(Elena Nefedova @ 26:07:2006, 10:51 )</span><!--QuoteEBegin-->По возможности уменьшить частоту индексирования базы.

[snapback]41043" rel="nofollow" target="_blank[/snapback]​

[/quote]
... делать не стоит, а наоброт оптимизировать частоту индексации с тем чтобы к минимумму свести издержки на перегрузку представлений.....

или я не прав?
:huh:

 

[Elena Nefedova]

Для Duedev

1. Да, есть стандартный метод db.archiveNow( collection, policy ) и относящиеся к нему свойства, не описанные в документации, но вовсю используемые в почтовых шаблонах еще со времен, когда я пешком под стол ходила

2. О сложной фильтрации уже много раз говорилось, в том числе и на этом форуме, и все сводится к тому, что надо заполнить форму, по данным которой с помощью FTSearch поместить документы в папку (заранее очищенную) и открыть эту папку для пользователя. От себя тут могу посоветовать запретить удалять документы из этой папки (иначе пользователи с правами на удаление вам так понаудаляют под предлогом очистки фильтра, что мало не покажется!!! Да что там пользователи - я сама раз удалила так штук 15 - хорошо, что старых - из архива потом восстановила )

3. Насчет индексирования - мы все-таки пришли к частоте раз в сутки, но у нас ежедневный прирост документов позволяет нормально работать в таких условиях. Тут сами только можете решить, какая частота вам подходит.

4. Встроенные виды с ограничением по категории имеют ряд подводных камней, самый неприятный из которых - это необходимость писать отдельный вид для каждого типа сортировки.

 

[Duedev]

<!--QuoteBegin-Elena Nefedova+28:07:2006, 10:28 -->
<span class="vbquote">(Elena Nefedova @ 28:07:2006, 10:28 )</span><!--QuoteEBegin-->О сложной фильтрации уже много раз говорилось

[snapback]41207" rel="nofollow" target="_blank[/snapback]​

[/quote]
да... с фильтрацией я разобрался, но как не крути все сводится к простмотру всех документов, а если этих документов порядка 5 000 000, то весьма проблематично...
Резюме:
Получается, для решения вопроса разгрузки базы и увеличения производительности работы менеджера, необходимо:
1. уменьшить количество документов физически(это, например, за счет архивирования и переноса их в другие базы)

2. Уменьшить количество документов логически(в представлениях), оптимизировать пораметры выбора и параметры фильтрации
3. Оптимизировать базу стандартными способами(настройки базы, индиксерование и т.д)

А еще идеи есть???
ps: локально базу использовать не удастся( много переписывать придется)

 

[Duedev]

<!--QuoteBegin-Elena Nefedova+28:07:2006, 10:28 -->
<span class="vbquote">(Elena Nefedova @ 28:07:2006, 10:28 )</span><!--QuoteEBegin-->db.archiveNow( collection, policy ) и относящиеся к нему свойства

[snapback]41207" rel="nofollow" target="_blank[/snapback]​

[/quote]

Хотел попросить, если есть возможность, чуть подробнее описать метод...

 

[Elena Nefedova]

Я, честно говоря, подробностей не знаю. Сама я использовала как пример агенты из шаблона почтового ящика.
Есть метод db.archiveNow(collection, policy) и св-во db.ArchiveDestinations, которое определяет все множество архивов данной базы.
Policy определяет конкретный архив, куда должны быть помещены документы из collection.

Все остальное надо уже программировать.
Например, если нужно запретить архивирование настроек. Или для каждого документа архивировать все логически с ним связанные. Можно будет сформировать собственную коллекцию.

 

[Duedev]

огромное спасибо всем!!!