Als PDF, PPTX herunterladen
![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)](https://image.slidesharecdn.com/dchh2013-131107185247-phpapp02/75/Warum-ne-Datenbank-wenn-wir-Elasticsearch-haben-39-2048.jpg)
![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)](https://image.slidesharecdn.com/dchh2013-131107185247-phpapp02/75/Warum-ne-Datenbank-wenn-wir-Elasticsearch-haben-40-2048.jpg)
Hochgeladen vonJodok Batlogg
Warum 'ne Datenbank, wenn wir Elasticsearch haben?
Das Dokument erörtert die Vorzüge von Elasticsearch im Vergleich zu traditionellen Datenbanken, hebt Möglichkeiten wie Echtzeitsuche, verteilte Architektur und Skalierbarkeit hervor. Es diskutiert zudem Herausforderungen wie Datenintegrität, Transaktionsmanagement und die Vor- und Nachteile von schemalosen NoSQL-Datenbanken. Abschließend werden Anwendungsbeispiele und technische Details zu einem spezifischen Implementierungsansatz vorgestellt.
Weitere ähnliche Inhalte
Warum 'ne Datenbank, wenn wir Elasticsearch haben?
- 1. Warum ‘ne Datenbank,wenn wir Elasticsearch haben? @jodok #dchh
- 2.
- 3. Was macht ‘neDatenbank? 1. Dokumente speichern 2. Binäre Objekte speichern 3. … wieder finden/lesen 4. … analysieren 5. … wieder verändern
- 4. Wie macht mandas 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. Einfach zu benutzen, zuskalieren, zu betreiben
- 6.
- 7. Einfach toll… (nichtnur search) • Echtzeit-Suche • Volltext Suche • Verteilt • • Hoch verfügbar Versions Konfliktbehebung • Restful API • Mandantenfähig
- 8.
- 9. • • • • • • Sicherheitsmodell? Transaktionen? Datensicherheit? Reifegrad der Werkzeuge? GroßeBerechnungen? Verfügbarkeit der Daten?
- 10. Was macht dieDatenhaltung? … but also inspired by Nathan Marz
- 11. ACID • Atomicity - allesoder 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. Jeder, der großeApplikationen baut, setzt auf CAP und BASE.
- 13. BASE & CAP • BasicallyAvailable - 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. Genau! Wir brauchen einen Key/Valuestore! PUT GET
- 15.
- 16. Anfrage = Funktion(Alle Daten) • Manchmalgeht 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.
- 18. Schemas • Schwierig zu ändern • “Sindim 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. Genau! Lass uns eineschemalose NoSQL Datenbank benutzen!
- 20. Das ist eineÜberreaktion
- 21. Bitte folgert nichtvon der ! schlechten Umsetzung! ! von Schemas auf den ! Zusatzwert, ! den Schemas erzeugen!
- 22. Funktion(Datenmenge) Wenn man eineSchema so betrachtet, dann kann man rausfinden, ob Daten valide sind oder nicht. Das ist hilfreich!
- 23. Der Wert vonSchemas • 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. Also, was wollenwir? • • • 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. You know, forsearch querying 24 000 000 000 Records in 900ms 14502 views @jodok
- 28. • Map/Reduce topush 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
- 29. Speicher Netzwerk • Die täglichen Spitzenliegen bei 600MByte/s
- 30.
- 31. Lasst uns denKurs weiterfahren
- 34.
- 36.
- 37. Das hört sichja gut an, • aber was funktioniert denn schon alles?
- 38. Table creation cr> createtable 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
- 39. Insert/Update Data cr> insertinto 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)
- 40. 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)
- 41. Clients • CRasH: Crate shellfor command line (python) • Python (BLOB, DB-API, SQLAlchemy) • Java (JDBC planned) • SQL over HTTP always possible
- 42.
- 44. Was passiert aufder 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)
- 46. Und dann gibt’sein Release:
- 47. Servus und bisbald! github.com/crate @cratedb @jodok