Vlákno názorů k článku SQLdep: Rozjetý český projekt v cloudu analyzuje datové toky od fd - Rad bych si od vas tu kristalovou kouli...

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).

SQL znám, používám, ale k čemu diagram který už dávno mám mít v návrhu.

Ano, tohle je přesné.
Jak uvádí i příspěvek pode mnou, tato aplikace předpokládá, že veškerá (nebo převážná) logika aplikace je v databázi.

Což zdaleka neplatí pro všechny případy. Naopak, jsou vývojáři, kteří toto nevidí rádi a nepoužívají tento přístup.

To je sice pěkné, ale takto přeložené adhoc SQL dotazy výše uvedený nástroj z databáze těžko vyčte, když tam nejsou....

A pokud aplikace používá jakýkoliv ORM, tak SQLdep nemá co analyzovat.

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í?

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 ?

Pokud používáte např. EF Code First, v databázi nemáte žádné stored procedury, ale pouze uložená data, tak je výše zmiňovaný nástroj v ..., neboť v databázi vidí pouze strukturu dat. Žádné stored procedury, žádné pohledy.

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.

To znamená, že se jedná o filtr příkazů volaných nad databází? Které analyzuje a pak předá dál?

Dobrá - monitor monitoruje komunikaci a co obsluha triggerů - ty nebere v potaz? Pokud jsou implementovány i INSTEAD OF triggery, pak analýza příchozích dotazů vůbec neobsahuje informace o tom kudy data tečou.

Navrh je jedna vec, druha vec je realny stav po nekolika letech :-)
Aby nedoslo k omylu: Mluvim o situaci ve velke firme, kde bezi desitky ci stovky IT projektu a data z jednoho systemu mohou vyuzivat projekty jine.

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 :-)

A jak dlouho to dela ? Pokud se nejaka tabulka pouzije treba jednou za rok a zrovna se do toho okamziku netrefi, oznaci ji za nepotrebnou ? To je opravdu uzasne :-)

Pak ani neni pravda, ze nemaji k dispozici data. Protoze ty jsou soucasti monitorovanych SQL prikazu.

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 ...

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).

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

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)

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.

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)