Миллионы документв в бд lotus

[Lariel]

Здравствуйте.

Если железо не особо мощное, в базе Lotus уживутся к примеру 5 миллион документов ? Если сделать несколько только нужных представлений например по 100,000 документов. Вариант может быть рабочий ? Обработки особой не требуется только просмотр списков (в представлениях) и только добавление новых документов. Или даже браться не стоит - идея гиблая ?

Подскажите, кто сталкивался с каким максимальным количеством документов в БД Lotus. Чтобы это были рабочие базы. В интернете встречал информацию, что можно хранить несколько миллионов документов в одной БД вопрос только грамотного проектирования, а хотя реально ссудя по отзывам проблемы с поддержкой объемистых БД начинают уже при 500,000 документах.

 

[ToxaRat]

и только добавление новых документов

только грамотного проектирования

так это и есть грамотное проектирование - только добавлять

можно конечно

 

[garrick]

Есть опыт использования справочника с количеством записей (документов) гораздо более 5 млн. Записи добавляются загрузкой из разных файлов, примерно раз в неделю, тогда же принудительно производится построение индексов (долго...). Автоматическое перестроение индексов отключено. Всё летает, как ракета, никаких тормозов. Никто из пользователей не жалуется. Есть гораздо более проблемные базы с меньшим количеством документов.

 

[rinsk]

Бяда у домино не с размерами данных, а с его дурацкими индексами (АКА views), что в случае @garrick позволяет в общем то сносно существовать. Если динамика - то нужно быть готовым что куда то пропадают или не появляются доки без - объяснения причин...
Поглядим что готовят нам в 902... Хотя надежны мало...
upd - web приклад с 3,5 млн доков пришлось кромсать и дружить с постгресом.

 

[Constantin A Chervonenko]

Минимизировать число вьюшек, сортировка/категоризация по одной колонке, НЕ использовать иерархические (с респонсами) вовсе, никаких аттачей - 3+ миллиона летали под 7-кой (железо серверов было приличное, но не выдающееся)

 

[Baneslaer]

Я бы посмотрел в другую сторону. Если документов так много, то большая их часть не используется или в статусах наподобии "исполнено"/ "архив" и т.п.
Я бы дописал функционал, которых архивировал бы документы в "закрытых" статусах через определеный срок(допустим, через 30 дней) в архивную базу. Архивную базу можно сделать из шаблона основной, предварительно отключив в ней агенты и оставив несколько нужных представлений.
В итоге вы бы имели архив + быстро работающую основную базу, которая не была бы перегружена отработанными документами.

 

[Lariel]

Спасибо. В целом так и есть. Но после дальнейшего анализа задачи решили реализовывать все-таки на реляционной СУБД

 

[lmike]

реляционной СУБД

стесняюсь спросить - что за процесс вы туда запихнуть хотите?

 

[VladSh]

Я бы дописал функционал, которых архивировал бы документы в "закрытых" статусах через определеный срок(допустим, через 30 дней) в архивную базу.

Лучше саму базу периодически (у кого раз в год, у кого реже, а у кого чаще) отправлять архив, а рабочую создавать с нуля, копируя все настройки и справочники. Какое-то время (месяц-полтора) люди будут искать старые документы в архивной базе, но потом эти обращения сойдут на нет.
Такое решение избавляет от удаления/изменения документов, а соответственно и от дополнительной (дурной) работы над базами индексера. Также все документы в архивных базах будут доступны в т.ч. и по лотус-линкам.