Keskusmuistipohjaiset tietokannat

1. Keskusmuistipohjaiset tietokannat DB2YTRHeksinki, 2010-05-04 Antoni WolskiChief Researcher, solidDB IBM Helsinki Lab Software Group

2. Sisältö Perinteisen tietokannan pullonkaulat Keskusmuistitietokannan periaatteet Keskusmuistipohjaiset saantimenetelmät Väliotoksen teko • Pääkysymykset: • Miksi? • Miten? • Miksi helppoa? • Miksi vaikeaa? Pysyvyyden toteutustekniikat Sovellusarkkitehtuurit Suorituskykytulokset Ei-pysyvien taulujen tyyppejä Tuotekatsaus Hybridi tietokanta- järjestelmä Uudet haasteet

3. Mikä on oleellisinta tiedonhallinnassa? SQL-kieli ja relaatiomallin tuki Kyselyjen optimointi, suoritus • Jaettu tieto • ... ja sen nopea • ... ja joustava saanti, • … ja sen pysyvyys • … ja eheys Rinnakkaisuudenhallinta Toipumisen varmistus Jaettu puskuri Saantimenetelmät ja levytoiminnot Väliotos (checkpoint) Transaktio- loki Tietokanta

4. Nopeutta etsimässä: tietokantojen muistitasot Saantiaika 1 ns Prosessorin puskuri(cache) L1 rivin koko: 16-128 B x 10 Saantiaika 10 ns Prosessorin puskuri(cache ) L2 rivin koko: 16-128 B x 10 Saantiaika 100 ns Sivupuskuri keskusmuistissa (sivut 2 - 64 KB) x 100 000 Pahin pullonkaula Saantiaika 10 ms Tietokantasivut levyllä Lokitiedot levyllä

5. Keskusmuistipohjaisen tietokannan periaatteet • Tavoite: poistaa tai vähentää levytoimintojen hidastava vaikutus säilyttäen muut tietokannan ominaisuudet [GMS92] • Ratkaisu: • tietokanta sijaitsee pääasiassa keskusmuistissa • pysyvyys ratkaistaan väliotos- ja lokitiedostojen avulla • tietokanta alustetaan keskusmuistiin otostiedostojen (checkpoint) avulla • lokikirjoitus optimoidaan ja valinnaisesti pysyvystaso säädellään < • (durability level: strict  relaxed) • saantimenetelmät (indeksit) optimoidaan keskusmuistihakua varten, myös puskuriherkkyttä (cache sensitivity) pyritään kehittämään. • kyselyjen optimoinnisessa otetaan huomioon keskusmuistin ominaisuuksia (erilaiset kustannusfunktiot kuin levytietojen yhteydessä)

6. Onko meillä varaa sijoittaa tiedot keskusmuistiin? Muistin hinta v. 2008 (€/GB) Parasta olisi saada mahdollisuus jakaa tietokannan keskusmuistin ja levyn välille nopeusvaatimusten ja kustannustekijöiden perusteella. Mooren laki puolijohdemuistiin sovellettuna: hinta puolittuu 24 kuukauden välein Nykyisin keskusmuistin koot ovat välillä 4 – 64 – 1TB

7. Mitä uutta keskusmuistipohjainen kanta tuo? SQL-kieli ja relaatiomallin tuki Uusi keskusmuistissa tapahtuvaa laskentaa huomioon ottava optimoija ! Kyselyjen optimointi, suoritus Parannettu rinnakkaisuudenhallinta vasteajan pienentämiseksi ! Rinnakkaisuudenhallinta ! Toipumisen varmistus Säädettävä transaktioiden pysyvyys Jaettu puskuri Uudet keskusmuistia varten optimoidut saantimenetelmät (indeksit) Saantimenetelmät ja levytoiminnot ! Väliotos (checkpoint) Transaktio- loki Tietokanta

8. Pullonkaulojen ratkominen • Tiedon haku keskusmuistista • Puskuri-herkkäät menetelmät • Rinnakkainen laskenta (SMP, multicore)- NUMA-arkkitehtuurissa toimiminen- Cache coherence -rasitus • Optimointimallit [LiNe96] • Optimoinnin tehokkuus • Väliotoksen teko • Pysyvyyden ylläpitäminen • Kannan käynnistäminen (restore)

9. 22 B-puun nerokkuus Levy-pohjainen B-puu Oletukset: • ryvästety indeksi (clustered index) • tietokantasivun koko: 8 KB • arvon ja osoittimen koko: 4B osoitin (avaimet  arvo) Alin (lehti-) solmu arvo Solmun koko: 8 KB Kuinka monta avain-osoitin paria? 45 65 96 … 1K 8K data- sivu 8K data- sivu 8K data- sivu 8K data- sivu 8K data- sivu Sivujen lkm.n = I K 8 MB tietokanta … Puun korkeus? Montako hipaisua? Entä, jos tietokannan koko kasvaa 1 K -kertaiseksi?  h= log1000n

10. B-puu: miksi huono keskusmuistissa? • Solmun sisääinen käsittely kallista solmun koon takia- selaus (scan) -- hidas- binäärihaku -- hankalaa, kun solmu pitää päivittää • Solmun koon mitoitus sivun koon mukaan täysin epäasiallinen keskusmuitissa  pitää lähteä siitä, että alkion haku maksaa saman verran paikasta riippumatta 1. vastaus: pienemmät solmut AVL-puunsomu 2. vastaus: Binääripuut arvo • Triviaali binääri puu: AVL-puu • Ongelma: huono tilan käyttöaste(arvon tila / osoittimien tila) 22 yläosoitin vasen osoitin oikea osoitin Puun korkeus: h= log2n

11. T-puu (T-tree) T-puu: binääripuu, jossa parempi tilankäyttö [LeCa86] K= solmun koko  100 47 33 95 22 45 65 96 … (osoittimet riveihin puuttuvat kuvasta) vasen osoitin oikea osoitin Puun korkeus: h<< log2n B-puu = ”bushy tree”T-puu = ”tall tree”

12. Onko kaikki muistipaikat samanarvoisia? keskusmuisti • Lähempänä olevat paikat ovat tehokkampia kuin muut L1-puskuri konflikti Direct-mapped cache (jokaiselle muistirivillä on puskurissa vakiopaikka) • Päätelmät: • taulukot ovat tehokkampia kuin osoitinpohjaisetrakenteet (int a[n] vai int* pa[n])(pre-fetching käytetään hyväkseen) • tiivistäminen on tärkeää 32 B muistijaksot (rivit)

13. 65 45 22 Onko B-puu sittenkin hyvä keskusmuistissa? • B-puun rakenteet voidaan tiivistää: poistaa osoittimet ja järjestää taulukoiksi • Esimerkki: CSB-puu (Cache-Sensitive B-tree) [RR00] Jos solmun koko olisi 32B (puskurin rivin koko) Perinteinen B-puu: 3 arvoa, 4 osoitinta h= log4nesim. log41M = 10 1 2 3 4 5 6 7 CSB-puu: 7 arvoa, 1 osoitinh= log7nesim log71M = 7 47 33 95 22 45 65 96 CC-node positio = solmutaulukon indeksi 0 1 22 33 solmun vakio koko = 32 B node group (solmujen taulukko) Muut tiivistyskeinot ovat myös mahdollisia

14. Trie-muisti (Trie Memory) Esim. 4-haaroutuva trie, avaimen pituus = 32bJaetaan 16 osaan (16 x 2b = 32b) Node capacity = 2b (fan-out=4), solidDB node capacity=8b (fan-out 256) • Tree: jako perustuu avainarvoihin • Trie: jako perustuu kirjoitusmerkkeihin (esim. numerot) [Fre60] f (fan-out) = 4 L (pituus) = 32Trie:n korkeus:h = L/ (log2f) = 16 - 00 11 11 01 11 Path compression(solmu ohitetaan, ellei ole valintaa) 01 10 01 Width compression(vain tarpeelliset osoittimet) tietue (row) 1110 Fast termination (ei ole muita arvoja, joissa etuliite ’0101’) Trie:n mielekkyys perustuu tiivistyvyyteen

15. Väliotos (checkpoint) • Mikä se on? • Tietokannan tilan talennus pysyvään muistiin (levylle) • Mitä varten se on? • Tietokanta voidaan elvyttää katkon jälkeen (cold start) • Miksi se on helppoa? • Levylle vaan • Miksi se on vaikeaa? • Miten varmistetaan otoseheys (snapshot consistency) käyttöä häiritsemättä?

16. Väliotoksen (checkpoint) menetelmät Vaatimus: väliotoksen teko ei saa lukittaa pois tietokantatoimintoja (non-blocking checkpoint) [SGM90] Ratkaisut esim. • sumea väliotos (fuzzy checkpoint)(kirjoitetaan myös likaisia sivuja,toipumisessa selvitellään ne lokin perusteella) • varjosivut (copy-on-write, shadow pages)(säilytetään eheitä sivuja) väliotoksen alku väliotoksen loppu likainen sivu + transaktioloki vahvistettu transaktio = sivun korjaus sivu (segmentti) likainen sivu (vanha)eheä kopio

17. Rivivarjomenetelmään perustuva väliotos (solidDB) [Liedes04] (Solidille tehty diplomityö) Vaatimukset • Rivien varjokopiot vapaassa muistissa • Sivut kootaan vain väliotoksen yhteydessä (levypuskuriin) • Väliotoksessa kaikki tarvittava tieto eheän tilan palauttamisesksi (ilman lokia), [LieWol06] (ICDE'06) • Ei-estävä (non-blocking) • Eheä ilman lokia • Ennustettava suoritusaika • Vähäinen muistin käyttö Ratkaisu

18. SivuP1 Sivu P1 Sivu P1 SIREN: väliotossivun muodostaminen rivit vapaassa muistissa otoksen alun hetki jäädytä sivu t0 t1 t2 Pending Add Update: t0 t1 t1' t2 Pending Add Pending Remove menee otokseen Commit: näkyvissä t0 t1 t1' t2

19. Pysyvyyden vaikutus suorituskykyyn Transaktion pysyvyys (transaction durability ”D”) Pysyvyyden vaatimus: kun transaktio on vahvistettu, transaktion tulokset eivät häviä missään olosuhteissa. • Pysyvyys varmistetaan ”redo”-lokin avulla • Perinteinen WAL-menetelmä (write-ahead-log):vahvistusta ei kuitata ennenkuin transaktio on kirjoitettupysyvästi lokiin (odotus: 20 ms?) • Optimointi: ryhmävahvistus (group commit)- vaikuttaa suorituskykyyn, ei vasteaikaan • Onko pakko kirjoittaa levylle? • Onko tiukka pysyvyys liian kova vaatimus?

20. Pysyvyystason säätö Eri sovelluksilla ja eri transaktioilla voi olla eri pysyvyysvaatimuksia. Tiukka pysyvyys (strict durability): COMMIT WORK käsky on synkroninen: kontrolli palaa ohjelmaan, kun transaktion tiedot ovat fyysisesti kirjoitettu levylle. Rento pysyvyys (relaxed durability): COMMIT WORK on asynkroninen: lokin kirjoitus suoritetaan taustalla Palvelin Transaktio- loki Palvelin Transaktio- loki Commit Commit OK OK Kova kirjoitus (write-thru, synchronous) Pehmeä kirjoitus (asynchronous) Tiukka loki Rento loki

21. Pysyvyyden ”delegointi” varayksikköön Korkeaan käytettävyden tietokantajärjestelmä Pääyksikkö(Active) Varayksikkö (Standby) Palvelin Transaktio- loki Palvelin Transaktioloki Commit Commit OK (kuittaus välittömästi) OK Pehmeä kirjoitus Rentoloki Rento loki Sanomien edestakainen viive Pehmeä kirjoitus Nykyisin lokin kirjoitus verkon yli on 10 kertaa nopeampi kuin levylle

22. Samassa prosessissa: suoraan linkitettyjä sovelluksia DBMS DBMS Sovellusarkkitehtuurin vaikutus suorituskykyyn Sovellukset eri prosesseissa: verkon tai prosessinvälisen kommunnikoinnin käyttö (verkkoasiakas) ARVIOINTI (+) nopeampi (-) virhealtis (-) sovellukset vaikea kehittää ja ylläpitää ARVIOINTI (+) turvallinen (+) joustava (-) hitaampi Ehdoton, jos halutaan kaikki keskusmuisti-kannan edut esille

23. Muita keskusmuistikannan erikoispiirteitä • Kallista! (muisti maksaa) • Yleensä haetaan nopeutta  käytetään muisti-intensiivisiä metodeja (esim. trie)  maksaa vielä enemmän. • Käynnistys on hidasta, koska koko kanta pitää alustaa keskusmuistissa väliotoksen pohjalta. • Indeksejä ei tallenneta (toisiotieto), joten ne pitää rakentaa alustuksen aikana  vielä hitaampa. • Alustusongelmien takia keskusmuistikannat käytetään usein korkean käytettävyyden kokoonpanoissa (joissa myös pysyvyyden takaaminen on helpompa).

24. In-Memory Database Application Profile What kind of application is a good fit for solidDB IMDB? • Need for speed: Latency or Throughput requirements • Data fits into RAM (a must) • Small transactions • Application does a lot of point lookups (according to a key value) • Table scans are not good for in-memory engine • No more than three table joins • No GROUP BY or ORDER BY for large result sets (thousands of rows) • Relaxed durability requirements • Can use asynchronous logging • HotStandby configuration (network based durability) • Can use READ COMMITTED isolation level

25. Pysyvä ja ei-pysyvä tieto(persistent and transient data) • Lisää suorituskykyetua voidaan saada luopumalla pysyvyysvaatimuksesta joidenkin tietojen osalta. • Lokia ei tarvitse kirjoittaa ei-pysyvien tietojen osalta. • Jos ei-pysyvät tiedot ovat jaetussa käytössä, rinnakkaisuudenhallinta on kuitenkin tarpeellinen. • Jos tiedon käyttö rajoituu yhteen käyttäjään, rinnakkaisuudenhallinta on tarpetonta.

26. How can you do 10x? • Main factors affecting solidDB query performance • query type and scope – best case is query to a single table, good if max 3 table join. • size of the result set (if client/server setup) – best case is when query returns a single row • selectivity of the search condition and used indices -- best case is unique key in all columns that contain a search condition • row size (number of columns and how much data is returned to the app) -- best case when resulting row size <1KB • Avoid GROUP BY, ORDER BY and aggregate functions • solidDB can be 10x faster than a disk-based database DB2/IDS/Oracle etc when all the above criteria are met

27. Perustuu Solid-tuotteilla tehtyihin testeihin Nopeusetuja (1) Satunnainen yhden rivin haku (autovahvistuksella)(suhteutettuna levypohjaiseen kantaan) Suorituskyky (rows/s) %

28. Perustuu Solid-tuotteilla tehtyihin testeihin Nopeusetuja (2) Päivitystoiminnot autovahvistuksella (AUTOCOMMIT) (suhteutettuna levypohjaiseen kantaan) Suorituskyky (rows/s) %

29. Maximum Performance Gain: IMDB vs. Disk DB(MME vs. DBE)

30. Responsetimeadvantage

31. solidDB: Latency and throughput on Intel Xeon 5570 (Nehalem) processor

32. Non-persistent (ei pysyvät) -taulut transienttables temporarytables M-tables Solid In-memory Relational Engine Boost Engine 4.0 solidDB6.0 Taulutyypit solidDB -tuotteessa Persistent (pysyvät) -taulut D-tables FlowEngine 3.7 solidDB on hybridituote: sisältää sekä levykannan että keskusmuistikannan tekniikkaa. Database Checkpoint and log

33. Ei-pysyvien taulujen yhteenveto • Temporary- ja Transient-taulut ovat ei-pysyviä (sisältö ei palaudu katkon tai vioittumisen jälkeen) • Kummankin kohdalla suorituskykyetu johtuu väliotoksen ja lokin tarpettomuudesta. • Kummankin taulutyypin metadata (taulujen määrittelyt) ovat pysyviä. • Transient Tables • sisältö on globaalisti näkyvissä ja voidaan jakaa samanaikaisten käyttäjien välillä(rinnakkaisuudenhallinta on käytössä) • Temporary Tables (SQL-99) • sisältö on vain yhden istunnon käytössä(rinnakkaisuudenhallintaa ei tarvita)

34. solidDB: keskusmuistitaulujen luonti • Persistent in-memory table (M-table) CREATE TABLE lines ( line_id INTEGER, type VARCHAR(80), status CHAR(8))STORE MEMORY; • Transient table CREATE TRANSIENT TABLE measurements ( meter_id INTEGER, timestmp TIMESTAMP, value REAL); • Temporary table CREATE TEMPORARY TABLE statistics ( line_id INTEGER, average_bps INTEGER); Luonnin jälkeen erityyppiset taulut voidaan käyttää samanvertaisina (viite-ehydessä on joitakin rajoituksia)

35. solidDB: pysyvyyden säätö • Taulukohtainen pysyvyystaso CREATE TABLE lines ( line_id INTEGER, type VARCHAR(80), status CHAR(8))DURABILITY RELAXED; • Istuntokohtainen psysvyystaso SET DURABILITY RELAXED; • Transaktiokohtainen pysyvyytaso SET TRANSACTION DURABILITY RELAXED;

36. Tuotekatsaus Tuotteen yleiskuvaus Erikois- ominaisuudet Sovelluksen liittäminen

37. Uudet haasteet • Rinnakkaisuudenhalinta ja monisäikeisyys haittana yksisäikeiset palvelimet? • Lokitoiminta haittana pysyvyyden takaaminen hajautuksen keinoin? • Skalautuvuus saavutettava hajautuksen turvin tietojen jakaminen, ei-synkroniset vahvistuskäytännöt • Prosessoripuskurin pullonkaula tulee vastaan tiivistäminen, tiivistäminen… • Järjestelmä on laajennettava, päivitettävä ja siirrettävä ilman käyttökatkoja ? ? ? Katso [Sto+07]

38. Database caching concepts • A partition is logical part of a database • Read-only partitions may have multiple copies (replicas) • Writable partitions may have only one replica • Writable partitions are disjoint Front-end 1 Front-end 2 Front-end 3 Writable partitionreplica Read-only partitionreplica Partition A Partition B Partition C Partition D Backend database

39. IBM solidDB Universal CacheFront-end solution for performance-critical data IBM solidDB Universal Cache App App App IBM solidDB App App App Two-wayasynchronousreplication (based on Changed Data Capture – CDC)

40. IBM solidDb Universal Cache:Typical replication modes between the front-ends and a back-end Front-end Applications N-way updatable replica solidDB solidDB solidDB 1-way updatable replica Read-only replica Front-end databases InfoSphere Change Data Capture (CDC) T2 Back-end database T1 T3 Backend Applications

41. Deployment (default) solidDB solidDB JDBC driver CDC for solidDB CDC Management Console Front-end CDC CDC management node JDBC driver Data server Back-end

42. Yhteenveto www.solidtech.com Kun keskusmuistin koko kasvaa ja muistin hinta laskee, tietokannan sijoittaminen keskusmuistiin tulee yhä ajankohtaiseksi. Tuotteet ovat jo olemassa.

43. Kirjallisuutta [GMS92] H. Garcia-Molina and K. Salem. Main Memory Database Systems: An Overview. IEEE Transactions on Knowledge and Data Engineering, Vol. 4, No. 6 (December 1992), pp. 509-516. [Fre60] Edward Fredkin: Trie Memory. CACM 1960 (3)9 (August 1960), pp. 490 - 499. [Jag+94] H.V. Jagadish, D. Lieuwen, R. Rastogi, A. Silberschatz, S. Sudarshan: Dali: A High Performance Main Memory Storage Manager. Proc. VLDB Conf. 1994, pp. 48-59. [LeCa86] Tobin J. Lehman, Michael J. Carey: A Study of Index Structures for Main Memory Database Management Systems. VLDB 1986: 294-303. [Liedes04] Antti-Pekka Liedes. Checkpointing a Main-Memory Database. Diplomityö, TKK, 2004. [LieWol06] Antti-Pekka Liedes and Antoni Wolski. SIREN: a memory-conserving, snapshot-consistent checkpoint algorithm for in-memory databases. Proc. International Conference on Data Engineering (ICDE'06), April 3-7, 2006, Atlanta, U.S.A. [LiNe96] Sherry Listgarten, Marie-Anne Neimat: Modelling Costs for a MM-DBMS. RTDB 1996: 72-78. [SGM90]Kenneth Salem, Hector Garcia-Molina: System M: A Transaction Processing Testbed for Memory Resident Data. TKDE 2(1): 161-172 (1990) [Sto+07] Michael Stonebraker, Samuel Madden, Daniel J. Abadi, Stavros Harizopoulos, Nabil Hachem, Pat Helland: The End of an Architectural Era (It’s Time for a Complete Rewrite). VLDB 2007 Conference, Vienna, September 23-27 2007. [Raa03] Vilho Raatikka: Cache-Conscious Index Structures for Main-Memory Databases. Msc. Thesis, University of Helsinki, 2003.http://www.cs.helsinki.fi/u/raatikka/Gradu/Gradu.pdf [RaRo00] Jun Rao, Kenneth A. Ross: Making B+-Trees Cache Conscious in Main Memory. SIGMOD Conference 2000: 475-486.