Warum ‘ne Datenbank, wenn wir
Elasticsearch haben?

@jodok #dchh
@jodok
@cratedb
@lovelysystems
Was macht ‘ne Datenbank?

1. Dokumente speichern
2. Binäre Objekte speichern
3. … wieder finden/lesen
4. … analysieren
5. …...
Wie macht man das
bei einer großen
Datenmenge?
MongoDB (1., 3., 4., 5.?) + Elasticsearch
(3.) + GridFS (2)
!

Riak (1., 3....
Einfach
zu benutzen, zu skalieren, zu betreiben
Elasticsearch
einfach geil
Einfach toll… (nicht nur search)
•

Echtzeit-Suche

•

Volltext Suche

•

Verteilt

•

•

Hoch verfügbar

Versions Konflikt...
Und nu’?
•
•
•
•
•
•

Sicherheitsmodell?
Transaktionen?
Datensicherheit?
Reifegrad der Werkzeuge?
Große Berechnungen?
Verfügbarkeit...
Was macht die Datenhaltung?

… but also inspired by
Nathan Marz
ACID
•

Atomicity - alles oder nichts

•

Das ist zuuu vieeel, speziell
bei verteilten Knoten.

•

Consistency - nur gülti...
Jeder, der große Applikationen
baut, setzt auf CAP und BASE.
BASE & CAP
•

Basically Available - das
System gibt immer eine
Antwort

•

Soft State - es muss nicht
jederzeit konsistent...
Genau!
Wir brauchen einen
Key/Value store!
PUT
GET
Nicht ganz…
Anfrage =
Funktion(Alle Daten)
•

Manchmal geht es darum, gespeicherte Informationen wieder
abzurufen

•

Meistens werden ...
Strukturierte Daten?
Schemas
•

Schwierig zu ändern

•

“Sind im weg”, stören

•

Generieren Zusatzaufwand für den Entwickler

•

Es nervt, im ...
Genau!
Lass uns eine schemalose NoSQL
Datenbank benutzen!
Das ist eine Überreaktion
Bitte folgert nicht von der
!

schlechten Umsetzung!
!

von Schemas auf den
!

Zusatzwert,
!

den Schemas erzeugen!
Funktion(Datenmenge)
Wenn man eine Schema so betrachtet, dann
kann man rausfinden, ob Daten valide sind oder
nicht.
Das ist...
Der Wert von Schemas
•

Strukturelle Integrität

•

Garantie, was gespeichert und
gelesen werden kann

•

Korrupte Daten b...
Also, was wollen wir?
•

•

•

Linear skalierende
Storage
sharded, massiv
paralleles Cluster
Semi-strukturierte
Datensätze...
You know, for search
querying 24 000 000 000 Records in 900ms

14502 views

@jodok
• Map/Reduce to push
to Elasticsearch	


distcp

• via NFS to HDFS
storage	


S3

HDFS

HDFS
ES

• no dedicated nodes

tra...
Speicher

Netzwerk
•

Die täglichen Spitzen liegen bei 

600MByte/s
Antwortzeit
Lasst uns den Kurs weiterfahren
STORM

?
Die Komponenten
Das hört sich ja gut an,
•

aber was funktioniert denn schon alles?
Table creation
cr> create table my_table1 (!
...
first_column integer primary key,!
...
second_column string!
... ) cluste...
Insert/Update Data
cr> insert into locations values
('2013-09-12T21:43:59.000Z', 'Blagulon Kappa is the
planet to which th...
Queries

cr> select name, race['name'] from locations where race['name'] = 'Bartledannians'
+-----------+----------------+...
Clients
•

CRasH: Crate shell for command line (python)

•

Python (BLOB, DB-API, SQLAlchemy)

•

Java (JDBC planned)

•

...
Funktioniert das wirklich?
Was passiert auf der Hardware?
•
•
•
•

4 Server: Supermicro SuperServer SYS-5017C-MTF
CPU: Intel Xeon E3-1240 - 3,3GHz (8...
Und dann gibt’s ein Release:
Servus und bis bald!
github.com/crate

@cratedb
@jodok
Warum 'ne Datenbank, wenn wir Elasticsearch haben?
Warum 'ne Datenbank, wenn wir Elasticsearch haben?
Warum 'ne Datenbank, wenn wir Elasticsearch haben?
Warum 'ne Datenbank, wenn wir Elasticsearch haben?
Warum 'ne Datenbank, wenn wir Elasticsearch haben?
Warum 'ne Datenbank, wenn wir Elasticsearch haben?
Warum 'ne Datenbank, wenn wir Elasticsearch haben?
Nächste SlideShare
Wird geladen in …5
×

Warum 'ne Datenbank, wenn wir Elasticsearch haben?

3.007 Aufrufe

Veröffentlicht am

Developer Conference Hamburg 2013

Veröffentlicht in: Technologie
0 Kommentare
3 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.007
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
68
Aktionen
Geteilt
0
Downloads
33
Kommentare
0
Gefällt mir
3
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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

×