DB Options - vylepšení celého řešení na úrovni databázové vrstvy, část 2.

Dnes dokončíme přehled options a další vlastnosti databáze, které mohou pomoci při práci s dokumenty.

SecureFiles jsou vlastností databáze 11g pro práci s nestrukturovaným obsahem ("dokumenty"). Při jejich užití je možné uložené dokumenty: deduplikovat (v případě vkládání stejného dokumentu se ukládá jen jednou), komprimovat a šifrovat (na rozdíl od Security Option se šifrují jen samotné dokumenty).

Oracle Text dokáže vytvářet fulltextové indexy. Pro jeho využití není nezbytné, aby se dokument ukládal do databáze (indexace probíhá proti souboru na disku). Při jeho využití není potřeba dokupovat index servery třetích stran (v dřívějších verzích Stellent spolupracoval s nástrojem Verity).

Oracle Data Guard je řešení pro synchronizaci mezi primární a záložní lokalitou. V případě ukládání dokumentů do databáze je možné dokumenty i metadata synchronizovat čistě touto technologií. Co zatím není možné, je využít option Active Data Guard, který dokáže záložní lokalitu využívat pro read-only dotazy. V současném nasazení je možné záložní lokalitu využít pro testovací či školicí prostředí (využívá "volný" výkon zbylý po synchronizaci).

Advanced Compression option umožňuje zmenšit obsah, který zabírají na disku - opět se vztahuje jak na dokumenty, tak na metadata. Její využití na dokumenty závisí do značné míry na ukládaném obsahu (MS Office dokumenty se komprimují dobře, PDF už mnoho neušetří), komprimace metadat může mít vliv při opravdu velkých projektech (desítky miliónů záznamů a více). Při těchto objemech už může být zajímavé i nasazení Hybrid Columnar Compression, která je k dispozici v Exadatě.

Co říci závěrem?
Databáze je jednou z vrstev ECM řešení a zejména u velkých řešení je dobré se zamyslet na celkovou architekturou a požadavky a nastavit využití databáze dle potřeb. Jedno ideální řešení určitě neexistuje, ale vždy je možné najít optimum pro konkrétní danou situaci.

DB Options - vylepšení celého řešení na úrovni databázové vrstvy, část 1.

V návaznosti na článek z minulého týdne, kdy jsme se dotkli tématu databázových options, pojďme si udělat kompletní přehled, které z nich a jiných vlastností databáze Oracle mohou a jakým způsobem přispět k celkovému řešení pro správu dokumentů.

Real Application Clusters (RAC): jedná se o option, který má na starosti škálování (při přidání dalšího databázového uzlu-serveru se výkony všech sčítají) a vysokou dostupnost (při výpadku jednoho uzlu-serveru běží řešení na zbývajících) na úrovni databáze. Její funkce je transparentní pro běh podporovaných aplikací.

Partitioning: partitioning dokáže rozdělit velké tabulky na několik částí (partitions). Tato vlastnost může mít pozitivní vliv na výkon (běží-li dotaz v rámci jediné nebo několika partitions, může běžet rychleji). Z pohledu řešení UCM je však mnohem důležitější, že při využití další vlastnosti databáze, Automatic Storage Management, mohou být jednotlivé partitions uloženy na různých fyzických médiích, což může vést k výrazným úsporám na úložném prostoru. Další využití partitioningu může být při backupu či obnově ze zálohy - při vhodném návrhu kritérií partitioningu je možné urychlit backup (mění se jen 'nejnovější' partitions), či spustit řešení nad ne zcela obnovenou databází (např. se obnoví jen data za poslední měsíc či rok, které jsou pro uživatele nejdůležitější a starší budou do systému dodávány teprve postupně). Zde už je třeba trochu znát, jaký je datový model. V zásadě ale platí, že dokumenty (tabulka FileStorage) či historické záznamy (SCTAccessLog či např. WorkflowHistory) je možné partitionovat hierarchicky, naopak metadata (např. Revisions) je sice možné partitionovat, při obnově však musí být tabulka obnovena celá.

U některých projektů (zejména v oblasti Records Managementu) se někdy zavádí koncept 'životně důležitých dokumentů', kdy jsou takto označené dokumenty obnoveny prioritně - kritérium pro partitioning je tedy řízeno metadaty.

V zásadě platí, že přesáhne-li velikost databáze 1 TB, nejspíš byste měli partitioning v architektuře využít.

Advanced Security (ASO), Database Vault, Label Security: jak napovídá název, tyto options jsou zaměřeny na zabezpečení - v tomto případě se jedná o zabezpečení před útoky "zevnitř" (ze strany administrátorů). ASO umožňuje zašifrování citlivých údajů - ať už ve metadatech, nebo především pak vložené dokumenty, a to buď přímo v databázi, nebo i v dalších užití - v backupech, při posílání po síti apod. Ostatní dvě technologie pak mohou zajistit, že ani administrátor databáze nebude mít možnost dané nastavení měnit - jeho oprávnění budou dána nastavením v systému pro správu identit.

Nasazení těchto komponent je na místě, pokud systém bude spravovat citlivá data. Víceúrovňová správa přístupu pak může být zajímavá i pro hostovaná řešení (správce prostředí se bude starat o chod prostředí, nebude mít však žádný přístup ke spravovaným datům).

(pokračování někdy příště)

Ukládat, či neukládat (dokumenty do databáze)

Nedávno jsem byl svědkem dvou, poměrně vášnivých, diskuzí na téma zda ukládat dokumenty do databáze, či nikoliv. Osobně se nekloním ani na jednu stranu. Trefně to však vystihl kolega, který prohlásil, že každý preferuje to, co zná. Pojďme se však podívat na věc pokud možno objektivně.

Rychlost (zejména vkládání dokumentu)
Častým argumentem odpůrců vkládání je tvrzení, že vkládání dokumentu na databáze trvá výrazně déle než vkládání na filesystem. Toto (minimálně pro databáze Oracle) byla pravda někdy, dnes již dost dávno. Obecně trvá vkládání do databáze o něco déle, rozdíl je však v jednotkách procent. A pro některé speciální případy (vkládání mnoha krátkých souborů najednou) dokáže být databáze dokonce rychlejší. Stejně tak může být rychlejší, pokud je systém synchronizován (např. z důvodů disaster recovery - databáze synchronizuje celý commit, filesystem každou změnu).

Komprese, deduplikace, šifrování dokumentů
Argumentem zastánců databáze naopak bývá možnost využití databázových options, a to zejména na kompresi vkládaných dokumentů (zmenšení obsahu na disku), deduplikaci (vkládá-li se stejný soubor vícekrát, je uložen fyzicky jen jednou a z dalších míst existuje odkaz) a zašifrování (ani pro db administrátora nebude soubor čitelný, pokud si jej vyhledá prostředky databáze).
Předně, tyto options často bývají k dispozici i na úrovni filesystému (zpravidla taktéž za příplatek). Navíc, jejich přínos je velmi závislý na tom, co se bude do úložiště ukládat (dokumenty MS Office se budou komprimovat dobře, PDF, TIFF či JPEG formátům asi komprese moc neubere), či jak je projekt implementován (přílohy emailů po firmě by se neměly posílat jako soubory, ale jako odkazy do úložiště).

Synchronizace active a stand-by lokality
Podobně je na tom využití technologie DataGuard pro synchronizaci active a stand-by lokality u řešení v rámci disaster recovery. UCM bohužel "odkládá" některá provozní data na filesystem (z těch nejznámějších: stavy položek ve workflows), a tak je podporována jen instalace, kde je synchronizována databáze i filesystem.

Fulltext indexace
Databáze umí (kromě engines třetí strany) indexovat soubory pro fulltextové vyhledávání. Pro využití této vlastnosti však není nezbytně nutné, aby zdrojové soubory byly uloženy v databázi (v databázi je v každém případě výsledný index).

Jednotná správa
Pokud nebudete implementovat model OAIS, který vyžaduje, aby i v případě ukládání dat na "otevřenou platformu" byla data i metadata u sebe, dá se očekávat, že při ukládání na filesystem budou metadata v databázi, tj. při případné ztrátě či chybě, která oba celky od sebe rozpojí, budete mít problémy spojit, co k sobě patří (po pravdě řečeno, i s metadaty rozházenými na disku to nebude o moc snazší). Toto je tedy argument pro databázi. Na druhou stranu, k jeho uplatnění dojde jen v opravdu krizových situacích a v případě správné politiky zálohování lze dopady minimalizovat.

Hierarchical Storage Management
To jest, ukládání starších dat s možnou delší vybavovací dobou na levnější fyzická úložiště lze dosáhnout jak prostředky databáze, tak filesystému - při využití partitioningu bude databáze pracovat s několika málo většími soubory, zatímco na filesystému bude základní jednotkou nejspíš jednotlivý soubor, což opět může být mírný agrument pro databázi.

V souhrnu je tedy vidět, že obě metody jsou srovnatelné s mírnou převahou pro ukládání v databázi. Při výběru metody je tedy třeba zvážit i to, na co jsou zvyklí administrátoři zákazníka či zda zákazník neinvestovat do jedné či druhé metody a očekává zhodnocení svých investic v rámci projektu.

Ukládání nestrukturovaného obsahu do databáze

V dnešním článku se pokusím zaměřit na téma, o kterém stále koluje řada dezinformací. Protože se budu pouštět spíše na led databázistů (dokonce nejen oraclovských), dovoluji si požádat o benevolenci při technických detailech - v hlavních argumentech bych se ale plést neměl.

Jak je to tedy s tím ukládáním do databáze:
- první nezvratné tvrzení je, že je to možné, a to jak pro databáze Oracle (min. od verze 10g), tak pro Microsoft SQL Server (podle informací, které jsem našel, nejspíš od verze MS SQL 2005)
- druhé tvrzení je, že UCM 11g je certifikováno na oba výše zmíněné databázové servery. Ukládání se však neděje přímo do databáze, ale přes jakési dočasné úložiště na filesystému, a to pomocí komponent FileStore Provider (což jsou jakési speciální adaptéry, které umí ukládat obsah prakticky kamkoliv). Důvodem pro meziúložiště je to, že některé části systému (např. konverzní server) zatím neumí pracovat s ničím jiným, než soubory na disku
- třetí tvrzení je, že ukládání do databáze je pomalejší a méně efektivní (o režii, kterou databáze má). Nevím jak pro Microsoft, ale pro Oracle toto tvrzení (pro některé typy úloh) již neplatí. Od verze 11g obsahuje databáze technologii SecureFiles, která je optimalizovaná takovým způsobem, že
a) dokáže "mnoho malých souboru" načítat v dávce tak, že dokonce porazí ve výkonu filesystem. Toto řešení bylo optimalizováno především na ukládání emailů, což jsou velmi často poměrně krátké zprávy.
b) dokáže nad ukládáným obsahem provozovat kompresi, deduplikaci a šifrování, takže dokáže na některých operacích "ušetřit"
- čtvrtým tvrzením je, že pro mnohé ECM projekty je ukládání souborů do databáze sňatkem z rozumu. Kvůli metadatům je databáze tak jako tak nutnou částí projektu, takže možností ukládat i nestrukturovaná data je možné jednou ranou vyřešit zálohování/obnovy, disaster recovery scénáře a v konečném důsledku mít jednoho administrátora na všechno. Při využití vhodném využití technologií jako je partitioning, je možné jeden velký soubor rozdělit na přijatelné množství (vyhnout se druhému extrému: spoustu malých souborů) - byť vybrat vhodné kritérium pro partitioning může být u obecných dokumentových projektů poměrně obtížné. A v neposlední řadě je možné využít Automatic Storage Management, který se na základě metadat (UCM) postará o uložení na správné médium (HW) v rámci životního cyklu informace (ILC).

Rozšiřitelnost Oracle UCM - využití hierarchických dotazů v databázi

V tomto článku si budeme demonstrovat rozšiřitelnost Oracle UCM na jednom konkrétním problému z reálného života. Jeden potenciální zákazník se na nás obrátil s otázkou, zda UCM umí na úrovni adresářů (komponenta Folders_g) pracovat s kvótami. Ve standardní verzi tato funkcionalita není, jedná se však o poměrně jednoduché rozšíření.

Představme si tedy, že budeme chtít implementovat kontrolu nepřekračování přidělovaných kvót v následujícím schématu:

Problém s kvótami je, že nemusí být přiřazeny pro všechny adresáře - např. kvóta pro společnost A, kterou přiděluje správce úložiště, může být dále rozdělena a i zde mohou existovat adresáře s omezeními kvóty či bez omezení. Tyto "díry" povedou na netriviální rekurzivní dotazy.

Př. 1. vkládání dokumentu do adresáře uživatele 2 se musí nejprve zjistit, zda existuje nějaký adresář (buď adresář sám, nebo některý z jeho předků v hierarchii) s nastavenou kvótou. Kontrola možného překročení kvóty pak bude probíhat na úrovni tohoto adresáře, pokud nějaký takový adresář vůbec existuje.

Př. 2. vlastní výpočet vyčerpané kvóty je rovněž rekurzivní:

• kvótu mohou vyčerpat soubory vložené do adresáře
• či podadresáře, přičemž je-li podadresáři přiřazena jeho kvóta, pak se počítá s ní; v opačném případě se opět musí najít soubory a podadresáře do něj vložené

Rekurzivní vazba je daná přímo v databázové tabulce Collections: každý adresář má svůj jednoznačný identifikátor (dCollectionId) a kromě kořenového adresáře též svého přímého předka (dParentCollectionId).

Nalezení prvního adresáře s nenulovou kvótou (Př. 1) může být v databázi Oracle implementováno přímo jako jeden dotaz (stejné je tomu s Př.2):

select DCOLLECTIONQUOTA, DCOLLECTIONID, DCOLLECTIONNAME from COLLECTIONS
where DCOLLECTIONQUOTA > 0
start with DCOLLECTIONID = ?
connect by DCOLLECTIONID = PRIOR DPARENTCOLLECTIONID and DCOLLECTIONQUOTA > 0 and PRIOR DCOLLECTIONQUOTA is null

? v dotazu představuje placeholder pro parametr dCollectionId adresáře, pro který dotaz voláme

O hierarchických dotazech si více přečtěte v článku Davida Krcha zde.

Tento případ hezky demonstruje, že Oracle UCM je skutečně otevřený systém, který dokáže využívat nejlepších vlastností ostatních technologií.