Duombazė. DIDELĖ ir judri
•
1 like•628 views
Tado Makčinsko skaitytas pranešimas Agile Dienoje 2013 gegužės 9d. Pastoviai susiduriame su problemomis valdant ir administruojant duomenų bazes. NoSQL duomenų bazės dėl savo lankstumo padeda spręsti nemažai DB architektams ir administratoriams kylančių iššūkių. NoSQL padeda susidoroti su neprognozuojama plėtra, dideliais duomenų srautus, lengvai integruojasi su iteratyviu procesu, leidžia pamiršti skausmingą DB migravimo procesą. DB schemų projektavimas, toks kokį mes žinome šiandiena, jau praeityje?
Duombazė. DIDELĖ ir judri
- 2. /urs/bin/whoami Didelių duomenų technologinis architektas Tadas.Makcinskas@bdc.lt @mctadas http://bit.ly/12a0hkB
- 3. Kur
- 6. ACID savybės Neskaidoma (angl. ATOMICITY): Viskas arba nieko Vientisa (angl. CONSISTENCY): Bet kuri transakcija perkelia DB iš vienos vientisos būsenos į kitą nepažeisdama kitų savybių Izoliuota (angl. ISOLATION): Operacijos negali prieiti prie duomenų, kurie šiuos metu yra modifikuojami kitos dar nepasibaigusios transakcijos Tvari (angl. DURABILITY): Galimybė atstatyti patvirtintas transakcijos nutikus bet kokiam sistemos sutrikimui (transakcijų log’as)
- 8. Startuolis Didelis neapibrėžtumas Greiti ir dažni pokyčiai Laukiamas eksponentinis augimas Visuomet pasiekiamas servisas http://bit.ly/YC4wr0
- 9. Sistemos poreikiai Nepertraukiamas prieinamumas Atsarginė sistema Greitas duomenų prieinamumas Užklausų balansavimas Geografiškai jautrūs duomenys
- 10. NoSQL
- 13. Analitika Architektūra Programavimas Testavimas Krioklinis metodas Analitika Architektūra Programavimas TestavimasAnalitika Architektūra Programavimas Testavimas Agile procesas Analitika Architektūra Programavimas TestavimasAnalitika Architektūra Programavimas Testavimas Agile procesas + Agile įrankiai
- 14. Mitas ar realybė
- 15. DB architektas
- 16. Pirmieji sprintai (db schema) Lankstūs duomenų tipai Iš anksto neapibrėžta schema Key-Value duomenų surišimas DB migravimas, praeitis DB projektavimas paprastas
- 19. Pavojai skaidant DB (sharding)
- 21. DB savininkas ir tvarka
- 22. Harmonija tarp kodo ir DB
- 25. Ką pasirinkti
- 26. Reliacinė DB geras pasirinkimas OLTP – programų aibė vykdanti ACID transakcijas. (geriausias kombinacija tarp duomenų kokybės ir greitaveikos) Reikia užtikrinti duomenų teisingumą nepriklauso nuo jais besinaudojančių sistemų. Klausimus užduodami DB nėra žinomi (ad-hoc) Sudėtingi duomenų tarpusavio sąryšiai Yra poreikis palaikyti SQL
- 27. NoSQL DB geras pasirinkimas Įvykiais paremtos transakcijos Hierarchiniai objektai sistemoje Paskirstyta sistema veikianti debesyje. Masiškai įrašomi duomenys Reikalinga lanksti schema ir lankstūs duomenų tipai Greiti ir nepriklausomi nuo apkrovimo DB skaitymai Dinaminis lentelių kūrimas Programuotojų komanda atsakinga už duomenų DB
- 28. Hadoop geras pasirinkimas Jeigu duomenys tampa per dideli paskaičiuoti ant vieno serverio (DWH) Jeigu reikia išsaugoti TB-us įvairių duomenų su galimybe juose atlikti analizę ir reikia jus analizuoti laiko intervalais (angl. time series analysis)
- 29. Kiti klausimai