Opravdu hezky nacvičená řeč, které ovšem někomu, kdo se v této oblasti běžně nepohybuje, neřekne vůbec nic. Informace o tom, kolik procent dat je ve strukturované podobě a jaký objem dat je vytvořen za časové období, jsou sice zajímavé, ale ponižuje to celou prezentaci na čistý marketing toho, aniž by se kdokoliv dozvěděl, jak in-memory comuting vlastně funguje. Kupte si hrnce, určitě je budete potřebovat protože jíst musíte, ale nemusí Vás zajímat v čem jsou lepší, hlavně když je zaplatíte.Protože se v této oblasti pohybuji, udělám za pány špinavou práci a stručně se pokusím specifikovat, o co vlastě v in-memory comutingu jde a proč je to vlastně "cool" :) Protože in-memory computing staví právě na zpracování dat v paměti a každá společnost má vlastě svůj vlastní systém, jak toho optimálně dosáhnout a nejsem rozhodně expert na všechny, pokusím se to vysvětlit na konkrétní Microsoft technologii.Všechna data, která mají být při dotazu zpracována, musí mít systém v paměti, to není nic nového.
In-memory databáze nebo objekty ovšem optimalizují práci s daty obzvláště v těchto směrech :
- vysoká míra komprese dat
- optimalizace paralelního zpracování
- odlišný způsob uložení datKonkrétně například nový typ indexu v MS SQL Server 2012 Enterprise Edition, který se nazývá Columnstore index.
Běžně jsme zvyklí, že se data v tabulkách ukládají v podobě řádků. Když chcete vypočítat třeba sumu nad konkrétním sloupcem prodeje, databázový systém si všechny řádky uloží do paměti a pak z každého řádku vytáhne hodnotu sloupce a zpracuje ji. Tento postup se nazývá Row mode nebo row-at-time. Musí tedy do paměti umístit celé řádky, byť z nich potřebuje pouze jediný sloupec.
Columnstore index ukládá data nikoliv po řádcích, ale uloží data každého sloupce samostatně. Při počítání sumy nad sloupcem tedy stačí vzít tu část, která prokazatelně obsahuje pouze hodnoty konkrétního sloupce a ne celé řádky. Protože hodnoty z jediného sloupce uložené pohromadě mají často podobné nebo stejné hodnoty, tento způsob uložení je výrazně efektivnější pro kompresní algoritmus (hodnoty 1000,1001,1002,1003 atd mají stejný prefix 100 a proto není nutné ho ukládat mnohokrát, ale stačí jednou... tak pracuje komprese).
Při zpracování dat je celý sloupec rozdělen na části, obvykle obsahující asi 1000 záznamů a každá ta část je zpracována hromadně, čemuž se říká Batch mode nebo batch-at-time. Při paralelní operaci tedy dochází k tomu, že každé vlákno zpracovává jednotlivé, podobně velké skupiny a nemusí docházet k tak časté výkonnostně náročné synchronizaci práce vláken, které známe ze současných systémů.
No a poslední optimalizace vyplývá z již řečeného, potřebujete sumu nad jediným sloupcem (nebo několika) ? Stačí do paměti uložit pouze a jen data toho sloupce, ne celé řádky tabulky, tedy várazné snížení I/O operací při čtení dat z disku do paměti a výrazně menší paměťové nároky pro uložení dat (také díky kompresi).Fakta jsou jasná a opravdu to funguje, není to jen tak nějaký výmysl jak prodat novou technologii bez reálného užitku. Osobně mám technologii vyzkoušenou a tentokrát marketing nelže... pokud je implementace provedena správně, snížení délky trvání dotazů nad objemnými daty je i (původní čas/100) nebo více.
Nad malým objemem dat to nemá smysl... Ale podařilo se mi simulovat případ, kdy z původních 12 sec doby zpracování byl výsledek nove za 0.2 sec (což je u tak krátkého dotazu směšné).
