Warum 'ne Datenbank, wenn wir Elasticsearch haben?

3 399 vues

Publié le

Developer Conference Hamburg 2013

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 399
Sur SlideShare
0
Issues des intégrations
0
Intégrations
68
Actions
Partages
0
Téléchargements
39
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Warum 'ne Datenbank, wenn wir Elasticsearch haben?

  1. 1. Warum ‘ne Datenbank, wenn wir Elasticsearch haben? @jodok #dchh
  2. 2. @jodok @cratedb @lovelysystems
  3. 3. Was macht ‘ne Datenbank? 1. Dokumente speichern 2. Binäre Objekte speichern 3. … wieder finden/lesen 4. … analysieren 5. … wieder verändern
  4. 4. Wie macht man das bei einer großen Datenmenge? MongoDB (1., 3., 4., 5.?) + Elasticsearch (3.) + GridFS (2) ! Riak (1., 3., 4.?, 5.?) + Solr (3.) + Rados (2) ! CouchDB (1., 4) + Elasticsearch (3.) + HDFS (2.) + Hadoop (4., 5.)
  5. 5. Einfach zu benutzen, zu skalieren, zu betreiben
  6. 6. Elasticsearch einfach geil
  7. 7. Einfach toll… (nicht nur search) • Echtzeit-Suche • Volltext Suche • Verteilt • • Hoch verfügbar Versions Konfliktbehebung • Restful API • Mandantenfähig
  8. 8. Und nu’?
  9. 9. • • • • • • Sicherheitsmodell? Transaktionen? Datensicherheit? Reifegrad der Werkzeuge? Große Berechnungen? Verfügbarkeit der Daten?
  10. 10. Was macht die Datenhaltung? … but also inspired by Nathan Marz
  11. 11. ACID • Atomicity - alles oder nichts • Das ist zuuu vieeel, speziell bei verteilten Knoten. • Consistency - nur gültige/valide Daten werden gespeichert • Ausfälle? Zuverlässigkeit? Mehrere Server! • Hohe Anzahl von parallelen Lese- und Schreibzugriffe? • Diese Algorithmen sind nicht für verteile Umgebungen gemacht und zu langsam. • • Isolation - sich so verhalten, als ob alle Transaktionen seriell passieren und die Daten korrekt sind Durability - ich lese genau das, was ich geschrieben habe
  12. 12. Jeder, der große Applikationen baut, setzt auf CAP und BASE.
  13. 13. BASE & CAP • Basically Available - das System gibt immer eine Antwort • Soft State - es muss nicht jederzeit konsistent sein. • Eventually Consistent zu einem späteren Zeitpunk wird es konsistent http://bigdatanerd.files.wordpress.com/2011/12/cap-theorem.jpg
  14. 14. Genau! Wir brauchen einen Key/Value store! PUT GET
  15. 15. Nicht ganz…
  16. 16. Anfrage = Funktion(Alle Daten) • Manchmal geht es darum, gespeicherte Informationen wieder abzurufen • Meistens werden jedoch Transformationen, Aggregationen und andere Funktionen benötigt. • z.B. die Anzahl von Seitenaufrufen einer speziellen URL über einen gewissen Zeitraum
  17. 17. Strukturierte Daten?
  18. 18. Schemas • Schwierig zu ändern • “Sind im weg”, stören • Generieren Zusatzaufwand für den Entwickler • Es nervt, im Voraus Informationen festzulegen Nathan Marz: 
 http://www.slideshare.net/nathanmarz/runaway-complexity-in-big-data-and-a-plan-to-stop-it
  19. 19. Genau! Lass uns eine schemalose NoSQL Datenbank benutzen!
  20. 20. Das ist eine Überreaktion
  21. 21. Bitte folgert nicht von der ! schlechten Umsetzung! ! von Schemas auf den ! Zusatzwert, ! den Schemas erzeugen!
  22. 22. Funktion(Datenmenge) Wenn man eine Schema so betrachtet, dann kann man rausfinden, ob Daten valide sind oder nicht. Das ist hilfreich!
  23. 23. Der Wert von Schemas • Strukturelle Integrität • Garantie, was gespeichert und gelesen werden kann • Korrupte Daten beim lesen? • Verhindert Datenkorruption • Fehler viel später? • Fehler wird zu dem Zeitpunkt geworfen, an dem er gemacht wurde • Was sind die Umstände der Datenkorruption? • spart Zeit
  24. 24. Also, was wollen wir? • • • Linear skalierende Storage sharded, massiv paralleles Cluster Semi-strukturierte Datensätze, inklusive Binärendateien • Real-time queries mit SQL • Erweiterte SQL Abfragen möglich (und UDFs). • Open Source • Standard-Hardware (Betriebsystem unabhängig)
  25. 25. You know, for search querying 24 000 000 000 Records in 900ms 14502 views @jodok
  26. 26. • Map/Reduce to push to Elasticsearch distcp • via NFS to HDFS storage S3 HDFS HDFS ES • no dedicated nodes transform MAPRED https://github.com/lovelysystems/ls-hive https://github.com/lovelysystems/ls-thrift-py-hadoop
  27. 27. Speicher Netzwerk • Die täglichen Spitzen liegen bei 
 600MByte/s
  28. 28. Antwortzeit
  29. 29. Lasst uns den Kurs weiterfahren
  30. 30. STORM ?
  31. 31. Die Komponenten
  32. 32. Das hört sich ja gut an, • aber was funktioniert denn schon alles?
  33. 33. Table creation cr> create table my_table1 (! ... first_column integer primary key,! ... second_column string! ... ) clustered into 10 shards! CREATE OK (... sec)! ! + + + - routing! replicas! fulltext indizes, analyzers! ALTER! Schema for object fields
  34. 34. Insert/Update Data cr> insert into locations values ('2013-09-12T21:43:59.000Z', 'Blagulon Kappa is the planet to which the police are native.', 'Planet', 'Blagulon Kappa', 7)! INSERT OK, 1 row affected (... sec)
 cr> update locations set race['name'] = 'Human' where name = 'Bartledan'! UPDATE OK, 1 row affected (... sec)
  35. 35. Queries cr> select name, race['name'] from locations where race['name'] = 'Bartledannians' +-----------+----------------+! | name | race['name'] |! +-----------+----------------+! | Bartledan | Bartledannians |! +-----------+----------------+! SELECT 1 row in set (... sec)! ! cr> select count(*), kind from locations group by kind order by count(*) desc, kind asc! +----------+-------------+! | COUNT(*) | kind |! +----------+-------------+! | 5 | Planet |! | 4 | Star System |! +----------+-------------+! SELECT 3 rows in set (... sec)
  36. 36. Clients • CRasH: Crate shell for command line (python) • Python (BLOB, DB-API, SQLAlchemy) • Java (JDBC planned) • SQL over HTTP always possible
  37. 37. Funktioniert das wirklich?
  38. 38. Was passiert auf der Hardware? • • • • 4 Server: Supermicro SuperServer SYS-5017C-MTF CPU: Intel Xeon E3-1240 - 3,3GHz (8 Cores) Memory: 4x Samsung Memory M391B1G73BH0-CH9 8GB Disks:1x Intel 320 Series 300GB 63,5mm Flash SSD
           1x Western Digital WD RE4 WD1003FBYX 1000 GB ! • • • ca. 10 Tabellen für die Applikationen (davon 8 mit < 50k Datensätze, 2 mit insgesamt 250M. Reine Datenmenge: 25GB 1 Replika ! • Applikation erzeugt ca. 750 queries pro Sekunde (davon ca. 300 INSERT)
  39. 39. Und dann gibt’s ein Release:
  40. 40. Servus und bis bald! github.com/crate @cratedb @jodok

×