• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Собрать отчет из многих баз

  • Автор темы anna
  • Дата начала
A

anna

Многоуважаемый all! У меня есть некий план, но хочется услышать и другие мнения - каков наилучший способ (наибыстрейший и с минимальными серверными нагрузками) собрать инфу(снять отчет) о статусе документов разом из ~50 баз?
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
Что есть "о статусе"? Если по кол-ву доков, всю работу поручить индексёру - понаделать лукапных вьюх, но эт смотря какое разнообразие доков.
Тогда ващще онлайн выйдет.
 

Kizarek86

Green Team
20.07.2007
871
7
BIT
28
Если баз и документов много а результат нужен быстро то гоните данные в реляционки.
У нас для таких целей используется LEI и DB2
 
A

anna

Если баз и документов много а результат нужен быстро то гоните данные в реляционки.
У нас для таких целей используется LEI и DB2
чтобы гнать в реляционки тоже используются ресурсы доминошного сервера?
дб2 не бесплатен. да и под него еще целый огород городить придется.
 

garrick

Lotus Team
26.10.2009
1 342
150
BIT
128
DB2 бывает бесплатная версия, но она, по-моему, с Domino не дружит, а вот LEI точно не задаром? Без какого-либо генератора отчётов наверное не обойтись, а все генераторы отчётов работают только с реляционными СУБД. У Интертраста был какой-то самодельный для Lotus Notes, но кажется он был заточен специально только под CompanyMedia. Если совсем по-простому Java+Notes API+Apache POI = вывод в Excel. В базах на этот случай надо построить специальные вьюхи для ускорения отбора документов для отчёта, а если ещё и с правильными столбцами, то можно пройтись по ViewEntryCollection.
 
Последнее редактирование модератором:

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
2
чтобы гнать в реляционки тоже используются ресурсы доминошного сервера?
дб2 не бесплатен. да и под него еще целый огород городить придется.
можно использовать постгрес через JDBC. и без всяких lei.

ps.. хочу поиграться с jsonb на мульенах записей...
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
Гнать инфу в реляционку, это по сути готовить в ней отчёт(ы) для быстрого к нему(к ним) доступа. А сам отчёт будет актуальным с периодичностью загрузки данных (если она массовая). Т.е. и близко никакого реалтайма (а об этом вроде @anna упоминала). Нотусёвые вьюшки - те же отчёты (кусочки, в общем случае) с хорошей актуальностью (и автоматом - индексёр).
Какие проблемы собрать простую (если я правильно понял) инфу с вьюшек 50 баз на лету???
Разговор, канеш, о простом не развёрнутом отчёте (ну типа статистики)
 
A

anna

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

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
2
Гнать инфу в реляционку, это по сути готовить в ней отчёт(ы) для быстрого к нему(к ним) доступа. А сам отчёт будет актуальным с периодичностью загрузки данных (если она массовая). Т.е. и близко никакого реалтайма (а об этом вроде @anna упоминала). Нотусёвые вьюшки - те же отчёты (кусочки, в общем случае) с хорошей актуальностью (и автоматом - индексёр).
Какие проблемы собрать простую (если я правильно понял) инфу с вьюшек 50 баз на лету???
Разговор, канеш, о простом не развёрнутом отчёте (ну типа статистики)
Все это здорово, пока набор отчетной инфы относительно статичен и\или кол-во доков относительно не большие.
На счет реалтам\не реалтйм. если нужен реалтам то при doc.save данные пихаются в сиквел тут же - замер показал 5-15 ms на upsert операции.
если есть запас по времени от 5 мин - то шедульный агент с db.search и отсечкой по времени вполне так порционно гонит инфу куда надо.
 
A

anna

Все это здорово, пока набор отчетной инфы относительно статичен и\или кол-во доков относительно не большие.
На счет реалтам\не реалтйм. если нужен реалтам то при doc.save данные пихаются в сиквел тут же - замер показал 5-15 ms на upsert операции.
если есть запас по времени от 5 мин - то шедульный агент с db.search и отсечкой по времени вполне так порционно гонит инфу куда надо.
Я думала, что сейчас будет флейм про то, что нужно на сервере sql дергать лотусовые данные, типа, хочешь отчетов - сам себе и надергай :) В общем, если юзать R, то примерно так и можно работать с данными, но в данном конкретном случае интересует не бигдата же, а банально статусы документов в документообороте
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 927
608
BIT
150
Если совсем по-простому Java+Notes API+Apache POI
выкладывал здесь шаблон, еще и настраивается (что выгружать из каких вью) + может связанную инфу тянуть
понятно - не будет быстро (если по сетке)
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 927
608
BIT
150
оптимизации по выгрузке отчетов - только список измененных юнидов получать
первая выгрузка - полный срез - будет задержка
 
A

anna

деткам на заметку: если в виде используется @Now - время работы увеличивается от 20 секунд до 6 минут и все замедляяяяяетсяааа
 
A

anna

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

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