GoldenLine
Zaloguj się
Marek Kuchciak

Marek Kuchciak Wroslauer, IBM
Collaboration
Solutions, Social
Business

Temat: Bardzo duże repozytorium dokumentów

Może ktoś zechciałby się podzielić swoim praktycznym doświadczeniem z tworzenia i eksploatacji aplikacji o charakterze repozytorium lub biblioteki dokumentów o bardzo dużych rozmiarach (łączny rozmiar załączników rzędu kilkuset GB)? Zależy mi na opiniach i komentarzach dotyczących rzeczywistych systemów.

Jak wiadomo nie da się zrobić tak wielkiego repozytorium w postaci pojedynczej bazy danych - pomijając problemy wydajnościowe w obrębie Domino to pewnie i system operacyjny nie bardzo by sobie radził z tak wielkim plikiem. Dawniej trzeba było jakoś sztucznie dzielić aplikację na szereg baz, np. przesuwając do nich załączniki. Od wersji Domino 8.5 można wykorzystać funkcjonalność DAOS, dzięki czemu wszystkie załączniki powyżej określonego rozmiaru lądują od razu poza bazą Notes.

Tyle teorii. Czy ktoś z Was testował może albo produkcyjnie wdrożył takie rozwiązanie? Jakie wrażenia? Ciekawe byłoby porównanie wydajności i komfortu wykorzystania tego samego repozytorium przed i po objęciu go DAOS.

Marek Kuchciak
Link do wypowiedziLink
Andrzej Zieliński

Andrzej Zieliński Administrator
Systemów
Informatycznych, Sp.
z.o.o

Temat: Bardzo duże repozytorium dokumentów

Dlaczego system operacyjny miałby sobie nie poradzić z tak "małym" plikiem ? Z tej strony nie widzę problemów.
Jednak obsłużenie takiej ilości danych od strony Lotusa to już jest coś.
Link do wypowiedziLink
Grzegorz P.

Grzegorz P. Programista .NET
ASP.NET Silverlight
MCP, MCTS

Temat: Bardzo duże repozytorium dokumentów

Witam!

Też interesuje mnie ten temat. Limit wielkości bazy nsf jest na poziomie 64 GB.

DAOS u mnie odpadł, bo mam replikację pomiędzy stacjami a serwerem głównym, dodatkowo jest kilka serwerów replikujących. Czy nadal jest aktualnie, że archiwum DAOS się nie replikuje?

Znam rozwiązania autorskie polskiej dobrej firmy - wdrożone i sprawdzone w dużej firmie. Jeśli to Pana interesuje, to przekaże namiary, proszę o kontakt na: grzegorz.pawluch@ekowodrol.com.pl.

Pozdrawiam
GP
Link do wypowiedziLink
Marek Kuchciak

Marek Kuchciak Wroslauer, IBM
Collaboration
Solutions, Social
Business

Temat: Bardzo duże repozytorium dokumentów

Andrzej Zieliński:
Dlaczego system operacyjny miałby sobie nie poradzić z tak "małym" plikiem ? Z tej strony nie widzę problemów.

OK, sam rozmiar pliku nie jest problemem we współczesnych systemach plików. W przypadku Domino ustalono limit 64 GB. Serwer Domino nie rezerwuje z góry obszaru na plik .nsf (tak jak to robi np. dla plików logów transakcyjnych), a ten przy intensywnej wymianie dokumentów (dużo nowych i usuwanych) może ulec sporej fragmentacji, aczkolwiek załóżmy że to nie wpłynie istotnie na wydajność.

IBM Support: File system limits the size of database below the certified maximum size of 64 GB
http://www-01.ibm.com/support/docview.wss?rs=463&uid=s...

Marek Kuchciak
Link do wypowiedziLink
Marek Kuchciak

Marek Kuchciak Wroslauer, IBM
Collaboration
Solutions, Social
Business

Temat: Bardzo duże repozytorium dokumentów

Grzegorz Pawluch:
Czy nadal jest aktualnie, że archiwum DAOS się nie replikuje?

DAOS działa tylko na serwerze (m.in. dlatego, że do jego funkcjonowania musi być włączone logowanie transakcyjne). To jest "niskopoziomowy" mechanizm, tzn. API Notes/Domino nie wie, czy baza jest podłączona do DAOS czy nie. Jeśli zechcemy założyć lokalną replikę takiej bazy, to oczywiście da się, ale
Znam rozwiązania autorskie polskiej dobrej firmy - wdrożone i sprawdzone w dużej firmie.

Nie szukam takiego rozwiązania. Interesuje mnie za to, czy np. ktoś włączył DAOS na serwerze (bez wymiany produkcyjnej aplikacji) i porównał wydajność. A w ogóle jeśli rozwiązanie dobre i sprawdzone, to czemu nie zarekomendować go tutaj?

Marek Kuchciak
Link do wypowiedziLink
Marek Kuchciak

Marek Kuchciak Wroslauer, IBM
Collaboration
Solutions, Social
Business

Temat: Bardzo duże repozytorium dokumentów

Jeszcze jeden komentarz do problemu dużych rozmiarów plików z bazami NSF: fragmentacja plików i ich defragmentacja, szczególnie na NTFS, biorąc pod uwagę, że powierzchnia dyskowa pod bazy Notes nie jest prealokowana.

Ciekawy wpis na ten temat:
wissel.net: Domino and Disk Fragmentation
http://www.wissel.net/blog/d6plinks/SHWL-7ZM353

Przy wykorzystaniu DAOS problem ten będzie mniej dotkliwy.

Marek Kuchciak
Link do wypowiedziLink
Artur K.

Artur K. DR NOTES

Temat: Bardzo duże repozytorium dokumentów

Na początek zaznaczę, że doświadczenia wdrożeniowego z tak dużymi repozytoriami nie mam, ale do tematu podchodziłem kilkukrotnie. Jakiś czas temu robiłem analizę pod kątem takiego wdrożenia ale ostatecznie klient zdaje się wybrał inne rozwiązanie (nie bazujące na Domino). Opinia, że Domino nie nadaje się do dużych baz danych ciągle pokutuje .. moim zdaniem niesłusznie.

Osobiście nie bałbym się wykorzystać Domino jako duże repozytorium dokumentów. Problemem nie jest wielkość bazy danych - można opracować odpowiednią architekturę systemu, która ten problem rozwiąże. Aplikacja Lotus Notes będzie działała bardzo szybko nawet w przypadku dużych baz (powyżej kilkudziesięciu GB) o ile nie występują pola Readers a widoki mają prostą strukturę i nie ma ich dużo.

Zwróćmy uwagę, że w repozytoriach dokumentów najczęstszymi operacjami jest odczyt dokumentów oraz tworzenie nowych. Rzadko natomiast zmienia się zawartość istniejących dokumentów. To okoliczność sprzyjająca. Problemem, na który trzeba przede wszystkim zwrócić uwagę jest liczba dokumentów.

Oczywiście nie ma to jak doświadczenia praktyczne - nie wszystko można przewidzieć na 100% - chociażby, wspomniana kwestia defragmentacji baz NSF. Czytałem opis tego zagadnienia i podobno nawet "przekompaktowanie" bazy nie pomaga, bo ponownie zaalokowany może zostać zdefragmentowany fragment dysku. Trudno powiedzieć, jak to jest w praktyce. Można próbować na aplikację przeznaczyć osobną partycję dysku ... (wtedy system operacyjny nie ma specjalnie wyboru przy alokacji :). Albo się tym nie przejmować - repozytoria nie mają zwykle dynamicznego charakteru jak już pisałem ..więc może nie będą się bardzo defragmentować ..

Co do DAOS, raczej nie stosowałbym go w tym przypadku. Wiem, że od razu narzuca się jego zastosowanie z powodów odciążenia NSF-ów ale DAOS-em jest ciężko zarządzać i wykonywać backupy. Nie wykorzystamy też głównej cechy DAOS-a czyli przechowywania wielu kopii załącznika w jednym pliku (no, chyba że charakter repozytorium jest taki, że załączniki się powtarzają).

W swoim czasie wdrożyliśmy aplikację w takiej architekturze, że załączniki są przechowywane w innym NSF-ie i automatycznie otwierane, gdy otwierany jest macierzysty dokument (użytkownik nie zauważa, że pochodzą z innej bazy). Zamierzeniem było właśnie stworzenie systemu jako dużego repozytorium dokumentów. Klient zamierzał skanować duże ilości dokumentów. Po wdrożeniu klient się rozmyślił co do skanowania dokumentów i mimo, że aplikacja działa od wielu lat to bez zawartości skanów jej rozmiar nie jest imponujący.

Reasumując, nie odchodziłbym od przechowywania całego repozytorium w NSF-ach (bez DAOS). Przewaga związana z zarządzalnością i elastycznością jest niewątpliwa - poza tym, sposób ten daje możliwość implementacji funkcjonalności, którą inaczej ciężko byłoby zaimplementować w Lotus Notes - prawo czytania dokumentu z wyłączeniem pól Rich Text i załączników.
Link do wypowiedziLink
Marek Kuchciak

Marek Kuchciak Wroslauer, IBM
Collaboration
Solutions, Social
Business

Temat: Bardzo duże repozytorium dokumentów

Artur Korol:
Co do DAOS, raczej nie stosowałbym go w tym przypadku. Wiem, że od razu narzuca się jego zastosowanie z powodów odciążenia NSF-ów ale DAOS-em jest ciężko zarządzać i wykonywać backupy. Nie wykorzystamy też głównej cechy DAOS-a czyli przechowywania wielu kopii załącznika w jednym pliku (no, chyba że charakter repozytorium jest taki, że załączniki się powtarzają).

Owszem, przy zastosowaniu DAOS nieco komplikuje się strategia wykonywania i odtwarzania kopii zapasowych: bazy NSF agentem dedykowanym dla Domino zaś pliki w repozytorium DAOS agentem plikowym, po odtworzeniu bazy NSF trzeba sprawdzić, czy w DAOS są wszystkie niezbędne załączniki i ewentualnie je dociągnąć, ale to się da zautomatyzować poprzez skrypty. W zamian za to DAOS nie tylko obniża nam zużycie powierzchni dyskowej i poprawia wydajność operacji I/O (mniej zapisów na dysk), ale i zmniejsza wolumen danych w regularnie wykonywanych kopiach zapasowych, ponieważ bazy NSF są znacznie mniejsze, załączniki zdeduplikowane a obiekty w repozytorium są niezmienne, więc wystarczy zapisać ich kopię zapasową tylko raz (gdyby były w bazie NSF, to jakakolwiek zmiana danych w tej bazie skutkowałaby potrzebą wykonania jej kopii zapasowej).

Nawet jeśli mamy po jednym egzemplarzu każdego załącznika, to i tak DAOS daje nam korzyści, np. bez problemu logiczny rozmiar naszej bazy NSF z załącznikami może znacznie przekroczyć limit 64 GB.
Reasumując, nie odchodziłbym od przechowywania całego repozytorium w NSF-ach (bez DAOS). Przewaga związana z zarządzalnością i elastycznością jest niewątpliwa - poza tym, sposób ten daje możliwość implementacji funkcjonalności, którą inaczej ciężko byłoby zaimplementować w Lotus Notes - prawo czytania dokumentu z wyłączeniem pól Rich Text i załączników.

Nie zgadzam się z tym ostatnim stwierdzeniem. DAOS to mechanizm niskopoziomowy, przeźroczysty dla nawet dla API. Funkcja API odczytująca dokument z bazy nawet "nie wie", czy załącznik jest wewnątrz NSF czy w repozytorium DAOS.

Dzięki za rzeczowy głos w dyskusji.

Marek Kuchciak
Link do wypowiedziLink
Zbigniew Nowak

Zbigniew Nowak specjalista

Temat: Bardzo duże repozytorium dokumentów

Marek Kuchciak:
kopiach zapasowych, ponieważ bazy NSF są znacznie mniejsze, załączniki zdeduplikowane a obiekty w repozytorium są niezmienne, więc wystarczy zapisać ich kopię zapasową tylko raz (gdyby były w bazie NSF, to jakakolwiek zmiana danych w tej bazie skutkowałaby potrzebą wykonania jej kopii zapasowej).

Jak robi backup klient TSM dla Domino?
Link do wypowiedziLink
Marek Kuchciak

Marek Kuchciak Wroslauer, IBM
Collaboration
Solutions, Social
Business

Temat: Bardzo duże repozytorium dokumentów

Zbigniew Nowak:

Jak robi backup klient TSM dla Domino?

W skrócie:
- zapisuje kopie zapasowe baz NSF z wykorzystaniem API, czyli sprawdza czy rzeczywiście w bazie były jakieś modyfikacje danych (sam plik jest modyfikowany także przez operacje typu indeksowanie itd.) - to wystarczy robić np. raz na dobę
- zapisuje kopie zapasowe logów transakcyjnych, najlepiej przestawionych w tryb Archived - to najlepiej robić raz na 1-2 godziny
- dezaktywuje i usuwa te pliku logów transakcyjnych, które nie są już potrzebne
- jest w stanie odtwarzać bazy NSF w trybie "point in time", tzn. dla wskazanego czasu odtwarza ostatnią poprzednią pełną kopię bazy NSF po czym dodaje do niej stosowne transakcje z logu

Obsługa agenta jest możliwa zarówno z linii komend (dzięki czemu łatwo wszystko oskryptować) jak i z GUI.

Miałem do czynienia także z analogicznym oprogramowaniem z rodziny HP DataProtector i EMC Legato NetWorker, ale oba nie dawały takich możliwości i elastyczności przy wykonywaniu operacji backup/restore danych z serwerów Domino.

Marek Kuchciak
Link do wypowiedziLink
Zbigniew Nowak

Zbigniew Nowak specjalista

Temat: Bardzo duże repozytorium dokumentów

Marek, źle napisałem - chodziło mi o TSM i DAOS (bo normalnie to wiem jak działa ;). Moim zdaniem klient on-line bierze całe bazy nsf, ponieważ z poziomu Domino (API) nie widać mechanizmu DAOS. No chyba, że jako produkt tego samego producenta TSM jest mądrzejszy.

A pytanie jest wynikiem Twojego opisu tworzenia kopi zapasowych. Gdyby robić "zimny" backup to faktycznie oszczędzamy miejsce ale przy kliencie on-line nie widzę za dużo korzyści (jeśli chodzi o miejsce na backupie)?
Link do wypowiedziLink
Marek Kuchciak

Marek Kuchciak Wroslauer, IBM
Collaboration
Solutions, Social
Business

Temat: Bardzo duże repozytorium dokumentów

Zbigniew Nowak:
Marek, źle napisałem - chodziło mi o TSM i DAOS (bo normalnie to wiem jak działa ;). Moim zdaniem klient on-line bierze całe bazy nsf, ponieważ z poziomu Domino (API) nie widać mechanizmu DAOS. No chyba, że jako produkt tego samego producenta TSM jest mądrzejszy.

Hmm, nie jestem specjalistą od oprogramowania TSM, ale z tego co pamiętam, to TSM for Domino sprawdza poprzez API czy baza została zmodyfikowana, ale obiekt jest składowany jako plik. Dlatego przy włączeniu DAOS składowane bazy NSF będą znacznie mniejsze (wg ich fizycznych rozmiarów), zaś repozytorium DAOS trzeba składować osobno zwykłym agentem plikowym.

Lotus Notes and Domino wiki: DAOS Backup and Restore
http://www-10.lotus.com/ldd/dominowiki.nsf/dx/daos-bac...

Marek Kuchciak
Link do wypowiedziLink
Artur K.

Artur K. DR NOTES

Temat: Bardzo duże repozytorium dokumentów

Nie zgadzam się z tym ostatnim stwierdzeniem. DAOS to mechanizm niskopoziomowy, przeźroczysty dla nawet dla API. Funkcja API odczytująca dokument z bazy nawet "nie wie", czy załącznik jest wewnątrz NSF czy w repozytorium DAOS.

Marek Kuchciak

Żeby była pełna jasność - nie stosowałbym (raczej)DAOS w tego rodzaju aplikacji (archiwum kilkaset GB). Nie chciałem przez to powiedzieć, że jestem przeciwnikiem stosowania DAOS w innych przypadkach, bo to bardzo ciekawa technologia.

Ale uważam, że w tym przypadku DAOS nam raczej nic da. Zużycia powierzchni dyskowej nie obniży- przy założeniu, że załączniki się nie duplikują. Co do wydajności operacji I/O - to ryzykowne stwierdzenie, że poprawia. Trzeba by dokładnie przeanalizować, co się dzieje przy odczycie i zapisie załącznika w obu przypadkach. Ważne jest też, na ile wydajnie poszczególne operacje zostały zaimplementowane przez programistów IBM (a to trudno ocenić).

Jakiś czas temu rozmawiałem z administratorem dużego serwera Domino (skrzynki pocztowe zajmowały kilka TB), który twierdził że wydajność Domino spadła po wdrożeniu DAOS. Trudno powiedzieć dlaczego. Stawiałbym na to, że wąskim gardłem może być w tym przypadku procesor raczej niż operacje I/O. Przypuszczam, że jest trochę "liczenia" przy operacjach związanych z DAOS.

Oczywiście charakterystyka implementacji DAOS na skrzynkach pocztowych i w omawianym przez nas systemie to dwie zupełnie różne bajki.
Archiwum wielkości kilkuset GB wcale nie musi być mocno obciążone. Tego nie zakładaliśmy (no, chyba że wpuścimy na nie kilkuset użytkowników). W mało obciążonym systemie, wydajność operacji I/O może nie mieć znaczenia. Nawet jeśli operacja odczytania załącznika z DAOS będzie trochę szybsza (mierząc czas operacji I/O) z tego samego dokumentu lub dokumentu umieszczonym w innym NSF-ie, to będzie miało to pomijalne znaczenie. Odczyt z innego NSF-a można robić jedną funkcją "GetDocumentByUNID", która działa bardzo szybko ..

A zarządzać DAOS z kilkuset GB ..policzmy. Zakładając, że średni plik to 10MB, to mamy 30,000 plików ..no niby software do backupów to załatwi przyrostowo, tym niemniej jednak nie wygląda to zachęcająco. Jeśli średni rozmiar pliku jest mniejszy, plików będzie więcej.

W przypadku osobnych NSF-ów, możemy to jakoś sami zorganizować, np. dzieląc archiwa chronologicznie, tak że starsze NSF-y się nie zmieniają. No, chyba że taka organizacja jest niemożliwa ..:) ..wówczas odpada jeden argument "za rozwiązaniem z osobnymi NSF-ami.

Na DAOS należy uważać, jeśli w archiwum naszym miałoby być dużo małych plików. Jak wiadomo, konfigurując DAOS określa się minimalną wielkość załącznika przechowywaną w DAOS i zalecane jest ok 64kB. Przypuszczalnie powodem wprowadzenia takiej rekomendacji jest narzut związany z umieszczaniem pliku w DAOS. Przypuszczalnie także dążenie do ograniczenia liczby plików w DAOS. Nie wiem czy są jakiekolwiek opracowania jak się DAOS zachowuje, jeśli zawiera dużą liczbę plików (kilkaset tysięcy lub więcej). Poza tym DAOS nie załatwi nam pól Rich Text, wklejonych obrazków, OLE itd.

Reasumując, podtrzymuję zdanie, że DAOS w tym przypadku raczej nie ..ale ..trzeba by rozpatrzeć charakter danej aplikacji, bo wszystko zależy ...:))

Artur KorolArtur Korol edytował(a) ten post dnia 22.02.10 o godzinie 23:49
Link do wypowiedziLink
Marek Kuchciak

Marek Kuchciak Wroslauer, IBM
Collaboration
Solutions, Social
Business

Temat: Bardzo duże repozytorium dokumentów

Artur Korol:
Ale uważam, że w tym przypadku DAOS nam raczej nic da. Zużycia powierzchni dyskowej nie obniży- przy założeniu, że załączniki się nie duplikują. Co do wydajności operacji I/O - to ryzykowne stwierdzenie, że poprawia. Trzeba by dokładnie przeanalizować, co się dzieje przy odczycie i zapisie załącznika w obu przypadkach. Ważne jest też, na ile wydajnie poszczególne operacje zostały zaimplementowane przez programistów IBM (a to trudno ocenić).

Owszem, jeżeli załączniki się nie duplikują, to nie zmniejszymy dzięki DAOS zużycia powierzchni dyskowej. Jeśli ustawimy minimalny rozmiar załącznika przerzucanego do repozytorium DAOS na mniej niż wielkość jednostki alokacji dysku to możemy nawet osiągnąć efekt przeciwny, tj. wzrost zużycia powierzchni dyskowej. Standardowo ten limit to 4 KB, co odpowiada domyślnej wielkości jednostki alokacji w systemi plików NTFS.

Co do wydajności I/O, to w takim przypadku rzeczywiście trzeba byłoby przeprowadzić testy, chociaż wyraźna poprawa na pewno będzie widoczna dopiero przy operacjach na duplikujących się załącznikach, a szczególnie przy ich zapisie.

Natomiast nawet bez duplikacji załączników osiągniemy dzięki DAOS wymierną korzyść w postaci zmniejszenia rozmiarów dziennej kopii zapasowej danych, gdyż normalnie zmiana nawet jednego dokumentu w bazie NSF skutkuje koniecznością wykonania kopii całej bazy, zaś przy DAOS załączniki logicznie przypisane do tej bazy nie muszą być codziennie składowane na zewnętrzne nośniki. Oczywiście ceną za to jest nieco bardziej skomplikowany proces wykonywania i odtwarzania kopii zapasowych.
Jakiś czas temu rozmawiałem z administratorem dużego serwera Domino (skrzynki pocztowe zajmowały kilka TB), który twierdził że wydajność Domino spadła po wdrożeniu DAOS. Trudno powiedzieć dlaczego. Stawiałbym na to, że wąskim gardłem może być w tym przypadku procesor raczej niż operacje I/O. Przypuszczam, że jest trochę "liczenia" przy operacjach związanych z DAOS.

Przypadek wymagający analizy, wydajność teoretycznie nie powinna spaść, może przy okazji włączono jakieś dodatkowe mechanizmy.
Na DAOS należy uważać, jeśli w archiwum naszym miałoby być dużo małych plików. Jak wiadomo, konfigurując DAOS określa się minimalną wielkość załącznika przechowywaną w DAOS i zalecane jest ok 64kB. Przypuszczalnie powodem wprowadzenia takiej rekomendacji jest narzut związany z umieszczaniem pliku w DAOS. Przypuszczalnie także dążenie do ograniczenia liczby plików w DAOS. Nie wiem czy są jakiekolwiek opracowania jak się DAOS zachowuje, jeśli zawiera dużą liczbę plików (kilkaset tysięcy lub więcej). Poza tym DAOS nie załatwi nam pól Rich Text, wklejonych obrazków, OLE itd.

O konfigurowaniu minimalnego rozmiaru załącznika pisałem wyżej. Maksymalna ilość plików w repozytorium DAOS to 40 milionów (1000 podkartotek po 40000 plików w każdej - takie parametry są wspierane aktualnie, ale liczę na ich zwiększenie w kolejnych wersjach Domino).

Marek Kuchciak
Link do wypowiedziLink
Artur K.

Artur K. DR NOTES

Temat: Bardzo duże repozytorium dokumentów

Dochodzimy do jakiegoś konsensusu. W jednej kwestii mam zdanie odmienne. Nie sądzę, że DAOS może poprawić wydajność w sytuacji, gdy załączniki się nie duplikują. Przytoczony przeze mnie przykład pokazuje (wydajność spadła) - jest czymś, czego należało się spodziewać. Nie zauważyłem, żeby IBM w swoich materiałach akcentował poprawę wydajności w innym kontekście jak eliminację operacji przy duplikujących się załącznikach. Źle mnie zrozumiałeś, gdy rozważałem jak się DAOS zachowa, gdy jest bardzo dużo plików (np. kilkaset tysięcy). Nie chodziło mi, jaki jest limit (bo to jest opisane) ale jak się DAOS "sprawuje" przy tak dużym archiwum. I właśnie takich informacji nie widziałem.

1000 podkartotek po 40000 plików - przecież to trzeba przeszukać przy każdej operacji odczytu/zapisu (wątpię, by się dało to trzymać w RAM). Nie może to pozostać bez wpływu na wydajność ..

Dlatego bazując na własnej intuicji, nie sądzę by DAOS poprawiał wydajność w takiej sytuacji. Ale aby definitywnie to stwierdzić, trzeba by dokładniej przeanalizować (a to nie takie proste) a jeszcze lepiej poprzeć testami.

Stąd też zalecenia, aby w DAOS przechowywać tylko stosunkowo duże pliki. Myślę, że nie należy zostawiać domyślnej wartości 4kb ale też i zalecane 64kb to za mało, jeśli spodziewamy się dużej liczby plików w archiwum.Artur Korol edytował(a) ten post dnia 08.03.10 o godzinie 00:45
Link do wypowiedziLink
Marek Kuchciak

Marek Kuchciak Wroslauer, IBM
Collaboration
Solutions, Social
Business

Temat: Bardzo duże repozytorium dokumentów

Artur Korol:
1000 podkartotek po 40000 plików - przecież to trzeba przeszukać przy każdej operacji odczytu/zapisu (wątpię, by się dało to trzymać w RAM). Nie może to pozostać bez wpływu na wydajność ..

Wyciąganie załączników wprost z systemu plików na pewno nie jest bardziej pracochłonną operacją I/O niż wyciąganie ich z pliku bazy .nsf. Przecież nie trzeba tych plików wyszukiwać - wewnętrzny identyfikator załącznika jednoznacznie determinuje nazwę pliku w repozytorium.
Dlatego bazując na własnej intuicji, nie sądzę by DAOS poprawiał wydajność w takiej sytuacji. Ale aby definitywnie to stwierdzić, trzeba by dokładniej przeanalizować (a to nie takie proste) a jeszcze lepiej poprzeć testami.

Zgoda. Test w danym przypadku byłby miarodajny. Oczywiście trzeba zadbać o poprawną konfigurację.
Stąd też zalecenia, aby w DAOS przechowywać tylko stosunkowo duże pliki. Myślę, że nie należy zostawiać domyślnej wartości 4kb ale też i zalecane 64kb to za mało, jeśli spodziewamy się dużej liczby plików w archiwum.

W Domino 8.5.1 domyślny minimalny rozmiar plików przechowywanych w repozytorium to 64000 bajty.

Marek Kuchciak
Link do wypowiedziLink
Artur K.

Artur K. DR NOTES

Temat: Bardzo duże repozytorium dokumentów

Marek Kuchciak:
Artur Korol:

Wyciąganie załączników wprost z systemu plików na pewno nie jest bardziej pracochłonną operacją I/O niż wyciąganie ich z pliku bazy .nsf. Przecież nie trzeba tych plików wyszukiwać - wewnętrzny identyfikator załącznika jednoznacznie determinuje nazwę pliku w repozytorium.

Zwróć uwagę na to, że dokument Lotus Notes w którym jest załącznik mamy już odnaleziony i otwarty. Wystarczy przeczytać trochę więcej sektorów z dysku i już. Żadnych obliczeń, przeszukiwań. W DAOS wewnętrzny identyfikator załącznika przekłada się na nazwę więc może i na to w którym jest katalogu(nie wiem) ale potem trzeba przeszukać katalog, który może zawierać do 40,000 plików. Mówimy cały czas o odczycie, zapis jest bardziej skomplikowany.

OK - nie roztrzygniemy tego bez miarodajnego testu. Ja w każdym razie w swoich wdrożeniach będą ustawiał minimalną wielkość pliku na coś powyżej 64kB aby ograniczyć liczbę plików w DAOS (jeśli spodziewać się mogę, że będzie ich b. dużo) bo wydaje mi się, że b. dużo plików w DAOS może go spowolnić.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Lokowanie dokumentów




Wyślij zaproszenie do
Anuluj