allan ebdrup bloghoved ny

Indtryk fra MongoDB World i New York

Jeg var så heldig at være en af de over 1.000 deltagere til MongoDB World den 23-25. juni på Manhattan i New York. For at starte med konklusionen, så var de den bedste teknologi-konference, jeg nogensinde har været til.

Ja, starten på konferencen blev udskudt, fordi der var flaskehalse i registreringen af deltagere. Jeg måtte stå op til nogle af foredragene, fordi arrangørerne havde forregnet sig i hvor populære foredragene ville være. Maden var ikke prangende. Wifi var en smule ustabil til tider. Udstillingsområdet var ikke særligt interessant og hotellet var dyrt.

Alligevel var det en fantastisk konference, for jeg lærte en hel masse brugbart. Jeg fik også mange nye MongoDB-"venner".

Startede med kursus

Jeg startede en dag tidligere end selve konferencen med klasse-undervisning. Kurset var Advanced Data Modelling.

MongoDB har et ret begrænset udvalg af kurser. Til gengæld er materialet godt gennemarbejdet og det er baseret på MongoDB-konsulenters og MongoDB-kunders praktiske erfaringer. Kurset var meget relevant for mig og jeg lærte en masse, som jeg kan bruge i mit daglige arbejde med MongoDB.

Det første jeg gjorde da jeg kom hjem, var at anvende min nye viden til optimering af mit fritidsprojekt. Mit fritidsprojekt laver mellem 200 og 2.000 Mongo-operationer i sekundet, døgnet rundt. Efter et par dages arbejde performer det cirka dobbelt så godt som før. Jeg kan meget klart anbefale MongoDBs undervisning, til alle der overvejer MongoDB, eller som allerede er i gang med MongoDB.

Konference

Selve konferencen var tilrettelagt med keynotes og ellers hele 6 parallelle spor, med talks på 40 minutter. Så det var kun en brøkdel af foredragene jeg hørte.

Jeg brugte halvdelen af tiden på MongoDB-internals, om hvordan MongoDB virker "inde i maven", og den anden halvdel på foredrag holdt af folk med praktiske erfaringer med MongoDB. Kvaliteten af foredragene var høj. Der var kun et enkelt foredrag af alle dem jeg var til, hvor foredragsholderen faldt igennem.

Oploggen

En af de ting jeg havde set meget frem til, var at lære mere om oploggen. Oploggen, eller operations-loggen, er den mekanisme MongoDB bruger til replikering til secondaries eller read-slaves. Det minder lidt om transaktions-loggen og log-shipping i traditionelle relationelle databaser. Men til forskel for mere traditionelle transaction-logs, der som regel er noget, der foregår forholdsvis aflukket og low-level i maven på databasen, så er oploggen i MongoDB bare en helt almindelig capped collection. Den er magen til de capped collections, du selv kan lave.

Alle opdateringer der laves på primary/master-serveren skrives ned i oploggen, som helt almindelige MongoDB-dokumenter. Et dokument i oploggen beskriver enten en indsættelse, en opdatering eller en sletning af et enkelt dokument.

Secondaries, eller read-slaves, i dit MongoDB replica-set, tail'er så bare oploggen, som man kan gøre med enhver capped collection i MongoDB, og afspiller opdateringerne lokalt for at synkronisere data. Secondaries laver bare de indsæt/opdater/slet-operationer som oploggen beskriver, at der er blevet lavet på primary/master-serveren.

Det smarte er, at det er meget nemt at starte sin egen process der tail'er oploggen. Det var der en del foredragsholdere, der havde brugt til ret forskellige ting.

Jon Hoffman fra Foursquare fortalte om, hvordan de bruger tailing af oploggen til at flytte collections mellem fysiske servere, live i produktion, mens applikationen kører videre. Det svarer lidt til at flytte tabeller i en relationel database fra en databaseserver til en anden, mens systemet er online. Foursquare flytter collections, for at skalere ud på flere maskiner, og for at opdele deres applikation for at gøre udviklings-processen mere strømlinet.

Evan Broder fra Stripe fortalte om, hvordan de bruger tailing af oploggen dels som et slags pub/sub event-system, dels til at live-replikere til både elastisearch, HBase og PostgreSQL.

Og MongoDB selv annoncerede MongoDB Backup, som en del af deres MMS-service. MongoDB Backup tail'er oploggen til backup, så du får point-in-time recovery. Det vil sige en backup-mekanisme, hvor du kan få et dump af databasen, som den så ud i går klokken 10, eller i forgårs klokken 16, osv. Samtidig belaster backup-processen stort set ikke produktionssystemet.

Hos e-conomic på debitoor.com, som jeg arbejder på, ville det være oplagt for os at bruge tailing af oploggen til at seperere rapport-genererings-workloadet fra den almindelige brug af databasen. Noget, vi hele tiden har vidst, vi skulle gøre efterhånden som systemet vokser. Nu har vi bare fået en nem måde at gøre det på.

Fremtiden for MongoDB

MongoDB har ry for at give udviklerne, der bruger MongoDB, de features som udviklerne beder om (også selv om det er teknisk hul i hovedet at give dem det, vil nogen af konkurrenterne sige).

I den ægte MongoDB-ånd sluttede MongoDBs CTO Eliot Horowitz af med at fortælle om en række features, som MongoDB overvejer at implementere. Så kunne vi ellers allesammen bruge de udelte sedler, til at afgive vores stemme på nye features og give feedback til MongoDB. Personligt kunne jeg godt lide at se multi-document-transactions på listen.

Som sagt var det en fantastisk konference. Jeg lærte meget andet end jeg har skrevet om her. Jeg forlod konferencen endnu mere tilfreds med vores valg af MongoDB. Fremtiden ser i min optik lys ud for MongoDB. Men husk: Vælg altid den rigtige database til den opgave du står overfor.

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jesper Louis Andersen

Relevant læsning for alle der drifter et MongoDB cluster: http://aphyr.com/posts/284-call-me-maybe-mongodb (Ja, artiklen er mere end et år gammel, ja, flere af problemerne er mig bekendt stadigvæk meget aktuelle.)

Kyle Kingsbury har rigtigt mange gode pointer i samtlige af hans blogposts. Det er ret vigtigt at kigge i dem før man vælger et databaseprodukt. Hvis jeg skulle vælge et system i dag til udvikling, ville jeg helt klart vælge Postgres 9.4. De har en ny jsonb type så du kan have "MongoDB i en søjle". I øvrigt outperformer de så også lige MongoDB i query speed :) Og du kan så stille og roligt migrere dine data over i andre søjler når det bliver nødvendigt med lidt mere struktur over data. Og de taber ikke data under partitions :)

Desuden laver Postgres også PITR backup, og har gjort det i årevis. Det er en rar ting.

Det MongoDB gør bedre end alle andre er at de virkeligt gør meget ud af deres Driver-interface i gængse sprog. Og det kan i høj grad mærkes.

  • 0
  • 0
Allan Ebdrup Blogger

Er det muligt at uddybe hvad du har gjort for at det performer cirka dobbelt så godt som før?

Jeg gjorde flere ting:

  • Jeg erstattede nogle findAndModify kommandoer med først en update og så en find. Det kan give forbedringer da findAndModify ikke kan yield'e mens den har sin lås. (til gengæld mister du noget concurrency-sikkerhed, så pas på med race conditions hvis du gør det)
  • Ydermere gav det mig mulighed for at lade være med at hente hele dokumentet efter opdateringen (jeg brugte new:true i findAndModify). I stedet henter jeg kun præcis de properties jeg har brug for, som er en del færre end hele dokumentet (jeg indførte et par ekstra properties for at gøre det mere effektivt).
  • Og så lavede jeg noget oprydning, som man altid gør når man rører ved kode.

Jeg mangler stadig at finpudse min optimering der laver bulk updates. Det skulle reducere netværkstrafikken.

Og jeg mangler også at lave en optimering af min dokumentstruktur. Når MongoDB leder i BSON dokumentet efter en property, kan det bedst betale sig at have et hieraki, uden alt for mange properties på hvert niveau, da søgningen så går hurtigere. Lige nu har jeg nogle dokumenter med en meget flad struktur og rigtig mange properties på top-niveau i roden af dokumentet.

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