Uber i databaseskift: Har droppet PostgreSQL og skiftet til MySQL

PostgreSQL gav problemer med ydelsen, når data skulle ligge på SSD'er, og der skulle være kopier af databasen tilgængelige.

Uber har gennem de sidste par år arbejdet på at skifte fra én open source database til en anden. Nærmere bestemt fra PostgreSQL til MySQL med Ubers egetudviklede lag, der skulle hjælpe med skalering.

Uber-udvikler Evan Klitzke skriver i et blogindlæg, hvordan PostgreSQL voldte problemer for den måde, Uber gerne ville håndtere databasen på.

Problemet med PostgreSQL er ifølge Uber-udviklerne, den måde ændringer i en tabel gemmes på i databasen. Det sker ikke som en egentlig opdatering af en tuple i tabellen, men ved at tilføje en ny tuple med et nyt id.

Det betyder, at der skal laves flere fysiske dataoperationer, som kan være kostbare på et SSD-lagermedie, i forhold til blot en simpel opdatering.

Tilsvarende skal ændringerne også kommunikeres ud til kopier af databasen som egentlige ændringer af, hvor data fysisk ligger på en disk, og det koster netværkskapacitet. Det bliver især et problem, når databasen skal replikeres mellem flere datacentre, der ligger geografisk spredt.

Uber har også haft problemer med, at de replikerede versioner af databasen har været låst på grund af igangværende transaktioner, og hvis de har taget for lang tid, risikerer de et timeout, og det kan svært for udviklerne at tage hensyn til.

Uber benytter databasemotoren InnoDB til MySQL. Databasen er mindre effektiv til visse typer opslag, men løser til gengæld nogle af de problemer, Uber har haft med PostgreSQL.

Derudover har Uber lagt selskabets eget lag oven på, kaldet Schemaless. Det er primært et projekt, der er kommet til verden, fordi alternativer som Cassandra eller MongoDB ikke havde alle de funktioner, Uber efterspurgte til et skalerbart og fejlsikret system.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Martin Jünckow

Meget spændt på om de bliver mere glade for MySql.

Jeg har arbejdet med MySql på et databaseprojekt i terabyte-klassen og hvorom MySql nok er en af de mest brugervenlige databaser med et af de bedste administreringsværktøjer i form af den relancerede MySql Workbench, så kan det samme altså desværre ikke siges om hverken innodb eller MyISAM (Som problematisk nok stadig benyttes til alle system databaser).

Min erfaring er at MySQL ikke fuldt lever op til ACID kravene og at det oftere går galt med MySQL så den skal restores fra backup end tilfældet er med andre professionelle databaser - herunder PostGreSql.

Desuden lider den også under alvorlige performance-problemer og en query optimizer der formentlig er den mest handicappede på markedet - mit gæt er at Uber vil komme til at opleve at flaskehalsene blot har flyttet sig ved at skifte væk fra PostGreSql.

  • 7
  • 1
Troels Henriksen

Så vidt jeg kan se bruger de mest af alt MySQL som en dum spand bits, som de så bygger deres egen egentlige grænseflade ovenpå - antageligvis også med bedre robusthedsegenskaber. Jeg husker noget med at Google også gjorde det på denne måde engang.

  • 2
  • 0
Martin Kristiansen

Jeg har arbejdet med MySql på et databaseprojekt i terabyte-klassen og hvorom MySql nok er en af de mest brugervenlige databaser med et af de bedste administreringsværktøjer i form af den relancerede MySql Workbench, så kan det samme altså desværre ikke siges om hverken innodb eller MyISAM (Som problematisk nok stadig benyttes til alle system databaser).

Det har jeg også prøvet, en DB der voksede med 7GB/dag over 18 måneder, - og rendt ind i begrænsningerne med mysqldump. Løsningen er MySQL Enterprise Backup, der ikke er gratis. Det laver backup af den underliggende InnoDB storage engine, uden om MySQL.

MyISAM burde være fjernet for år tilbage, der er intet pænt at sige om det.

Min erfaring er at MySQL ikke fuldt lever op til ACID kravene og at det oftere går galt med MySQL så den skal restores fra backup end tilfældet er med andre professionelle databaser - herunder PostGreSql.

Hvilke ACID krav honoreres ikke ? Hvis man ikke roder med transaction concurrency mode burde ACID kravene være opfyldt.

Mht. crashes på InnoDB. Jeg har ikke oplevet et alvorligt et endnu (efter 10+ års brug). MyISAM crasher hele tiden.

Desuden lider den også under alvorlige performance-problemer og en query optimizer der formentlig er den mest handicappede på markedet - mit gæt er at Uber vil komme til at opleve at flaskehalsene blot har flyttet sig ved at skifte væk fra PostGreSql.

Det er vigtigt at kende MySQL's begrænsninger. Query udføres som nestede loops ved at læse én tabel ad gangen (i en query med flere tabeller joinet sammen). Hver loop laver sit eget temporære resultat (intern tabel), der så bruges til at query den neste med.

Her hjælper PostGres f.eks med at lave temporære hash lookup-tabeller der så er med til at filtrere resultatet når en tabel spørges. Det giver nogle gange en faktor 3-10 forskel i performance, per join.

Et andet problem med MySQL er at query planneren, der bestemmer rækkefølgen af tabeller, gør det ud fra et gæt om kardinaliteten af kandidat-indices. Gættet udføres ved at tage stikprøver i et indeks for at fastslå kardinalitet. Default er ti stikprøver; Det virker normalt fint for enkelt-kolonne indices, men er slet ikke fyldestgørende for indices lavet over flere kolonner. MySQL sorterer rækkefølgen af tabeller efter kardinalitet på kandidat indices, med højeste først. Hvis rækkefølgen skifter kan du gå fra at have en query, der tager 10ms til en der tager én dag !! Dette er ikke unikt for MySQL, jeg har også oplevet det på Oracle, men ikke nær så ofte.

Heldigvis kan man siden 5.5 hæve antallet af samples. Det bør man gøre, da disse samples ikke foretages ret tit og er næsten gratis. Jeg bruger 100 samples i alle mine MySQL installationer.

Query optimizeren er også "dum". Den laver en udtømmende søgning af bedste rækkefølge af joinede tabeller. Det betyder at hver gang du tilføjer en tabel-join så fordobler du optimizerens arbejde.

DERFOR skal du hjælpe MySQL. Strukturér dine queries med subqueries, der så joines sammen. Så reducerer du chancen for at query planneren roder rundt i tabellerne, og du reducerer også arbejdet med at finde optimal query-plan. Hvis kan omskrive en join mellem 12 tabeller med omkostning 2^12 (4096), til en join mellem fire subqueries hver med 3 tabeller, så er omkostningen ca 4*2^3+2^4 (40). Derudover: brug prepared statements, hvor query plan genbruges fra query til query.

Fordelen ved at bruge MySQL/MariaDB er at det er relativt let at skalere til flere maskiner med master-master replikering (Facebook !)

  • 4
  • 0
Martin Jünckow

Vi oplevede nedbrud ca. hvert halve år, men vi skrev også ~100 GB data/dagen, så det er tænkeligt vi lidt oftere rendte ind i nogle problemer andre måske ikke ville opleve selv over 10 år. Men det var nu egentlig ikke for at starte en større tråd om MySqls ulyksageligheder.

Mit personlige indtryk er blot at PostgreSql på mange måder er en mere moden og enterprise rettet database og jeg ville umiddelbart have svært ved at anbefale MySql til ret meget professionel brug, omend jeg udmærket er klar over den anvendes til mangt og meget.

Jeg ved at større firmaer som google kører deres egne custom builds af MySQL der er tilpasset og optimeret til lige præcis deres formål, men det er et lidt andet scenarie end hvordan de fleste andre anvender MySql og deres success med det finder jeg derfor svært sammenligneligt.

  • 2
  • 0
Lars Nielsen

Blandt andet slitage af SSD'er, som jeg har forstaaet det saa er leve tiden paa SSD'er stadig ikke paa hoejde med HDD'er. Derfor ville en SSD i et storage system hurtiger blive slidt og derved ville der hurtiger opstaa et behov for at skifte disse. Men det kan godt vaere jeg er helt galt paa den. Hardware er ikke min store force

  • 0
  • 1
Log ind eller Opret konto for at kommentere