The talk I gave about CouchDB at 3 Oct, 2009, at the Hungarian Web Conference. Slides are in Hungarian

1. A WEBRE TERMETT
ADATBÁZIS

2. ÉRDI BÁLINT
(ruby) web developer
@baaz
http://bucionrails.com

3. “Django may be built for the Web, but
CouchDB is built of the Web. I’ve never seen
software that so completely embraces the
philosophies behind HTTP.”
Jacob Kaplan-Moss, a Django egyik megalkotója

4. DOKUMENTUM ALAPÚ

5. SÉMA NÉLKÜLI

6. ELOSZTOTT

7. HIBATŰRŐ

8. SKÁLÁZHATÓ

9. RESTFUL HTTP/JSON API

10. minnesotaindependent.com
KOOL!

11. KÖSZÖNÖM.
KÉRDÉSEK?

12. ÁTTEKINTÉS
• Történet
• CouchDB, mint DB
• fő tulajdonságok
• adatbázis kezelés (elvek és gyakorlat)
• teljesítmény avagy “a színes oszlopokat akarom”
• CouchDB mint standalone application

13. TÖRTÉNET
• Damien Katz hobbiprojektje
• Apache open source projekt (2008-)
• Erlang: funkcionális, konkurrens
• 0.10.0

14. COUCHDB, MINT DB

15. DOKUMENTUM ALAPÚ
• rekordok helyett dokumentumok
• “evolving, self-contained documents”
• JSON
• típusok: minden, ami valid JSON
• inkrementált id helyett UUID (universally unique)

16. {
“_id” : “BE2298A127D”,
“_rev” : “2-5d0319b075a”,
“type” : “book”,
“title” : “CouchDB: The definitive
guide”,
“authors” :
[“J. Chris Anderson”, “Jan
Lehnardt”, “Noah Slater”],
“published_year”: 2009,
“categories” : [“db”, “web”]
}

17. {
“_id” : “BE2298A127D”,
“_rev” : “2-5d0319b075a”,
“type” : “book”,
“title” : “CouchDB: The definitive
guide”,
“authors” :
[“J. Chris Anderson”, “Jan
Lehnardt”, “Noah Slater”],
“published_year”: 2009,
“categories” : [“db”, “web”]
}

18. SÉMA NÉLKÜLI
• Az igazi világ nem (mindig) sematikus
• nem kell előre tervezni
• nincs szükség migrációra
• ugyanaz a típus != ugyanaz a séma

19. ELOSZTOTT, HIBATŰRŐ
• clustering replikáció segítségével
• “crash-only design”
• nincs shut-down process, egyszerűen csak terminál
• nincs felülírás, mindig csak a db file végére ír
• write & commit (két fázisban)
• nem kell consistency-check v. fix-up újraindításkor

20. HTTP API
• minden adatbázisműveletre
• adatbázis létrehozás és törlés
• dokumentum létrehozás és lekérés (view query)
• kliensek: curl, wget, FF, Safari, stb. :)
• “webre termett”

21. CREATE: PUT http://localhost:5984/webkonf/
couchdb_eloadas -d {‘title’: ...}
READ: GET http://localhost:5984/webkonf/
couchdb_eloadas
UPDATE: PUT http://localhost:5984/webkonf/
couchdb_eloadas -d {‘title’: ...}
DELETE: DELETE http://localhost:5984/webkonf/
couchdb_eloadas?rev=...

22. CAP
• Consistency: Minden kliens ugyanazt az adatot látja
• Availability: Minden kliens megkapja az adat valamelyik verzióját
• Partition tolerance: Az adatbázis szétosztható több szerverre

23. CAP ELV: VÁLASSZ 2-T

24. “Each node in a system should be able to make
decisions purely based on local state. If you
need to do something under high load with
failures occurring and you need to reach
agreement, you’re lost…”
Werner Vogels, Amazon CTO and Vice President

25. AVAILABILITY >
CONSISTENCY
• nagy forgalmú, elosztott rendszereknél életbevágó
• minden adat megvan a node-on
• minden kérés rögtön megkapja a dok. valamely verzióját
• replikáció után konzisztens (“eventual consistency”)

26. HOGYAN? MVCC
• Multi Version Concurrency Control
• minden íráskor új verzió keletkezik
• az írás alatt beérkező olvasások a régi verziót kapják meg
•a CouchDB a _rev mezőt automatikusan növeli
• írás csak a legutolsó _rev átadásával lehetséges

27. CONFLICT MANAGEMENT
• u. azon dokumentum két helyen változik meg
• két verzió keletkezik
• replikációkor konfliktus (_conflicts mező)
• determinisztikus nyertes
• az app feladata a konfliktus feloldása

28. ADATTÁROLÁS
• B-treeben
•1 B-tree / adatbázis
•1 B-tree / view
• DocId-vel indexelve
• Query key-jel v. key range-dzsel nagyon gyors: O(log N)

29. ADATTÁROLÁS 2.
• nincs felül-, csak hozzáírás (“append-only”)
• compaction: a régi verziókat lenyesi

30. DESIGN DOKUMENTUM
• nem adatot, design elemeket tárol
• view-k, show és list functionök, stb.
• mindenben megegyezik az “adatdokumentumokkal”
• lehet több is egy adatbázisban

31. REPLIKÁCIÓ
• adat szinkronizáció módja
• két adatbázis között
• inkrementális: csak az új ill. módosult dokumentumok
replikálódnak
• mindig egyirányú (source és target)
• indított és folyamatos (>= 0.10.0) replikáció

32. VALIDÁCIÓ
•a régi dok., az új dok. és a user alapján
• true : mehet, false v. raise: nem
• alkalmas hozzáférés kezelésre is

33. LEKÉRDEZÉS
• csak view-kon keresztül
• view: map + reduce funkciópár
• indexelt (B-treeben)
• javascript
• kevésbé flexibilis, mint az SQL, de indexelt
•a view a design dokumentumban tárolódik

34. MAP
• először minden dokumentumon végigmegy
• utána csak dok. változáskor fut le
• mindegyikhez 0..n key-value párt generál a view-ban
•a kimenet key szerint rendezve van!

35. function map(doc) {
if ( doc.type == “book” ) {
if ( doc.title ) {
emit(doc.title, doc)
}
}
}

36. REDUCE
• opcionális
• aggregáló funkció
• inputja lehet
•a Map által generált sor
• előző reduce által generált sor (rereduce)

37. function reduce (keys, values,
rereduce) {
if (rereduce) {
return sum(values);
} else {
return values.length;
}
}

38. QUERY PARAMÉTEREK
•= http query paraméterek :)
• key
• startkey, endkey
• group, group_level
• reduce
• descending

39. www.graphicshunt.com
HÁNY REQ/S, HÁNY REQ/S?

40. TELJESÍTMÉNY
• hangsúly a megbízhatóságon és a concurrency-n
• megbízhatóság vs. req/s
• “fast enough”

41. “The ab (apache bench) utility has (or had at
the time) a hardcoded limit of 20000
concurrent connections. CouchDB didn't
sweat when ab started failing”
Jan Lehnardt, CouchDB team

42. BENCHMARKING
• nehéz
• reprodukálhatónak kell lennie
•a kontextus is fontos
• standard benchmark hiánya

44. STANDALONE APP

45. “COUCHAPP”
• web szerver + document database
• html és js file attachmentek a design dochoz
• Javascript-tel lehet kommunikálni a szerverrel
• offline mód megoldva
• deployment = replikáció
• shareable apps!

46. P2P WEB: A JÖVŐ ZENÉJE?
• minden eszközön (laptop, mobil, stb.) fut egy CouchDB
szerver
• replikáció a peerek között
•a design dok. (view-k, list functionök, validációk) is replikálódik
• push és pull
• Ubuntu következő verziójában (Karmic Koala) alapból lesz

48. SHOW FUNCTIONS
•a JSON dokumentumokat más Content-type-re konvertálja
• input: a dok. és a Content-type
• ETag support

49. LIST FUNCTIONS
•a view kimenetét konvertálja
• bármely view-val futtathatóak
• input: meta-információ (“head”) és a request
• pl. feed-ek előállítására

50. SHOW, LIST, VIEW FUNCTIONS
• nem érhet el külső resource-okat (ismételhető)
• side-effect mentes (nem írhat a DB-be, nem indíthat process-
eket, stb.)
• cache-elhető
• egyfunctiont egy dokra csak egyszer kell lekérdezni, utána
cache-ből!

51. BIZTONSÁG
• beépített cookie-alapú autentikáció (_session)
• admin account-ok
• dok.-hoz tartozó reader lista
• proxy server-rel az API tetszőleges része elrejthető

52. COUCHAPP-EK
• Futon, a CouchDB admin interface-e
• Nymphormation: http://nymphormation.org/
• Boom Amazing: http://github.com/langalex/boom_amazing
• Swinger: http://github.com/quirkey/swinger
• Real-timegroup calendar: http://jchrisa.net/cal/_design/cal/
index.html
• CouchDB twitter client: http://github.com/jchris/couchdb-
twitter-client

53. KÖSZÖNÖM, KÉRDÉSEK?