Forum: PC-Programmierung BigData - Massendaten-Speicherung mit sehr schneller Abfrage


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gordon M. (headless)


Lesenswert?

Hallo zusammen.

Hat zwar jetzt nicht wirklich was mit Mikrokontrollern zu tun, aber kann 
man vielleicht auch für eine Wetterdatenbank gebrauchen, oder so.

Ich suche eine Datenbank die einfache Daten so speichert, das sie sehr 
schnell wieder abgerufen werden können.

Es handelt sich um eine Tabelle mit 5 Spalten. Die erste ist ein 
Timestamp in Millisekunden. Auf diesem könnte der Index liegen. Die 
anderen 4 Spalten sind Dezimalzahlen mit max 6 Stellen vor und 4 Stellen 
nach dem Komma.
Das wars. Es sind aber aktuell 180 Mio Datensätze. Könnte sich aber auch 
noch vervielfachen.

Ich habe es erst einmal in eine MariaDB gehauen. Geht, aber nicht mehr 
schön.

Gibt es eine Datenbank (für Privatanweder) die dafür besser geeignet 
ist? Die diese Anzahl von Daten trotzdem recht schnell durchsuchen kann? 
(Es wird nur im Timestamp gesucht)

Danke schon mal.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Gordon M. schrieb:
> Gibt es eine Datenbank (für Privatanweder) die dafür besser geeignet
> ist?

Wenn mySql / MariaDB nicht reicht, sollte man wohl stets mal ein Auge 
auf ein PostgreSQL werfen. Braucht bissel mehr Aufwand in der 
Einrichtung, aber sollte allemal viel performanter sein, selbst ohne 
irgendein Tuning.

von Bumm und Peng (Gast)


Lesenswert?

Welche Art von Abfragen brauchst du?
Haben die Daten Eigenschaften die man für eine Speicherung abseits von 
einer Indexierung durch Bäume nutzen kann?

von Gordon M. (headless)


Lesenswert?

Jörg W. schrieb:
> Wenn mySql / MariaDB nicht reicht, sollte man wohl stets mal ein Auge
> auf ein PostgreSQL werfen. Braucht bissel mehr Aufwand in der
> Einrichtung, aber sollte allemal viel performanter sein, selbst ohne
> irgendein Tuning.

Ah ok, wusste gar nicht das PostgreSQL performanter ist als MySQL. 
Dachte immer es ist andersrum. Muss ich mal ausprobieren was es bringt.



Bumm und Peng schrieb:
> Welche Art von Abfragen brauchst du?
> Haben die Daten Eigenschaften die man für eine Speicherung abseits von
> einer Indexierung durch Bäume nutzen kann?

Wie meinst du das?
Abgragen ganz normale SELECT Abfragen. Mit einem Limit und ORDER BY 
timestamp.
Ich weiß gerade nicht was du mit Bäumen meinst. Wenn du relational 
meinst, dann nein. Die Zahlen unterliegen keinem Schema und lassen sich 
nicht gruppieren.

von Gordon M. (headless)


Lesenswert?

Wie sieht es mit NoSQL aus? Damit hatte ich noch nichts zu tun. Sind die 
nicht für "BigData" gemacht worden?

von (prx) A. K. (prx)


Lesenswert?

Klingt weniger nach einer SQL Datenbank, als vielmehr nach einem simplen 
Key/Value Speicher. Wenn dann auch noch kein Netz gebraucht wird, dann 
wär vielleicht die Berkeley DB passend.

von Sean G. (atmega318)


Lesenswert?

Du könntest auch mal ClickHouse probieren, vor allem falls du noch 
Abfragen wie z.B. min/max/avg mit Bins machen möchtest.

von Bumm und Peng (Gast)


Lesenswert?

Gordon M. schrieb:
> Wie meinst du das?
> Abgragen ganz normale SELECT Abfragen. Mit einem Limit und ORDER BY
> timestamp.

Wenn du schneller und größer sein willst als die die Daten in Bäumen zu 
indexieren und die dadurch universell sind musst du die Daten und die 
darauf gewünschten Abfragen definieren und eine Struktur definieren die 
für deinen eingeschränkten Zwecks schneller und größer ist.

Das ist die normale Vorgehensweise für Optimierung.

von Low impedance source (Gast)


Lesenswert?

Warum. Ne DB? Nimm doch nen hdf5 file.

von Blechbieger (Gast)


Lesenswert?

Hört sich nach Zeitreihen an. Dafür gibt es spezielle optimierte 
Datenbanken, z.B. InfluxDB.

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Gordon M. schrieb:
> Abgragen ganz normale SELECT Abfragen. Mit einem Limit und ORDER BY
> timestamp.

Analysiere erstmal wo eventuell überhaupt dein Problem liegt, das "Zeit 
frisst". Wenn du in deiner Abfrage irgendwas drin hast was sich nicht 
mit dem Index verträgt, ist es am ende egal welches DB-Backend du nutzt, 
die benötigen dann alle unnötig lange. Gerade bei so einem primitiven 
Konstrukt wie bei dir sollten eigentlich alle SQL-Datenbanken kein 
Problem damit haben, außer du hast irgend was "schräges" in deiner 
Abfrage drin?

Eine einzige Platte Tabelle hat eigentlich mit BigData so garnichts zu 
tun. Da geht es eher drum zig Datenquellen, mit ggf. hunderten 
Abhängigkeiten miteinander zu verknüpfen.

Gordon M. schrieb:
> das sie sehr schnell wieder abgerufen werden können.
Immer diese total genauen angaben:-) Was hast du derzeit für Zeiten? Wo 
willst du hin?

Für den Anfang mal zum Analysieren deiner Abfrage:
- https://dev.mysql.com/doc/refman/5.7/en/using-explain.html
- https://dev.mysql.com/doc/refman/8.0/en/explain.html

Wenn das nichts hilft, wird es schwieriger:
- https://dev.mysql.com/doc/refman/8.0/en/optimizing-server.html

von Sascha (Gast)


Lesenswert?

Das hört sich für mich eher wie ein Strukturproblem an. Wahrscheinlich 
nur ein Primary Key auf das Datum.

Mysql (InnoDB) kann auch bei größeren Datenmenge mit den richtigen 
Indicies sehr performant sein. Wir habe eine Tabelle mit fast 2 
Milliarden einträgen und eine Bereichsabfrage dauert vielleicht 20ms.

Vorschlag: Schau dir deine Abfrage an (Nach welchen Feldern Sortierst 
oder Filterst du) und dann erstellst du einen Column übergreifenden 
Index darauf.
Bedenke die Reihenfolge der Indizierten Columns, da der Index nur 
angewendet wird, wenn die Columns 'hintereinader' im WHERE order order 
by verwendet werden. Ansonsten ist immer ein kompletter Index Scan 
erforderlich.

Beispiel: Felder Datum, Typ, Sensor im Index. Dann kannst du NUR nach 
Datum, nach Datum und Typ oder Datum, Typ und Sensor abfragen.
Eine Abfrage Nur Typ und Sensor, verwendet diesen Index nicht.

Überprüfe auch deine Einstellungen, vorallem die InnoDB Parameter 
explizit die größe des innodb-buffer-pool-size. Je mehr dort geht, je 
besser.

von (prx) A. K. (prx)


Lesenswert?

Ist sukzessive Datenverdichtung ein Thema? Also sowas wie avg/min/max 
älterer Daten in zunehmenden Intervallen? Dann wäre rrdtool interessant.

: Bearbeitet durch User
von Georg (Gast)


Lesenswert?

Gordon M. schrieb:
> Es sind aber aktuell 180 Mio Datensätze

Wenn ich mich nicht verrechnet habe, sind das ja gerade mal 5 GByte. Und 
wenn es so extrem schnell sein muss empfiehlt sich eine Datenbank die 
komplett im RAM gehalten wird.

Georg

von Georg (Gast)


Lesenswert?

Georg schrieb:
> eine Datenbank die
> komplett im RAM gehalten wird.

Das Stichwort heisst "In-Memory-Datenbank".

Georg

von Εrnst B. (ernst)


Lesenswert?

Georg schrieb:
> Das Stichwort heisst "In-Memory-Datenbank".

Bei so kleinen Datenmengen halten "konventionelle" Datenbanken 
(Postgres/Mariadb) das auch im RAM, solange man die nicht auf minimalen 
Speicherbedarf konfiguriert hat.
Aber ja, wenn er wirklich die letzten Millisekunden optimieren will und 
viele 1000 User gleichzeitig auf der Datenbank werkeln sollen, kann er 
mit einer spezialisierten In-Memory-Datenbank noch was rausholen.

Ich vermute aber, er hat bei seinem Test hier:

Gordon M. schrieb:
> Ich habe es erst einmal in eine MariaDB gehauen. Geht, aber nicht mehr
> schön.

irgendwelche groben Fehler gemacht.

von Sebastian (Gast)


Lesenswert?

Evtl. partitionieren?

LG, Sebastian

von Jens G. (jensig)


Lesenswert?

Sebastian schrieb:
> Evtl. partitionieren?
>
> LG, Sebastian

Noch mehr Quatsch.

Der TO solle doch mal die komplette DDL der Tabelle, und die konkreten 
Abfragen mit ihren Laufzeiten hier reinstellen. Dann kann man weit 
besser entscheiden, ob und was hier evtl. schiefläuft.
Und ja, mit dem bereits erwähnten Explain-Tool läßt sich sehr schön 
herausfinden, wie und wo der Hase so INTERN läuft.

von Norbert S. (norproz)


Lesenswert?

Blechbieger schrieb:
> Hört sich nach Zeitreihen an. Dafür gibt es spezielle optimierte
> Datenbanken, z.B. InfluxDB.

ja, hätt ich auch gesagt. aber: die einarbeitung in die abfragesprache 
ist etwas komplizierter als popeliges sql. wenn nicht influxspezifische 
funktionen noch einen performancegewinn bringen würde ich eher auf 
postgres/timescale setzen. und im schlimmsten fall noch über sharding 
und partitionierung nachdenken.

von Sheeva P. (sheevaplug)


Lesenswert?

Gordon M. schrieb:
> Ich suche eine Datenbank die einfache Daten so speichert, das sie sehr
> schnell wieder abgerufen werden können.
>
> Es handelt sich um eine Tabelle mit 5 Spalten. Die erste ist ein
> Timestamp in Millisekunden. Auf diesem könnte der Index liegen. Die
> anderen 4 Spalten sind Dezimalzahlen mit max 6 Stellen vor und 4 Stellen
> nach dem Komma.
> Das wars. Es sind aber aktuell 180 Mio Datensätze. Könnte sich aber auch
> noch vervielfachen.

Wenn es sich um Zeitseriendaten handelt, könnte sich ein Blick auf für 
PostgreSQL-Erweiterung TimescaleDB lohnen. In meinen Tests war das 
deutlich performanter als das normale PostgreSQL und auch als 
Spezialisten wie InfluxDB. Nach meiner Erfahrung ist PostgreSQL bei 
größeren Datenmengen performanter als MySQL, MariaDB und Co., 
insbesondere dann, wenn man die großen Tabellen partitioniert. Das kann 
aber je nach Workload auch immer vollkommen anders aussehen...

Wenn Du es richtig, richtig, richtig schnell haben möchtest, könntest Du 
Dir einmal den Columnar Store MonetDB oder die Volltextsuchmaschinen 
Elastic- oder OpenSearch anschauen. Wie bitte, höre ich Dich fragen, 
eine Volltextsuchmaschine? Ja, richtig gehört. Elasticsearch hat sich 
schon lange darauf konzentriert, mehr als nur Volltextsuche zu können, 
und deswegen gibt es dafür sogar eigens ein Webfrontend namens Kibana 
für Datenanalysen, -Visualisierung, Dashboarding etc. Ähnliches gilt 
auch für den Elasticsearch-Fork namens OpenSearch. Normalerweise liegen 
Abfragen damit im einstelligen Millisekundenbereich. Je nach Deinen 
Anforderungen und wachsenden Datengrößen haben Elastic- und OpenSearch 
noch weitere interessante Features wie Replikation, wenn Du 
Hochverfügbarkeit brauchst, und Sharding, mithin: horizontale 
Skalierbarkeit über einen Cluster aus IIRC bis zu 1000 Servern, wenn 
Deine Daten noch sehr viel größer werden. Viel Spaß und Erfolg!

von Sheeva P. (sheevaplug)


Lesenswert?

Jörg W. schrieb:
> Wenn mySql / MariaDB nicht reicht, sollte man wohl stets mal ein Auge
> auf ein PostgreSQL werfen. Braucht bissel mehr Aufwand in der
> Einrichtung, aber sollte allemal viel performanter sein, selbst ohne
> irgendein Tuning.

Das Tuning würde ich trotzdem empfehlen, denn PostgreSQL wird meistens 
mit sehr konservativen Einstellungen ausgeliefert -- IIRC 4 MB work_mem 
und lediglich 128 MB shared_buffers. Ich persönlich habe gute 
Erfahrungen mit [1] gemacht, das je nach PostgreSQL-Version, 
Anwendungsfall und vorhandenem Arbeitsspeicher ganz gute Anfangswerte 
für die postgresql.conf liefert, die man mit den Informationen aus [2] 
dann noch verfeinern kann.

Übrigens: die Konfiguration, die [1] ausspuckt, kann man einfach ans 
Ende der postgresql.conf schreiben, sie überschreiben die vorherigen 
Werte.

[1] https://pgtune.leopard.in.ua/
[2] https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

von Sheeva P. (sheevaplug)


Lesenswert?

(prx) A. K. schrieb:
> Klingt weniger nach einer SQL Datenbank, als vielmehr nach einem simplen
> Key/Value Speicher. Wenn dann auch noch kein Netz gebraucht wird, dann
> wär vielleicht die Berkeley DB passend.

Und wenn Netz gebraucht wird, vielleicht auch Redis -- der In-Memory 
läuft und dadurch wirklich extrem schnell ist. Trotzdem kann man 
natürlich fein granuliert konfigurieren, wie die Daten persistiert 
werden.

von Sheeva P. (sheevaplug)


Lesenswert?

Sean G. schrieb:
> Du könntest auch mal ClickHouse probieren, vor allem falls du noch
> Abfragen wie z.B. min/max/avg mit Bins machen möchtest.

Danke für den Tipp, das kannte ich noch gar nicht.

von Sheeva P. (sheevaplug)


Lesenswert?

Jens G. schrieb:
> Sebastian schrieb:
>> Evtl. partitionieren?
>
> Noch mehr Quatsch.

Zumindest für PostgreSQL ist das gar kein Quatsch.

von Rubble C. (Gast)


Lesenswert?

Nimm AWS DynamoDB oder AWS Athena. Für die kleinen Mengen dürfte das 
praktisch gratis sein.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Gordon M. schrieb:
> Ich weiß gerade nicht was du mit Bäumen meinst.
Ich tippe mal binärer Baum als mehrdimensionale Liste

> Die Zahlen unterliegen keinem Schema und lassen sich
> nicht gruppieren.
Das ist unerheblich. Es ist ein Datensatz, aus dem mittels Algo ein 
eindeutiger Key erzeugt werden kann, auch wenn es keine Zahl ist. Das 
geht sogar bei mehrfachen Eingaben derselben Zahl oder anderer 
identischer items.

Der mehrdimensionale Baum muss mit einem Algo befüllt und immer mal 
wieder balanciert werden. Das ist immer nötig, wenn man nicht anhand des 
Keys und einer definierten Verteilung z.B. einem Eingabemonat eine 
Vorwauswahl treffen kann und würde auch den Vorschlag "Partitionieren" 
betreffen.

Wenn man das beschleunigen möchte, muss man die Datenbasis mehrfach 
parallel aufbauen, was man auch als Redundanz zur Datensicherheit nutzen 
kann.

Die items werden letztlich anhand ihres Keys einsortiert. Damit ist 
jeder Key testbar und ermittelbar, ob der Eintrag exisitert und wo. Die 
Suche beschränkt sich damit auf etwa LOG (N,2) + 10% ... 30% balancing 
oberhead.

Mit einem FPGA-System auf 166 MHz kann man auf diese Weise z.B. 10 Mia 
Einträge in unter 40 Takten = 0,2 us durchsuchen und ein neuer Satz 
einsortieren. Die 40 Takte wirken dann nochmal beim Umsortieren und 
balancieren des Baumes. Der betroffene Vektor kommt mit alten und neuen 
Folgern in allen (in dem Fall 2) Dimensionen in einen Cache, um bei 
Anfragen, die zufällig diese items betreffen eine Inkonsistenz abfangen 
zu können. Gecached abgefangene Anfragen brauchen einen neuen 
Suchvorgang und laufen dann halt nochmal 40 Takte.

BTDT: Läuft in einer Struktur mit mehreren Kintex-Boards - die Bremse 
sind die Anzahl und die internen / angeschlossenen Speicher in den FPGAs 
sowie (in meinem Fall) das nach dem Auffinden des Keys noch nötige 
Ansprechen der jeweiligen DDR-RAMs, wenn der Key gefunden wurde.

*wenn hier nur eine Zahl, also ein vom Umfang her eher kleiner Datensatz 
gespeichert werden soll, kann man das komplett im internen RAM machen 
und vom Tempo her auf einem PC durchaus in Echtzeit mit einem externen 
Speicher machen.

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Norbert S. schrieb:
> aber: die einarbeitung in die abfragesprache
> ist etwas komplizierter als popeliges sql.

...nichts ist umsonst! ...die "einarbeitung" in die "abfragesprache" 
(sind übrigens beides Substantive!) ist für einen SQL-Wissenden 
Kindergarten!

In heutigen Zeiten versucht man nicht irgendwas auf der Datenbank seines 
"Wissens" (was auch immer) zu vergewaltigen, sondern sucht sich die DB 
aus, die am optimalsten für die jeweilige Anforderung ist! --> bei 
Messwerten über ein Zeitintervall, ist es halt eine Zeitreihen-DB!

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Norbert S. schrieb:
> wenn nicht influxspezifische
> funktionen noch einen performancegewinn bringen

...auch hier gibt es Substantive im Satz...

Ja, wenn du die Doku, von z.B. InfluxDB lesen würdest, die gibt es!

von Sheeva P. (sheevaplug)


Lesenswert?

Uwe B. schrieb:
> ...nichts ist umsonst! ...die "einarbeitung" in die "abfragesprache"
> (sind übrigens beides Substantive!) ist für einen SQL-Wissenden
> Kindergarten!

Naja, es ist sicherlich eine Frage des Geschmacks und der Gewöhnung, 
aber Influx' Abfragesprache finde ich ein wenig... unübersichtlich. 
Allerdings kann ja auch InfluxDB so etwas Ähnliches wie SQL...

> In heutigen Zeiten versucht man nicht irgendwas auf der Datenbank seines
> "Wissens" (was auch immer) zu vergewaltigen, sondern sucht sich die DB
> aus, die am optimalsten für die jeweilige Anforderung ist! --> bei
> Messwerten über ein Zeitintervall, ist es halt eine Zeitreihen-DB!

Okay, eine Zeitreihendatenbank. Da gibt es aber eine ganze Menge, nicht 
nur InfluxDB. Mir fallen da zum Beispiel auch noch andere Spezialisten 
wie zum Beispiel Prometheus, Graphite und die PostgreSQL-Erweiterung 
TimescaleDB, aber auch... "Exoten" wie Redis mit der 
TimeSeries-Erweiterung [1], oder auch die Volltextsuchmaschinen Elastic- 
und OpenSearch ein.

Insbesondere Redis ist als In-Memory-Key-Value-Store extrem performant 
und wird diese Anforderung des TO sicherlich erfüllen. Immer noch sehr 
schnell sind Elastic- und OpenSearch, weil die ohnehin all ihre Daten in 
Inverted Indices speichern. Und in meinen Tests war auch die 
PostgreSQL-Erweiterung TimescaleDB deutlich performanter als InfluxDB -- 
das mag vielleicht bei anderen Workloads anders aussehen, müßte man mal 
testen.

Aber TimescaleDB ist eben eine Erweiterung für das ohnehin extrem 
flexible PostgreSQL, und das bedeutet vor allem: man muß dafür keine 
neuen Sprachen lernen, sondern kann weiterhin einfach mit SQL arbeiten. 
Außerdem kann man damit obendrein auch noch alles, was PostgreSQL 
ohnehin schon kann, etwa Stored Procedures und Trigger in allerlei 
Sprachen, oder Notifications, oder die vielen Datentypen und ihre 
Funktionen, die bei PostgreSQL schon direkt aus der Tüte fallen.

Wie gesagt: hinsichtlich der Performance müßte unser TO die Sache 
einfach mal testen, wie seine Workload in InfluxDB und in TimescaleDB 
sowohl mit, als auch ohne Partitionierung mit Hypertables performt. 
Danach hat er ein Kosten-Nutzen-Kalkül, ob es sich für seinen 
Anwendungsfall lohnt, InfluxDB zu nutzen und dafür dessen Abfragesprache 
zu lernen, oder ob TimescaleDB seine Anforderungen gleich oder sogar 
besser erfüllt und zumindest seinen Lernaufwand minimieren hilft. 
Womöglich könnte er die SQL-Queries aus der vorhandenen MariaDB-Version 
sogar weitestgehend unverändert übernehmen.


[1] https://redis.io/docs/stack/timeseries/

von C-hater (c-hater)


Lesenswert?

Gordon M. schrieb:

> Es handelt sich um eine Tabelle mit 5 Spalten. Die erste ist ein
> Timestamp in Millisekunden. Auf diesem könnte der Index liegen. Die
> anderen 4 Spalten sind Dezimalzahlen mit max 6 Stellen vor und 4 Stellen
> nach dem Komma.
> Das wars. Es sind aber aktuell 180 Mio Datensätze.

Das kann jeder aktuelle Rechner locker komplett im RAM halten.

> Könnte sich aber auch
> noch vervielfachen.

Dann musst du halt ggf. einen besser ausgestatteten Rechner verwenden, 
um maximale Performance zu erreichen.

> Gibt es eine Datenbank (für Privatanweder) die dafür besser geeignet
> ist? Die diese Anzahl von Daten trotzdem recht schnell durchsuchen kann?
> (Es wird nur im Timestamp gesucht)

Das sollte eigentlich jede übliche DB können. Ja, die allererste Anfrage 
nach dem Start des DB-Servers könnte möglicherweise etwas länger dauern, 
da muß ggf. erstmal der Index in den RAM geladen werden. Aber danach 
sollte jede folgende Anfrage (mit demselben Pattern) aus diesem Index 
bedient werden. Zumindest ist das bei jeder ernstzunehmenden DB so, daß 
sie die für "häufige" Anfragen nützlichen Indizes eine ganze Weile im 
RAM hält (typisch, bei hinreichender Häufigkeit der Frage und genug 
Speicher, halt quasi permanenent).

Also ich sehe das Problem (wenn es denn wirklich eins gibt) nicht bei 
den Datenbanken. So gut sind die inzwischen eigentlich alle...

von Purzel H. (hacky)


Lesenswert?

Falls es sich um Messdaten handelt, benoetigt man eh keine Datenbank, 
sondern ein strukturiertes File. Jeder Record is gleich Gross. Dann ist 
das Ganze um Groessenordnungen schneller.  Allenfalls legt man einen 
externen Index drueber und kann mit den 500MByte/sek einer SSD rechnen

von Ein T. (ein_typ)


Lesenswert?

C-hater schrieb:
> Das sollte eigentlich jede übliche DB können.

Hast Du den Eingangsbeitrag gelesen? Dort schreibt der TO, daß er 
aktuell eine Datenbank benutzt. Er ist damit aber unzufrieden, und fragt 
deswegen nach einer besseren Lösung.

von Εrnst B. (ernst)


Lesenswert?

Ein T. schrieb:
> Hast Du den Eingangsbeitrag gelesen? Dort schreibt der TO, daß er
> aktuell eine Datenbank benutzt. Er ist damit aber unzufrieden, und fragt
> deswegen nach einer besseren Lösung.

Er schreibt aber auch im Eingangsbeitrag, dass er nur einen kleinen 
Datenbestand mit gerade mal 180 Mio Zeilen hat. Heutzutage Pipifax für 
jede Datenbank.

d.H. Schlussfolgerung: Er verwendet die Datenbank falsch, z.B. 
vergessener Index.

von Jens G. (jensig)


Lesenswert?

Εrnst B. schrieb:
> Ein T. schrieb:
>> Hast Du den Eingangsbeitrag gelesen? Dort schreibt der TO, daß er
>> aktuell eine Datenbank benutzt. Er ist damit aber unzufrieden, und fragt
>> deswegen nach einer besseren Lösung.
>
> Er schreibt aber auch im Eingangsbeitrag, dass er nur einen kleinen
> Datenbestand mit gerade mal 180 Mio Zeilen hat. Heutzutage Pipifax für
> jede Datenbank.
>
> d.H. Schlussfolgerung: Er verwendet die Datenbank falsch, z.B.
> vergessener Index.

Ja, und überhaupt fehlen hier Angaben, wie die Tabelle definiert ist, 
was für Abfragen er benutzt, welche aktuelle Perfromance er sieht, und 
welche er erwartet, bzw. was der TO unter "schnell" und Langsam" 
versteht (ausgedrückt auf Basis von SI-Maßeinheiten)

Jede vernünftige Datenbank mit ordentlichem Datenbankdesign (ok, hier 
ist es eigentlich nur ein Tabellendesign) bekommt es hin, aus 100en 
Millionen Datensätzen einen Datensatz innerhalb von ms herauszusuchen. 
Erst recht, wenn DB auf SSD. Und dazu braucht man keine sogenannten 
InMemory-DBs (was ohnehin nur noch ein Begriff aus der DB-Steinzeit 
ist), keine Partitionierung, oder sonst was ...

: Bearbeitet durch User
von Sebastian W. (wangnick)


Lesenswert?

Jens G. schrieb:
> innerhalb von ms

Da fehlt eine Zahl.

LG, Sebastian

von Jens G. (jensig)


Lesenswert?

Sebastian W. schrieb:
> Jens G. schrieb:
>> innerhalb von ms
>
> Da fehlt eine Zahl.
>
> LG, Sebastian

Nö. Du kennst wohl diese Redewendung nicht?

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Jens G. schrieb:
> nd dazu braucht man keine sogenannten InMemory-DBs
Streng genommen ist das von dir angeführte Flash aber schon irgendwie 
ein solche, oder? Ich meine, wenn ich die Zugriffszeiten heutiger 
Flash-Speicher mit dem vergleiche, was ein RAM-Speicher vor 20 Jahren 
konnte :-)

Purzel H. schrieb:
> Allenfalls legt man einen
> externen Index drueber und kann mit den 500MByte/sek einer SSD rechnen
Es geht je primär ums Sortieren und Durchsuchen. Wenn man keinen guten 
Key anlegen kann, gibt es gewaltige Lücken. Eine kompaktierte Datenbank 
muss immer nach irgendwelchen Treffern durchsucht werden, es muss etwas 
einsortiert werden und es wird so immer darauf ankommen, mit welcher 
Strategie etwas abgelegt wird, um sich das Suchen zu vereinfachen.

Und mit "nur" 500MB/s an Bandbreite dauert das Durchsuchen eines nicht 
strategisch sortierten Datenbestandes von 100Mio Keys eben mehr, als 
1-2ms :-)

von C-hater (c-hater)


Lesenswert?

Jens G. schrieb:

> Jede vernünftige Datenbank mit ordentlichem Datenbankdesign (ok, hier
> ist es eigentlich nur ein Tabellendesign) bekommt es hin, aus 100en
> Millionen Datensätzen einen Datensatz innerhalb von ms herauszusuchen.
> Erst recht, wenn DB auf SSD. Und dazu braucht man keine sogenannten
> InMemory-DBs (was ohnehin nur noch ein Begriff aus der DB-Steinzeit
> ist), keine Partitionierung, oder sonst was ...

Richtig, aber das "InMemory" ergibt sich bei solchen primitiven 
Anwendungen und genug Speicher halt bei modernen Datenbanken fast immer 
ganz automatisch, weil es halt genügt, wenn der Index im RAM liegt. Und 
oft ergibt es sich bei intensiver Nutzung halt eben auch, dass letztlich 
sogar die gesamte Tabelle vollständig im RAM liegt. Ist nur eine Frage 
der Laufzeit, der Nutzungsintensität und der Menge des verfügbaren 
Speichers.

von Xanthippos (xanthippos)


Lesenswert?

(prx) A. K. schrieb:
> Dann wäre rrdtool interessant.

Rrdtool selbst eignet sich nicht für riesige Datenbanken. Es arbeitet 
Memory-mapped files und die Adressen gehen aus.

Aber das Prinzip erscheint recht sinnvoll - Aus dem Timestamp lässt sich 
direkt ohne Suche die Position in der Datei berechnen. Die 
Geschwindigkeit ist unabhängig von der Datenmenge.

P.S. hatte mal so etwas ähnliches mit Mikrocontroller und SD-Karte 
gebaut.

Die "Datenbank-Engine" bestand nur aus wenigen Zeilen.

Beim Schreiben werden Dummy-Datensätze angelegt, bis die richtige 
Position für den neuen Timestamp erreicht ist.
1
time_t prevMinute = logStart - 60 + mFile.size() / sizeof(logEntry_t) * 60;
2
while (prevMinute + 60 < currentMinute) {
3
    prevMinute += 60;
4
    mFile.write((uint8_t*)(&dummyEntry), sizeof(entry));
5
}
6
mFile.write((uint8_t*)(&entry), sizeof(entry));

Beim Lesen wird der Offset für den gewünschten Timestamp berechnet.
1
uint32_t pos = (jobEntry.timestamp - logStart) / 60 * sizeof(logEntry_t);
2
file.seek(pos);
3
file.read((uint8_t*)(jobEntry.logEntry), count * sizeof(logEntry_t));

Vielleicht genügt bei deinem Problem auch so eine Triviallösung.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Jens G. schrieb:
> Jede vernünftige Datenbank mit ordentlichem Datenbankdesign (ok, hier
> ist es eigentlich nur ein Tabellendesign) bekommt es hin, aus 100en
> Millionen Datensätzen einen Datensatz innerhalb von ms herauszusuchen.
> Erst recht, wenn DB auf SSD.

Aus Sicht eines Datenbankers ist es ja nett, was Du schreibst...

> Und dazu braucht man keine sogenannten
> InMemory-DBs (was ohnehin nur noch ein Begriff aus der DB-Steinzeit
> ist), keine Partitionierung, oder sonst was ...

... aber mit einer modernen NoSQL-Datenbank, oder einen Key-Value-Store 
hast Du noch nie gearbeitet, oder?

von C-hater (c-hater)


Lesenswert?

Sheeva P. schrieb:

> ... aber mit einer modernen NoSQL-Datenbank, oder einen Key-Value-Store
> hast Du noch nie gearbeitet, oder?

Das sind Krücken. Nur für sehr spezielle Anwendungsfälle brauchbar und 
primär für Programmierer gedacht, die kein SQL beherrschen. Damit die 
überhaupt was gebacken bekommen können und nicht den Urschleim für jede 
ihrer primitiven Anwendungen neu erfinden müssen.

Gerade was diese Trivialität Key-Value-Store betrifft: Das kann jede 
übliche relationale SQL-DB genau so gut. Das ist doch effektiv nur eine 
simple Tabelle mit zwei Spalten und einem Primärschlüssel auf der 
Key-Spalte.

Was machen denn deiner Meinung nach diese "tollen" Key-Value-Stores 
besser als die im Laufe vieler Jahre hochgradig optimierten "normalen" 
SQL-Datenbanksysteme?

von Rainer W. (rawi)


Lesenswert?

Gordon M. schrieb:
> Gibt es eine Datenbank (für Privatanweder) die dafür besser geeignet
> ist? Die diese Anzahl von Daten trotzdem recht schnell durchsuchen kann?
> (Es wird nur im Timestamp gesucht)

Sind die Daten äquidistant aufgenommen?

von Jens G. (jensig)


Lesenswert?

C-hater schrieb:
> Das sind Krücken. Nur für sehr spezielle Anwendungsfälle brauchbar und
> primär für Programmierer gedacht, die kein SQL beherrschen. Damit die
> überhaupt was gebacken bekommen können und nicht den Urschleim für jede
> ihrer primitiven Anwendungen neu erfinden müssen.
>
> Gerade was diese Trivialität Key-Value-Store betrifft: Das kann jede
> übliche relationale SQL-DB genau so gut. Das ist doch effektiv nur eine
> simple Tabelle mit zwei Spalten und einem Primärschlüssel auf der
> Key-Spalte.

Einfach einen Index, der die Key und Wertespalte einschließt, und schon 
haben wir auch unseren Key-Value-Store ;-), bei dem die eigentliche 
Tabelle gar nicht mehr angesprochen wird bei Abfragen. Und bei manchen 
Datenbanken kann man die Tabelle gleich ohne Tabellenobjekt anlegen 
(wenn meine Erinnerungen nicht trügen) wenn die Spalten gleich komplett 
vom Index eingeschlossen werden.

> Was machen denn deiner Meinung nach diese "tollen" Key-Value-Stores
> besser als die im Laufe vieler Jahre hochgradig optimierten "normalen"
> SQL-Datenbanksysteme?

Key-Value-Store leben von der Einfachheit ihrer "DB-Engine", genauso wie 
die InMemory-DBs, bzw. haben weniger Overhead aufgrund ihrer 
Spezialisierungen auf wenige Aspekte. Als solches sicherlich sinnvoller 
einsetzbar für den TO, wenn er den sonstigen Kram und Features einer 
echten DB nicht braucht. Aber das ist ja offensichtlich gar nicht das 
Problem des TO - zumindest solange er uns nicht verrät, was ich weiter 
oben schon fragte. Denn es klingt ja irgendwie so, als würde er Sekunden 
oder gar Minuten auf's Ergebnis warten, was nach falscher Handhabung der 
DB aussieht. Da isses egal, was für ein DB-Typ es ist.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jens G. schrieb:
> solange er uns nicht verrät

Hast du denn mal auf's Datum geguckt?

Der hat sein Problem wohl schon lange gelöst …

von Sheeva P. (sheevaplug)


Lesenswert?

C-hater schrieb:
> Sheeva P. schrieb:
>> ... aber mit einer modernen NoSQL-Datenbank, oder einen Key-Value-Store
>> hast Du noch nie gearbeitet, oder?
>
> Das sind Krücken. Nur für sehr spezielle Anwendungsfälle brauchbar und
> primär für Programmierer gedacht, die kein SQL beherrschen. Damit die
> überhaupt was gebacken bekommen können und nicht den Urschleim für jede
> ihrer primitiven Anwendungen neu erfinden müssen.

Das ist lustig, weil wir vergleichsweise komplexe Anwendungen für die 
Betrugsprävention entwickeln, meine Kollegen und ich natürlich alle SQL 
beherrschen, und trotzdem in vielen Anwendungsfällen oft NoSQL-DBs oder 
bisweilen auch Key-Value-Stores benutzen.

> Was machen denn deiner Meinung nach diese "tollen" Key-Value-Stores
> besser als die im Laufe vieler Jahre hochgradig optimierten "normalen"
> SQL-Datenbanksysteme?

Auf meinem Rechner macht Redis laut redis_benchmark etwa 140.000 TPS mit 
durchschnittlichen Latenzen um die 0.15 Millisekunden.

PostgreSQL schafft auf demselben Rechner laut pgbench(1) ungetunt 223 
TPS mit durchschnittlichen Latenzen um die 4,6 Millisekunden.

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Lesenswert?

SQLite wäre auch zu erwägen: https://www.sqlite.org/index.html
Das ist einfach ein Datenbankfile und eine Library. Ohne Client/Server.

: Bearbeitet durch User
von C-hater (c-hater)


Lesenswert?

Sheeva P. schrieb:

> Auf meinem Rechner macht Redis laut redis_benchmark etwa 140.000 TPS mit
> durchschnittlichen Latenzen um die 0.15 Millisekunden.
>
> PostgreSQL schafft auf demselben Rechner laut pgbench(1) ungetunt 223
> TPS mit durchschnittlichen Latenzen um die 4,6 Millisekunden.

Na das möchte ich dann doch mal gerne im Detail sehen...

Sprich: Testdatenbank, Testpattern und Konfiguration der DBs...

Das kann so unmöglich stimmen. Da muss man postgre schon bewußt völlig 
daneben konfigurieren, damit das so Scheiße sein kann.

War das etwa eine von Redis finanzierte "Studie"? Dann passt das 
Ergebnis natürlich...

von Sheeva P. (sheevaplug)


Angehängte Dateien:

Lesenswert?

C-hater schrieb:
> Sheeva P. schrieb:
>> Auf meinem Rechner macht Redis laut redis_benchmark etwa 140.000 TPS mit
>> durchschnittlichen Latenzen um die 0.15 Millisekunden.
>>
>> PostgreSQL schafft auf demselben Rechner laut pgbench(1) ungetunt 223
>> TPS mit durchschnittlichen Latenzen um die 4,6 Millisekunden.
>
> Na das möchte ich dann doch mal gerne im Detail sehen...

Probier's doch einfach selbst aus. Im Zweifel in einer Linux-VM und mit 
Docker-Containern -- aber gib' der Linux-VM bitte genug CPUs, sonst ist 
PostgreSQL gleich schon im Nachteil.

> Sprich: Testdatenbank, Testpattern und Konfiguration der DBs...
>
> Das kann so unmöglich stimmen. Da muss man postgre schon bewußt völlig
> daneben konfigurieren, damit das so Scheiße sein kann.

Alles die Defaults. PostgreSQL aus den Paketen von Kubuntu 22.04 LTS mit 
der Standardkonfiguration installiert, Redis aus Versionsgründen manuell 
übersetzt, aber auch ohne Tuning. pgbench und redis-benchmark gehören zu 
den jeweiligen Paketen, alles wurde in der Default-Konfiguration 
verwendet, auch die Benchmarks.

Ich habe das jetzt nochmal auf meinem Desktop ausprobiert. Die CPU ist 
ein AMD Ryzen 7 3800X mit 2 x 32 GB Patriot 3200 C16 Series und einer 
Samsung SSD 980 PRO mit 2TB auf einem ASUS TUF Gaming X570-Plus. Die 
Version von Redis ist 6.2.1, die von PostgreSQL ist 14.7, auf der 
Maschine läuft ein Kubuntu 22.04 LTS mit KDE. Dabei habe ich jeweils mit 
Sockets und mit TCP gearbeitet, um einen Vergleich zu haben.

Genaue Ergebnisse findest Du im Anhang, nur soviel: 120k bis 175k TPS 
mit Redis, 450 bis 480 TPS unter PostgreSQL. Latenzen unter Redis bei 
0,15 bis 0,2 Millisekunden, bei PostgreSQL bei 2 bis 2,2. An der klar 
überragenden Performance von Redis ändert sich wenig, wenn man 
berücksichtigt, daß jede pgbench-Transaktion 5 Befehle umfaßt. Dann 
kommt PostgreSQL also auf 2400 Befehle pro Sekunde, immerhin. Redis ist 
trotzdem 50-mal schneller. Nach ungefähr zwanzig Jahren Erfahrung mit 
PostgreSQL kann ich Dir klar sagen: da kannst Du Dir einen Wolf 
konfigurieren, so viel wirst Du aus PostgreSQL niemals nie nicht 
herausholen.

Wenn ich des Spaßes halber allerdings auch mal das Pipelining von Redis 
einschalte und also 5 Befehle in einer Transaktion ausführen lasse, 
sieht die Sache nochmals besser aus für Redis. Um wirklich fair zu sein: 
nicht jede Workload kann Pipelining nutzen, aber es braucht ja auch 
nicht jede Workload in einer SQL-Datenbank Transaktionen aus mehreren 
Befehlen. Aber dennoch habe ich Redis' Pipelining einmal 
eingeschaltet... und, siehe da: 595k bis 875k TPS, Faktor 247 bis 364 
gegenüber PostgreSQL!

Verstehst Du jetzt, warum es Anwendungsfälle gibt, die auf die extreme 
Performanz von Datenspeichern wie Redis angewiesen sind, und daß diese 
Dinger keineswegs "Krücken" und "primär für Programmierer gedacht 
[sind], die kein SQL beherrschen"? Klar, Key-Value-Stores und 
NoSQL-Datenbanken sind für spezielle Anwendungsfälle gemacht. Niemand 
bestreitet das, und unser TO könnte so einen Anwendungsfall haben. Aber 
die sind für Leute gedacht, die wissen, daß klassische SQL-RDBMs ihre 
Grenzen haben, und die diese Grenzen überwinden wollen oder müssen.

Klassische SQL-Datenbanken sind aber auch für spezielle Anwendungsfälle 
gemacht und gedacht: nämlich für solche, in denen ACID garantiert werden 
muß. Wer ACID nicht braucht, für den sind die Mechanismen, es 
umzusetzen, ein imperformanter und teurer Klotz am Bein. Um das zu 
verstehen, muß man sich nur anschauen, wie das heute in den meisten 
SQL-RDBMs gemacht wird: jeder einzelne Schreibzugriff benötigt 
mindestens zwei Zugriffe auf dem übelsten Flaschenhals, die 
Persistenzschicht, nämlich einmal den Eintrag ins Transaktionslog (in 
PostgreSQL Write-Ahead-Log genannt) und dann noch einen zweiten, mit dem 
die Inhalte des Transaktionslogs in die richtigen Datendateien 
übertragen werden. Der Writebefehl kommt zwar schon nach dem Eintrag ins 
Transaktionslog zurück, das Clientprogramm kann weitermachen, aber 
trotzdem sind das schlimmstenfalls zwei Zugriffe auf die langsamste 
Ressource im Rechner, die unter Last um ebendiese konkurrieren.

Abgesehen von der Performance verschiedener Datenspeicher gibt es aber 
natürlich auch noch andere Eigenschaften, die dazu führen, daß NoSQL-DBs 
sich in den letzten Jahren zunehmender Beliebtheit erfreuen. Stichworte 
wären das CAP-Theorem, die ACID-Garantien, und in diesen Zusammenhängen 
nicht ganz unkomplexe Themen wie Replikation, Sharding, die horizontale 
Skalierbarkeit und natürlich die Hochverfügbarkeit. Diese Eigenschaften 
dürften für den TO spätestens interessant werden, wenn er mit einer 
schon im OP befürchteten Vervielfachung seiner Datenmenge konfrontiert 
ist.

Diesen fachlichen Teil möchte ich allerdings noch kurz mit einem anderen 
Hinweis beschließen, nämlich darauf, daß verschiedene Datenbanken ihre 
Daten in unterschiedlichen Formaten speichern und dieser Umstand enorme 
Auswirkungen auf die Performance des Systems haben kann. Die klassischen 
SQL-RDBMs speichern ihre Daten fast alle zeilenweise, was für die 
meisten Zugriffsmuster auch vollkommen okay ist. Die meisten 
analytischen Abfragen performen aber deutlich besser, wenn die Daten 
spaltenweise gespeichert werden, deswegen gibt es die sogenannten 
"Columnar Stores" wie MonetDB oder Cassandra. Einen Index in einem 
klassischen SQL-RDBMs anzulegen, entspricht dieser Veränderung des 
Speicherformats. Wieder andere Datenspeicher wie Elastic- oder 
OpenSearch speichern ihre Daten nicht nur spaltenweise, sondern auch 
noch indiziert. Schreibt langsam, liest sauschnell.

Okay, genug gelabert. Wer sich ernsthaft für solche Themen interessiert, 
dem empfehle ich Martin Kleppmanns Buch "Designing Data-Intensive 
Systems", erschienen bei O'Reilly. Und natürlich auch die Website von 
Kyle "Aphyr" Kingsbury, einem Spezialisten für verteilte Datenspeicher, 
der etliche solcher Systeme genauer untersucht hat: [1]. YMMV, HF!

[1] https://jepsen.io/

> War das etwa eine von Redis finanzierte "Studie"? Dann passt das
> Ergebnis natürlich...

Nö, das waren kurze Tests, die ich mal eben hier auf einem unbelasteten 
Rechner gemacht hatte, weil auf meinem Desktop gerade ein umfangreiches 
Training eines GRU-Modells lief. Jetzt hab' ich das mal auf dem Desktop 
laufen lassen, und die Ergebnisse stehen oben und im Anhang.

von Sheeva P. (sheevaplug)


Lesenswert?

Jens G. schrieb:
> Einfach einen Index, der die Key und Wertespalte einschließt, und schon
> haben wir auch unseren Key-Value-Store ;-), bei dem die eigentliche
> Tabelle gar nicht mehr angesprochen wird bei Abfragen.

Jaein, so verbreitet ist das leider noch nicht. PostgreSQL, zum 
Beispiel, kann diese sogenannten "Index-Only-Scans" erst seit Version 
9.6 von 2016, wenn ich mich recht entsinne.

> Und bei manchen
> Datenbanken kann man die Tabelle gleich ohne Tabellenobjekt anlegen
> (wenn meine Erinnerungen nicht trügen) wenn die Spalten gleich komplett
> vom Index eingeschlossen werden.

Könntest Du da bitte noch einmal nachschauen und mir eventuell einen 
Link zukommen lassen? Lieben Dank.

> Key-Value-Store leben von der Einfachheit ihrer "DB-Engine", genauso wie
> die InMemory-DBs, bzw. haben weniger Overhead aufgrund ihrer
> Spezialisierungen auf wenige Aspekte.

Absolut richtig! Aber das ist ja genau mein Punkt: wenn Du die Features 
eines klassischen SQL-RDBMs nicht brauchst, warum willst Du dann dessen 
Kosten in Kauf nehmen?

> Aber das ist ja offensichtlich gar nicht das
> Problem des TO - zumindest solange er uns nicht verrät, was ich weiter
> oben schon fragte. Denn es klingt ja irgendwie so, als würde er Sekunden
> oder gar Minuten auf's Ergebnis warten, was nach falscher Handhabung der
> DB aussieht. Da isses egal, was für ein DB-Typ es ist.

Richtig... aber mit einem Elasticsearch-Cluster kann ich problemlos ein 
Search-as-you-type über die 14 Terabyte Daten einer großen Versicherung 
abbilden, und wenn die Suche dann wirklich abgeschickt wird, kommen 
meine Freunde Damerau, Levenshtein und Morse ins Spiel. Versuch' das mal 
mit einem klassischen SQL-RDBMs und einem Tausendstel der Datenmenge... 
;-)

von Sebastian W. (wangnick)


Lesenswert?

Sheeva P. schrieb:
> Ich habe das jetzt nochmal auf meinem Desktop ausprobiert.

Interessant. Danke für deine Mühe!

LG, Sebastian

von Jens G. (jensig)


Lesenswert?

Sheeva P. schrieb:
>> Und bei manchen
>> Datenbanken kann man die Tabelle gleich ohne Tabellenobjekt anlegen
>> (wenn meine Erinnerungen nicht trügen) wenn die Spalten gleich komplett
>> vom Index eingeschlossen werden.
>
> Könntest Du da bitte noch einmal nachschauen und mir eventuell einen
> Link zukommen lassen? Lieben Dank.

Ok, war wohl zu viel Phantasie dabei ;-). Also ohne Table-Objekt geht's 
doch nicht. Aber die INCLUDE-Option beim CREATE INDEX in DB2 LUW geht 
schon in die Richtung, um der DB Engine einen IndexOnly-Scan auch bei 
"eigentlich" nicht indexierten Spalten zu ermöglichen.

Jörg W. schrieb:
> Jens G. schrieb:
>> solange er uns nicht verrät
>
> Hast du denn mal auf's Datum geguckt?
>
> Der hat sein Problem wohl schon lange gelöst …

Ach, das glaub ich nicht. Er ist bestimmt immer noch beim Durchprobieren 
aller DB-Architekturen ... ;-)

Sheeva P. schrieb:
> Genaue Ergebnisse findest Du im Anhang, nur soviel: 120k bis 175k TPS
> mit Redis, 450 bis 480 TPS unter PostgreSQL. Latenzen unter Redis bei
> 0,15 bis 0,2 Millisekunden, bei PostgreSQL bei 2 bis 2,2. An der klar
> überragenden Performance von Redis ändert sich wenig, wenn man
> berücksichtigt, daß jede pgbench-Transaktion 5 Befehle umfaßt. Dann
> kommt PostgreSQL also auf 2400 Befehle pro Sekunde, immerhin. Redis ist
> trotzdem 50-mal schneller. Nach ungefähr zwanzig Jahren Erfahrung mit
> PostgreSQL kann ich Dir klar sagen: da kannst Du Dir einen Wolf
> konfigurieren, so viel wirst Du aus PostgreSQL niemals nie nicht
> herausholen.

Nun, da müsste man schon hinterfragen, was Redis unter "Transaction" 
versteht (also das T in TPS). Denn abgesehen von dem Unterschied, den Du 
schon nanntest, kennen solche eingedampften DB-Systeme oftmals/meistens 
gar keine Transaktionen, womit dann auch der ganze damit verbundene 
Overhead komplett wegfällt ...

von Sheeva P. (sheevaplug)


Lesenswert?

Jens G. schrieb:
> Sheeva P. schrieb:
> Ok, war wohl zu viel Phantasie dabei ;-). Also ohne Table-Objekt geht's
> doch nicht. Aber die INCLUDE-Option beim CREATE INDEX in DB2 LUW geht
> schon in die Richtung, um der DB Engine einen IndexOnly-Scan auch bei
> "eigentlich" nicht indexierten Spalten zu ermöglichen.

Danke, daß Du nachgesehen hast. Die INCLUDE-Option gibt es bei 
PostgreSQL auch, aber bisher habe ich die noch nie benutzt. Letzten 
Endes werden die betreffenden Indizes dadurch größer und das Schreiben 
in die DB teurer, dafür geht das Lesen schneller... wie so oft bei 
Datenbanken, handelt man das Eine gegen das Andere. ;-)

> Sheeva P. schrieb:
>> Genaue Ergebnisse findest Du im Anhang, nur soviel: 120k bis 175k TPS
>> mit Redis, 450 bis 480 TPS unter PostgreSQL. Latenzen unter Redis bei
>> 0,15 bis 0,2 Millisekunden, bei PostgreSQL bei 2 bis 2,2. An der klar
>> überragenden Performance von Redis ändert sich wenig, wenn man
>> berücksichtigt, daß jede pgbench-Transaktion 5 Befehle umfaßt. Dann
>> kommt PostgreSQL also auf 2400 Befehle pro Sekunde, immerhin. Redis ist
>> trotzdem 50-mal schneller. Nach ungefähr zwanzig Jahren Erfahrung mit
>> PostgreSQL kann ich Dir klar sagen: da kannst Du Dir einen Wolf
>> konfigurieren, so viel wirst Du aus PostgreSQL niemals nie nicht
>> herausholen.
>
> Nun, da müsste man schon hinterfragen, was Redis unter "Transaction"
> versteht (also das T in TPS). Denn abgesehen von dem Unterschied, den Du
> schon nanntest, kennen solche eingedampften DB-Systeme oftmals/meistens
> gar keine Transaktionen, womit dann auch der ganze damit verbundene
> Overhead komplett wegfällt ...

Redis spricht korrekterweise von "Requests pro Sekunde" oder "rps", das 
T war insofern eine Ungenauigkeit von mir. Redis kennt zwar ein Konzept, 
das "Transaktion" genannt wird, aber mit den "alles oder 
nichts"-Transaktionen, wie wir sie von klassischen RDBMs kennen, hat das 
nichts zu tun.

Ansonsten hast Du natürlich Recht, daß auch viele andere NoSQL-Systeme 
keine Transaktionskonzepte wie die Relationalen kennen. Das ist einer 
der Gründe dafür, daß viele davon so viel performanter sind. Deswegen 
passen sie natürlich nicht für jeden Anwendungsfall, aber für viele eben 
schon. Soetwas hatte ich oben schon angedeutet: wer ACID nicht braucht, 
kann dessen Kosten vermeiden. Wer ACID braucht, kann das natürlich 
nicht.

Danke nochmals, daß Du wegen der Indizes nachgeschaut hast.

von Jens G. (jensig)


Lesenswert?

Sheeva P. schrieb:
> Danke, daß Du nachgesehen hast. Die INCLUDE-Option gibt es bei
> PostgreSQL auch, aber bisher habe ich die noch nie benutzt. Letzten
> Endes werden die betreffenden Indizes dadurch größer und das Schreiben
> in die DB teurer, dafür geht das Lesen schneller... wie so oft bei
> Datenbanken, handelt man das Eine gegen das Andere. ;-)

Tja, Performance-Tuning ist meistens ein Kompromiss. An der einen Stelle 
hilft es, woanders muß man dann eben Nachteile in Kauf nehmen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.