Názory k článku SQLdep: Rozjetý český projekt v cloudu analyzuje datové toky
-
Tomáš2 (neregistrovaný)
SQLDep jde dál, primární cíl není struktura databáze, ale vizualizace vazeb mezi entitami podle používaných dotazů.
Z relačního návrhu sice poznáš, že entita X je závislá na entitě Y, ale až ze samotných sql dotazů můžeš zjistit, že tahle vazba se nikdy nepoužívá nebo naopak se nadmíru používá nepřímá vazba. Nemluvě o snadné možnosti identifikovat slabá místa v návrhu relačního modelu.
Další velké využití vidím pro refactoring, není v současné době snadné identifikovat místa, která jsou na určitých entitách závislá a ty při změně relačního modelu zohlednit.
(s SQLdep jsem ale nepracoval a uvedené scénáře pouze odhaduji).
Podle popisu není patrné, jestli jsou schopní také nabídnout realtime auditování přístupu k určitým zdrojům, tak aby se zamezilo v počátku úniku informací do nepovolaných rukou při vytěžování databáze.
-
P2010 (neregistrovaný)
Vzdyt to je naprosty nesmysl.
Ze se "tahle vazba nikdy nepouziva" lze zjistit bezpecne jen z kodu nad databazi. Mozna se pouzije jednou za 5 let, pokud ji touto nesmyslnou pseudoanalyzou zrusi, bude problem.
Dale neni jasne jak "analyzuji SQL dotazy". To mohou jedine nejakym monitorovacim nastrojem, jehoz pouziti zpravidla ovlivnuje negativne vykon. I tak zjisti prd nebo nesmysl, protoze vykon vubec nezavisi na "slozitosti" SQL dotazu jako takoveho, ale na tom jaky se z neho vytvori nakonec execution plan. Navic kazdy slusny SQL server takove statistiky prubezne poskytuje a dokaze na jejich zaklade nabidnout moznosti optimalizace.
Stejne tak neverim ze ta jejich blbost podporuje adaptovani se dle execution planu podle stavu databaze, to jest dle rozlozeni stromu indexu a dalsi veci, ktere zpusobi ze se "stejny SQL dotaz" nakonec provede rozdilne, podle aktualnich dat (ktere pry nemaji).
Cele mi to prijde jako dalsi typicky startup nesmysl. Ale kdyz na to dokazi nekoho nalakat ...
-
Tomáš2 (neregistrovaný)
Ale vždyť oni ten kód prolézají a hledají to v něm. Struktura takových aplikací vypadá trochu jinak než co bastlíři dělají v php.
Oni analyzují strukturu dotazu pouze u sebe, nezajímá je žádný perf nebo execution plan na produkční db.
Prošel jsis vůbec jejich demo a podíval se co tam mají?
-
P2010 (neregistrovaný)
Oni analyzují strukturu dotazu pouze u sebe, nezajímá je žádný perf nebo execution plan na produkční db.
Coz jen potvrzuje, ze vysledkem je naprosta blbost bez kontextu znalosti skutecneho pouziti :-) Docela by me zajimalo, jak vypada cela aplikace po te jejich "optimalizaci".
Prosel, vidim jen reverzovane schema databaze, bez dalsich souvislosti. Co treba fulltext, OLAP, dotazy nad XML obsahem, filestream ?
-
Martin (neregistrovaný)
Nereverzujem schéma databáze, ale vykreslujem datový tok na základě SQL dotazů. Konkrétně jde o DML dotazy.. DDL slouží jen jako vstup, abychom byli na stejné startovní čáre jako parser/analyzer databáze v případě, kdy dotaz neobsahuje plně kvalifikované názvy sloupců.
Netvrdím, že SQLdep musí být použitelný pro vás. Z toho se ale nelze dovodit toho, že pro jiné nemá zásadní přínos.
Ve chvíli, kdy máte ETL zpracování datového skladu, které je dáno sousledností tisice SQL dotazů, pak poněkud zamrzí, když začnete ručně traverzovat podmnožinu dotazů, abyste se dostal po několika desítkach minut k tomu, co my vykreslíme do vteřiny. U nás zabodnete prst do sloupce a my vykreslíme, jak se ten sloupec naplnil a kam z něj následně data putují dále.
Krom toho příští týden releasujem feature, která vám umožní porovnat datové toky mezi DEV a LIVE, nebo LIVE v čase. Což je úplné scifi pro firmy, které nemají v pořádku dokumentaci.
- Martin (SQLdep)
-
P2010 (neregistrovaný)
A jak resite ulozene procedury, funkce a triggery ? To musite parsovat jejich SQL kod a cele je znovu interpretovat. Zvlaste pokud pouzivaji/zakladaji docasne tabulky, coz je u nekterych SQL serveru v pripade nekterych operaci prakticky nezbytne.
Stale mi to pripada jako odhadovat funkcnost webove aplikace na serveru pomoci analyzovani realtime HTTP komunikace :-)
-
fd (neregistrovaný)
Rad bych si od vas tu kristalovou kouli pujcil, nebot neznam jinou metodu, jak by se z SQL provozu dalo vydedukovat, jakym zpusobem se pouzivaji ona dotazovana data, natoz jejich vazby. Zcela bezne se totiz data svazuji prave az na urovni aplikace, predevsim z vykonostnich duvodu. Nadto formu dotazu neurcuje uzivatel, ale prave tvurce aplikace, a tudiz to, ze se aplikace zepta na 20 poli v 10 tabulkach nerika absolutne nic o tom, co ve skutecnosti chce prave resit uzivatel na urovni aplikace a tudiz ani nic o tom, co by pripadne bylo mozno optimalizovat. Dokonce se vubec nevi, jestli ona data aplikace vubec nejak pouzije (byt by je mela treba jen nabidnout ke zobrazeni).
-
none_ (neregistrovaný)
Myslim, ze zakladni problem je, ze nechapete, jak cilove databaze funguji. To neni jen sklad dat, ale prave obsahuji i dost velkou cast logiky. Predstavte si to tak, ze mate e-shop. Tam normalne uzivatel udela objednavku a e-shop ji nekam zapise. Uz ale neresi nic dalsiho. Vsechny ostatni procesy jsou navazane na zmenu dat tabulky s objednavkama. Takze pri nove objednavce se automaticky vytvori zadost o expedici objednavky, naskladneni do zasoby, pridani do celkovych prodeju,... (scenare si vymyslim, ale jde o to, ze e-shop o tomhle nema nejmensi sajnung).
-
P2010 (neregistrovaný)
Nejen to. V tom demu nejsou stored procedury vubec videt, takze pokud je to na nich zalozene (?), nechapu uz to vubec. Pokud to nejak analyzuje ETL procesy (SSIS v pripade MS SQL) tak je to opet zcela mimo, protoze ten package vubec nemusi byt napsan v SQL :-)
Kazdopadne ta vec vypada jako jeden velky nesmysl, na tom se asi shodneme :-) Mozna to funguje na nejakem PHP CRM s peti tabulkami, ale ne na skutecnych velkych aplikacich.
-
Vy pořád nechápete, co ten nástroje dělá, a zjišťovat to nehodláte, že? Ten nástroj nepotřebuje SQL příkazy uložené někdy v databázi, on analyzuje příkazy, které se proti té databázi provádí. A je úplně jedno, kde se ten SQL příkaz vezme, zda je napsaný v programu, nebo zda ho vytvořil ORM nástroj, nebo zda ho někdo napsal na konzoli.
-
Martin (neregistrovaný)
Tome, díky za super shrnutí.. na to, že se dovozuješ, tak se dovozuješ skvělě :) K tvému dotazu:
Podle popisu není patrné, jestli jsou schopní také nabídnout realtime auditování přístupu k určitým zdrojům, tak aby se zamezilo v počátku úniku informací do nepovolaných rukou při vytěžování databáze.
Jestli jsem to pochopil správně, pak by se mělo řešit nečím, co sedí hodně blízko databázi. Protože jen pak by bylo možné reagovat a unik zastavit. Od stávajících zákazníků jsme tohle zatím neslyšeli. Jinak dělat trace na to, kdo má jaká práva na jaké tabulky bychom v principu mohli, ale nevidíme za tím "use-case".
Jinak pro doplnění -- naše ambice není mít na API odezvu v milisekundách. Typický zákazník odešle dávku automaticky uprostřed noci a ráno mají všichni k dispozici aktuální dokumentaci. Pouze pro jednoho našeho zákazníka máme odezvu v řádu sekund a děláme v "real-time". Leč negarantujeme to a jde samozřejmě o menší dávky SQL dotazů (cca do stovky).
- Martin (SQLdep)
-
Tomáš2 (neregistrovaný)
díky za odpověď :). Databázemi se zabývám a v oboru nejsem zelenáč, ledacos mi tak smysl dává.
Pokud již máte k dispozici realtime data přístupu k tabulkám, sloupcům, je to jen krůček k tomu, abyste dokázali v čase vyhodnocovat a hledat nestandardní chování a notifikovat support. Banky ale předpokládám mají na tohle již svoje technologie a nedokážu si představit, že fungují bez toho.
Viz https://en.wikipedia.org/wiki/Database_activity_monitoring
-
Ivan Nový (neregistrovaný)
Vytvoříte vlastní server s překladačem SQL a místo provádění příkazů vytváříte schéma popisující datové toky. Pokud budete dále SQL příkazy posílat do reálné databáze, vznikne vám mezistupeň, kterým můžete sledovat datové toky přímo v reálném čase a na základě reálných dat ještě schéma datových toků doladit o statistické údaje ukryté v reálných datech.
V podstatě na to můžete použít PEG gramatiku, která vám umožní analyzovat jen potřebné části SQL příkazů, použijete-li k tomu ještě "pancrat parsing", tak použitý koš frází bude přirozeným kolektorem statistických dat a bude přímo odrážet datové toky.
-
Ivan Nový (neregistrovaný)
Tak SQL compiler samozřejmě musí někdy přeložit i tuto uloženou proceduru, nebo předkompilovaný příkaz, takže zachytí a analyzuje i obsah. Takže budete vědět zda se někam zapisuje, odkud se čte atp. Samotné volání vám pak řekne, kdy se to někam zapisuje resp. čte. Jinak co nepotřebujete, můžete ignorovat a bez statistického zpracování poslat na reálný server. Pokud se vyvolá něco napsaného v jiném jazyce, tak se to může projevit voláním zase jiných SQL příkazů, které se zase někdy musely zkompilovat a jsou tedy podchyceny a nebo se pracuje přímo s interním formátem dat, ale to je prasečina sama o sobě a na tu samozřejmě neplatí vůbec nic, ale aspoň se odchytí informace o ní.
-
P2010 (neregistrovaný)
SP, funkci nebo ETL package muzete v pripade MS SQL serveru napsat v libovolnem .NETovem jazyce, protoze server podporuje tyto databazove objekty nejen v SQL ale i CLR.
Uz vidim, jak nekdo pise "SQL interpreter" ktery bude plne simulovat nejen konkretni podobu SQL jazyka daneho serveru, ale i vsechny jeho systemove ulozene procedury/funkce/views (a tim interni tabulky ktere udrzuji stav), ktere se opet bezne pouzivaji z aplikacni urovne.
Jestli je tu neco "prasecina", je to prave cely ten pochybny nastroj :-)
-
booster (neregistrovaný)
SQLDep není nástroj na záchranu jakékoli aplikace. Myslím že v článku bylo, že to je na analýzu datových toků v datovém skladě. Pro OLTP si to ani neumím moc představit, ale DWH jede celý dávkově, jednotlivé SQL příkazy pracují vždy s celou sadou dat a nikoli s jednoltivými klienty či dealy. S ad-hoc SQL příkazy se u DWH moc nepracuje kromě sandboxů (data labů), ale tam zase nepotřebujete dělat dopadové analýzy.
Pokud má DWH nějaké GUI, tak maximálně pro monitoring běhu jednotlivých ETL procesů.
Klíčová informace pro analytiky datového skladu je odkud kam v rámci DWH data tečou - když se na začátku stane změna/chyba, tak chci vědět kam se zpropaguje nebo naopak, když je mi podezřelá nějaká hodnota ve výsledném exportu/reportu, tak kde se pro ni posbíraly data. Neviděl jsem nikde takovou (dopřednou) dokumentaci datového skladu, která by umožnila rekurzivně takovéto analýzy provádět.
Samozřejmě záleží na tom, jak a v čem máte DWH implementován. Pokud jsou to z 99% databázové set-based SQL příkazy, obalené nějakým frameworkem jako (nejen) v mém případě, tak tento nástroj prostě má popsanou přidanou hodnotu. Pokud kompletní ETL mapping máte v SSIS nebo IBM DataStage nebo Informatice (upřímnou soustrast), tak pro výše popsanou analýzu použijete právě SSIS, IBM DataStage nebo nebo Informatiku. Pokud se jedná o kombinaci obou přístupů, tak SQLDep lze nakrmit i "simulacemi" resp. vygenerovanými SQL příkazy, akorát se v nich pak musí analytik vyznat.
Výhodu SQLDep vidím v agilním přístupu, že smysluplnou poptávku po nové funkcinoalitě analyzátoru kluci v Praze opravdu celkem flexibilně doplní, což se u kluků z IBM nebo Microsoftu spíš nestane. -
booster (neregistrovaný)
Můžete to prosím upřesnit? Rád bych věděl, jaké vlastnosti DWH jsou natolik chybné, že by kvůli nim neměl být provozován.
Pokud máte na mysli implementaci formou ručně vytořených SQL příkazů mimo komerční ETL nástroj, tak to je nejen v ČR celkem rozšířený přístup, anebo minimálně se používá kombinace části logiky v ETL nástroji a částečně mimo něj. Také jsem viděl několik custom developed ETL nástrojů. Naopak u praktických nasazení ETL nástrojů se setkávám spíš s přístupem, kdy si zákazníci vyvíjejí robustní nadstavby a generátory mappingů nebo workflows do ETL nástroje. Máte tedy s některým komerčním ETL nástrojem tak dobré zkušenosti, že byste ho doporučil pro efektivní výhradní použití?
Pokud máte na mysli způsob dokumentace source-to-target mapování, též by mě velmi zajímal takový nástroj nebo metodika, která by 100% a efektivně pokryla všechny relevantní datové toky a uměla je trackovat (ideálně rovnou s propojením na cílový zdrojový kód), a zároveň by existoval proces, který by zajistil, že se dokument a realita nerozjede. Dost se touto tematikou teď zabývám a hledám optimální přístup. Ale ve využití klasických ETL nástrojů jsem ho zatím nenašel, tak třeba mě přesvědčíte.
-
P2010 (neregistrovaný)
Zakladem kazdeho takoveho procesu je, ze by mel byt nekde zdokumentovan a nekdo jej urcite nekdy zadal. Cely ten nastroj na mne pusobi dojmem, ze se snazi hasit jiz dohorely pozar. Zkratka to, kdyz maji nekde ve vsem bordel, ten kdo dany proces vytvoril uz tam davno neni a ted se tezce snazi zpetne zjistit, co to vlastne presne dela.
-
booster (neregistrovaný)
Tak to není náš případ. Na dokumentaci máme celkem striktní metodiku jak co do formy, tak i do procesu (je i podrobena QA, slouží jako zadání pro vývojáře i testera) a bílých míst máme velmi málo - u našich dodávek používáme z 95% waterfall approach. Totéž pokud vím, platí i u několika dalších firem, kde se manta nebo sqldep používají.
Problém je, že naše forma dopředné dokumentace prostě neumožňuje automatizované trasování datových toků v rámci dopadových analýz - prostě technicky nejsou na úrovni metadat propojeny zdrojové sloupečky s cílovými - i když ze sémantiky srozumitelné člověku to jde. Ale i kdyby to šlo automaticky, tak velice rád použiju takovýto analyzátor pro rekonciliaci, že dokumentace odpovídá tomu, co je reálně naprogramováno - byla by to levná a relativně spolehlivá cesta (doplňujícího) testu a jen jeden z mnoha možných use cases takového nástroje.Jinak v článku se píše, že takovýto nástroj je celkem ojedinělý, ale není to pravda - existuje řada komerčních nástrojů, které zapadají do konceptu metadata managementu, viz např. zde https://www.capgemini.com/insights-data/data/metadata-management
Akorát tyto nástroje postihují metadata management komplexněji, obsahují např. i business glossary (sql parsery jsou jejich klíčovou součástí, ale je tam i parsing dalších jazyků, s cílem právě vytvořit data lineage) a jsou podstatně dražší.
