Duombazė. DIDELĖ ir judri

397 views
340 views

Published on

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?

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
397
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Duombazė. DIDELĖ ir judri

  1. 1. DuombazėDIDELĖir judrijudri
  2. 2. /urs/bin/whoamiDidelių duomenų technologinis architektasTadas.Makcinskas@bdc.lt@mctadashttp://bit.ly/12a0hkB
  3. 3. Kur
  4. 4. siaubo istorijahttp://bit.ly/15wOJfI
  5. 5. Reliacinėduomenųbazė
  6. 6. ACID savybėsNeskaidoma (angl. ATOMICITY): Viskas arba niekoVientisa (angl. CONSISTENCY): Bet kuri transakcija perkeliaDB iš vienos vientisos būsenos į kitą nepažeisdama kitų savybiųIzoliuota (angl. ISOLATION): Operacijos negali prieiti prieduomenų, kurie šiuos metu yra modifikuojami kitos darnepasibaigusios transakcijosTvari (angl. DURABILITY): Galimybė atstatyti patvirtintastransakcijos nutikus bet kokiam sistemos sutrikimui (transakcijųlog’as)
  7. 7. DB schemų apjungimashttp://bit.ly/140wISs
  8. 8. StartuolisDidelis neapibrėžtumasGreiti ir dažni pokyčiaiLaukiamas eksponentinis augimasVisuomet pasiekiamas servisashttp://bit.ly/YC4wr0
  9. 9. Sistemos poreikiaiNepertraukiamas prieinamumasAtsarginė sistemaGreitas duomenų prieinamumasUžklausų balansavimasGeografiškai jautrūs duomenys
  10. 10. NoSQL
  11. 11. Gidas į NoSQLhttp://bit.ly/12OBIY9VientisumasPrieinamumasToleruoja atskyrimą
  12. 12. Analitika Architektūra Programavimas TestavimasKrioklinis metodasAnalitika Architektūra Programavimas TestavimasAnalitika Architektūra Programavimas TestavimasAgile procesasAnalitika Architektūra Programavimas TestavimasAnalitika Architektūra Programavimas TestavimasAgile procesas + Agile įrankiai
  13. 13. Mitas arrealybė
  14. 14. DB architektas
  15. 15. Pirmieji sprintai (db schema)Lankstūs duomenų tipaiIš anksto neapibrėžta schemaKey-Value duomenų surišimasDB migravimas, praeitisDB projektavimas paprastas
  16. 16. Lenglvas DB projektavimas
  17. 17. Lengvas DB plečiamumas
  18. 18. Pavojai skaidant DB (sharding)
  19. 19. Automatizuotas duomenų skaidymas
  20. 20. DB savininkas ir tvarka
  21. 21. Harmonija tarp kodo ir DB
  22. 22. Transakcijų kompromisas
  23. 23. Palaikomos transakcijos
  24. 24. Kąpasirinkti
  25. 25. Reliacinė DB geras pasirinkimasOLTP – programų aibė vykdanti ACIDtransakcijas. (geriausias kombinacijatarp duomenų kokybės irgreitaveikos)Reikia užtikrinti duomenų teisingumą nepriklauso nuojais besinaudojančių sistemų.Klausimus užduodami DB nėra žinomi (ad-hoc)Sudėtingi duomenų tarpusavio sąryšiaiYra poreikis palaikyti SQL
  26. 26. NoSQL DB geras pasirinkimasĮvykiais paremtos transakcijosHierarchiniai objektai sistemojePaskirstyta sistema veikianti debesyje.Masiškai įrašomi duomenysReikalinga lanksti schema ir lankstūs duomenų tipaiGreiti ir nepriklausomi nuo apkrovimo DB skaitymaiDinaminis lentelių kūrimasProgramuotojų komanda atsakinga už duomenų DB
  27. 27. Hadoop geras pasirinkimasJeigu duomenys tampa perdideli paskaičiuoti ant vienoserverio (DWH)Jeigu reikia išsaugoti TB-us įvairių duomenų sugalimybe juose atlikti analizę ir reikia jusanalizuoti laiko intervalais (angl. time seriesanalysis)
  28. 28. Kitiklausimai

×