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.
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.
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?
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.
Wie sieht es mit NoSQL aus? Damit hatte ich noch nichts zu tun. Sind die nicht für "BigData" gemacht worden?
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.
Du könntest auch mal ClickHouse probieren, vor allem falls du noch Abfragen wie z.B. min/max/avg mit Bins machen möchtest.
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.
Warum. Ne DB? Nimm doch nen hdf5 file.
Hört sich nach Zeitreihen an. Dafür gibt es spezielle optimierte Datenbanken, z.B. InfluxDB.
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
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.
Ist sukzessive Datenverdichtung ein Thema? Also sowas wie avg/min/max älterer Daten in zunehmenden Intervallen? Dann wäre rrdtool interessant.
:
Bearbeitet durch User
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
Georg schrieb: > eine Datenbank die > komplett im RAM gehalten wird. Das Stichwort heisst "In-Memory-Datenbank". Georg
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.
Evtl. partitionieren? LG, Sebastian
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.
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.
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!
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
(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.
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.
Jens G. schrieb: > Sebastian schrieb: >> Evtl. partitionieren? > > Noch mehr Quatsch. Zumindest für PostgreSQL ist das gar kein Quatsch.
Nimm AWS DynamoDB oder AWS Athena. Für die kleinen Mengen dürfte das praktisch gratis sein.
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.
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!
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!
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/
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...
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
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.
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.
Ε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
Sebastian W. schrieb: > Jens G. schrieb: >> innerhalb von ms > > Da fehlt eine Zahl. > > LG, Sebastian Nö. Du kennst wohl diese Redewendung nicht?
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 :-)
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.
(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
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?
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?
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?
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
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 …
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.
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
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...
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.
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... ;-)
Sheeva P. schrieb: > Ich habe das jetzt nochmal auf meinem Desktop ausprobiert. Interessant. Danke für deine Mühe! LG, Sebastian
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 ...
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.