• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

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

    На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.

    Запись на курс до 25 апреля. Получить промодоступ ...

Большое Количество Документов В Папке

  • Автор темы DNT
  • Дата начала
D

DNT

Есть такая задача - создать механизм который бы давал пользователям возможность удобно работать с входящей почтой общей маил-иновской БД, кол-во входящих писем в день будет ООчень большим, порядка 10000 в день. Должен быстро, без тормозов работать поиск по инбоксу, причем одновременно в базе читают почту несколько десятков операторов, каждый может запускать поиск, под каждого нужно помнить прочитано им письмо или нет.
Можно было-бы заставить пользователей перемещать сразу руками из инбокса обработанные письма в другую папку, например "Обработанные", оставляя в Инбоксе только новые документы, тем самым облегчить папку, но по условию ТЗ в папке инбокс должны находиться письма за последний месяц от текущей даты, более давние будут агентом перемещаться каждый день в архив, т.е. по расчетам в папке должно быть около 300 тыс. документов постоянно. Причем письма очень разные, есть и 20 кБ, а есть и с вложениями по 20, 50 Мб...

1. Справится ли Лотус с такими объемами? Напомню: в Инбоксе около 300 000 документов, вообще в базе, например за год будет около 3 600 000 с аттачментами , по ним тоже нужен "не тормозящий" поиск.
2. Как мне оптимизировать реализацию такой задачи? Интересует ваш опыт работы с такими объемами и направление меня в нужное русло
поисков решения.

п.с. сейчас такая задача крутится на МС Аутлуке, и он в полном "Ауте" при работе с такими объемами )))
Тормозит, вешается, как-то пыхтит - пользователь негодуе ), решили попробовать Лотус.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 940
609
BIT
210
по аттачам, нетормозящий поиск...
а чё, аутлюк ищет по аттачам (зип, ПДФ...)?
с аттачами будет засада (МСО индексуются тока до опред объёма, и КМК - виндовзонли)
если коротко - в таком виде я бы не стал решать задачу на домине

что мешает прикрутить интеграцию с к-л другими ср-вами работы и индексации больших объёмов?

для поиска по аттачам - можно конвертить всё в текст и его индексировать
и у домины есть ограничение на размер ФТ индекса
 
A

akat

ИМХО, лучшим ответом будет сэмулировать задачу. Хотябы отчасти. И посмотреть. Учитывая то железо, которое будет использоваться.
 
D

DNT

2 lmike

нет, все немного проще, поиск по аттачам не нужен, нужен поиск по сабжекту, отправителю и т.д. , т.е. по данным которые отображены в представлении. Я упомянул про вложения только чтобы акцентировать внимание на большой объем БД.

что мешает прикрутить интеграцию с к-л другими ср-вами работы и индексации больших объёмов?

например?

2 AlexeyKatyushyn

ИМХО, лучшим ответом будет сэмулировать задачу. Хотябы отчасти. И посмотреть. Учитывая то железо, которое будет использоваться.

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

2 All

C Аутлука можно перегнать данные в Лотус, чтоб с аттачами и не битыми датами?
 
A

Akupaka

А вариант перемещать данные в какую-то реляционку не рассматривается? Правда, я не специализируюсь на них, не уверен в возможностях полнотекстового индекса... Но с огромными кол-вами записей реляционка работает лучше нотеса.
Хотя 1-3 млн документов в нереплицируемом приложении для нотес не особо проблемно, особенно, если представления не сложные, но необходимо проверить отдельно под нагрузкой несколькими пользователями, возможно стоит ознакомится с кластеризацией домино-серверов.
Желательно документы перемещать в архив оперативно, но есть сообщения, что наличие в БД большого кол-ва огрызков документов (стабы, окурки) влияет на производительность приложения в целом. Т.е. хорошо бы проработать механизм удаления огрызков после архивирования документов. Либо организовать периодическую ротацию БД.
Кроме того, вложения хорошо бы хранить отдельно от документов (тут либо выкладывать на диск агентами, либо включать стандартные механизмы 8-ки - DAOS )
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
фт поиск
при выходе из дока спрашивать переносить ли в обработанные

непонятно только почему в почте 300К актуальных писем
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
4
Что-то мне кажется требования не вписываются в Limits of Lotus Notes. Хотя бы по размеру базы.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Что-то мне кажется требования не вписываются в Limits of Lotus Notes. Хотя бы по размеру базы.

и в чем ограничени?
 
A

Akupaka

Код:
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.designer.domino.main.doc/H_NOTES_AND_DOMINO_KNOWN_LIMITS.html
 
D

DNT

Спасибо за реакцию, разбираюсь пока.
Аттачменты однозначно буду хранить отдельно!
А может как-то DB2 задействовать для хранения инфы? Только никогда с этим не работал... что почитать?
Не будет ли тормозов ещё больших?
 
A

Akupaka

Ну, есть стандартные средства переноса данных из домино в реляционку: DECS, LEI (этот кажись платный).
Еще можно написать свои с помощью объектов соответствующих классов.
В справке разработчика есть раздел "Lotus Connectors", в нем есть что глянуть.
Тормоза можно куда угодно прикрутить, а вот нужны ли костыли в виде переноса из нотес в реляционку - вопрос.
Если рассматривать эти данные как аналитические, то выгружать в реляционку очень желательно, а, если только для краткосрочной обработки и для истории, то достаточно будет в нотес-архивы скидывать неактуальные данные. Имхо.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 940
609
BIT
210
если только для краткосрочной обработки и для истории
и если нужен ФТ поиск (в т.ч. по аттачам) - нотус слабоват, вона обсуждали вынос индексов на др. диски (для домины), тоды уж луча ваще в др. систему :KillMe:
 
A

Akupaka

lmike ,
ну не знаю, не замечал особо слабостей, но и поиском особенным образом не пользовался, только повседневные задачи, домино справлялся. Хотя сравнением производительности не занимался, может и плох =)
 

Мыш

Lotus Team
12.02.2008
1 219
29
BIT
66
lmike ,
ну не знаю, не замечал особо слабостей
Пруфы не могу предоставить, ибо плотно не работал с FT. "Мое сугубое ИМХО" - глюкавость с полнотекстовым поиском наблюдалась во всех версиях Домино, с какими приходилось работать. С аттачами - особенно. Опять-таки, с чужих слов, без пруфов - коллеги для поиска в аттачах пользуются Архивариусом, говорят, неплохая прога. Возможно, экспорт в DXL + сторонняя прога и есть самое правильное решение...
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 940
609
BIT
210
ну просто, чтобы знать - чего хотеть от поиска -
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!