Keskusmuistipohjaiset tietokannat Antoni Wolski Chief Researcher, solidDB IBM Helsinki Lab Software Group DB2YTR Heksinki, 2010-05-04

Sisältö Pääkysymykset: Miksi? Miten? Miksi helppoa? Miksi vaikeaa? 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

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

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

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

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

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 ! Tietokanta Väliotos (checkpoint) Transaktio- loki

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)

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

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-puun somu 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

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

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

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) 22 45 65 Perinteinen B-puu: 3 arvoa, 4 osoitinta h= log4n esim. log41M = 10 1 2 3 4 5 6 7 CSB-puu: 7 arvoa, 1 osoitin h= log7n esim log71M = 7 22 33 45 47 65 95 96 CC-node positio = solmutaulukon indeksi 1 22 33 solmun vakio koko = 32 B node group (solmujen taulukko) Muut tiivistyskeinot ovat myös mahdollisia

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

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

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

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

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

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 kirjoitettu pysyvästi lokiin (odotus: 20 ms?) Optimointi: ryhmävahvistus (group commit) - vaikuttaa suorituskykyyn, ei vasteaikaan Onko pakko kirjoittaa levylle? Onko tiukka pysyvyys liian kova vaatimus?

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

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 Rento loki Sanomien edestakainen viive Rento loki Pehmeä kirjoitus Nykyisin lokin kirjoitus verkon yli on 10 kertaa nopeampi kuin levylle

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

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

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 You want to use in-memory database if disk-based databases don’t provide enough performance Optimized for point look-ups according to an indexed column, table scans are slow Join algorithms don’t work well with more than three tables Disk is bottle neck if strict logging is used With read committed isolation level writes don’t lock rows exclusively

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.

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 Examples – from Tommi With Tradeweb the average query returns dozens or even hundreds of rows. Moving those rows to the application takes the majority of the time and we cannot speed up the physical transfer of data over the network. With Choice the distribution of values for the columns used in the where clause is not very selective. It's a two table join (which is okay) where the first part of the join returns 8% of the rows from a 100,000 rows table, i.e. about 8000 rows and only the second part of the join cuts it down to about 10 rows which are then returned to the app. In client/server setup that first part of the join which returns 8% of the table negates most of the solidDB advantage. That's why we are "only" 2x faster in the client/server setup. But even if 1, 2 and 3 are perfect match it won't help much if the rowsize is 30kB. In that case again the physical transfer of the data will overwhelm the query time and we are not going to be much faster than a disk-based database. Now 6.5 will change this somewhat as the "Shared Memory Access" really speeds up the actual physical transfer of the rows. So if the customer has a case where the application and the database will be physically co-located then #2 and #4 don't matter that much. Like with Choice solidDB 6.4 is 5x faster than IDS. (If the first part of the join returned only a single row, we would be 10x faster..) And these same factors also apply to inserts,updates and deletes. We can give a big boost to applications that do a lot of concurrent single row updates/deletes/inserts. (if the application doesn't require strict durability or can run in HSB setup). But solidDB won't help much if you update/delete hundreds of rows with a single statement..

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

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

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

Response time advantage

solidDB: Latency and throughput on Intel Xeon 5570 (Nehalem) processor Summary: solidDB response times TATP v. 1.0.2 Date: 2009-04-27 Products: Comments: solidDB 6.1.0014 6.1 GA solidDB 6.3.0029 6.3 Fix Pack 1 Platform: 2xCPU Intel Nehalem Xeon 5570 @ 2.93GHz, total 8 cores Cache per core: L1:32KB, L2: 256KB, L3:8MB MM:18GB, Disk: RAID0 (x3), OS: SLES 10 SP2 64bit Load configuration: linked library access (Accelerator, statically linked) Database settings: Engine: MME Isolation: Read Commited Checkpoint interval: 3 min Durability: Relaxed TM1 settings: Population: 1M Subscribers (1.5 GB brutto) Ramp-up time: 1 min Sampling: 3 min Load mix:R80W20 Clients: 1-128 (

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

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)

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)

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;

Tuotekatsaus Tuotteen yleiskuvaus Sovelluksen liittäminen Erikois- ominaisuudet Oracle TimesTen (In-memory Data Manager) Keskusmuistikanta Keskitason käytettävyys Kohdeala: telekomm. - suora linkitys (- verkon yli) - SQL - rinnakkainen sovellusten linkittäminen Polyhedra, OSE Kohdeala: automaatio - verkon yli (SQL+oma API) - suora linkitys (oma API) - kehittynyt laukaisin-järjestelmä - oma kieli Sun (Clustra HA-DB) Korkea käytettävyys Kohdeala: telekomm - verkon yli - SQL + oma API - pysyvyyden delegointi verkossa MySQL Cluster (NDB Cluster) - oma API + SQL IBM solidDB In-Memory Database Hybridituote Kohdealat: telekomm., telematiikka, sulautetut j. - hybridituote - pysyvyyden säätö ja delegointi verkossa

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]

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 partition replica Read-only partition replica Partition A Partition B Partition C Partition D Backend database

IBM solidDB Universal Cache IBM solidDB Universal Cache Front-end solution for performance-critical data IBM solidDB Universal Cache App App App IBM solidDB App App App Two-way asynchronous replication (based on Changed Data Capture – CDC)

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 T1 T3 Back-end database Backend Applications

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

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

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.