ich möchte ein Programm erstellen, dass zahlreiche Datensätze liefert.
Mit dem Programm an sich hab ich keine Probleme. Die Daten sollten
allerdings in eine Datenbank übernommen werden und dort anschließend
ausgewertet.
Ich suche also Lösung, mit der ich eine Datenbank von gut 100 Millionen
einträgen verwalten kann, am Ende vermutlich um die 20GB groß
Hat jemand eine Idee?
Sollte für keine kommerzielle Datenbank ein Problem sein.
Oracle, SQL Server oder auch IBM DB-2.
Die kostenlosen Versionen haben allerdings Einschränkungen.
Ein Rechner mit 32GByte Ram hilft bei der Performance. Ist ja heute nix
besonderes mehr.
Inwieweit kostenlose Datenbanken das können weiss ich nicht, denke aber
das das auch da kein Problem sein sollte.
Udo S. schrieb:> Inwieweit kostenlose Datenbanken das können weiss ich nicht, denke aber> das das auch da kein Problem sein sollte.
Das schafft selbst SQLite. Von MariaDB und PostgreSQL ganz zu schweigen.
Gerade nochmal nachgeschaut:
MS SQL Server Express kann es nicht, der hat eine künstliche
Beschränkung auf 1G Ram, 1 CPU und max. 10G Datenbankgröße.
Allerdings kann man die Developer Edition verwenden wenn das Ganze nicht
kommerziell ist. Die hat keine Einschränkungen.
Bei Oracle müsste man forschen.
Aber wie Andreas gesagt hat gibts genügend freie Alternativen.
Falls die Datensaetze gleich, oder aehnlich gross waeren, wuerde auch
ein Array auf einem Stream taugen, welches schliesslich noch etwas
schneller waere.
Emil Kaiser schrieb:> ich möchte ein Programm erstellen, dass zahlreiche Datensätze liefert.> Mit dem Programm an sich hab ich keine Probleme. Die Daten sollten> allerdings in eine Datenbank übernommen werden und dort anschließend> ausgewertet.> Ich suche also Lösung, mit der ich eine Datenbank von gut 100 Millionen> einträgen verwalten kann, am Ende vermutlich um die 20GB groß>> Hat jemand eine Idee?
Nun, wie andere Teilnehmer dieses Thread bereits sehr richtig ausgeführt
haben, sind 20 GB heutzutage nicht besonders groß, das kann jede
klassische relationale Datenbank Management System (RDBMS) -- egal, ob
es PostgreSQL oder anders heißt.
Was die geschätzten Mitdiskutierenden allerdings zu vergessen scheinen,
ist, daß die Wahl eines geeigneten Datenspeichers auch noch von anderen
Bedingungen als der schieren Datenmenge abhängt, denn Daten sind nicht
gleich Daten. Daten, die keine Relationen enthalten, lassen sich mit
anderen Speichersystemen als einem RDBMS oft wesentlich effizienter und
performanter speichern.
Zudem bieten viele moderne Speichersysteme eine
Clusteringfunktionalität, so daß die Daten nicht auf einem, sondern
verteilt über mehrere Rechner (Stichwort Sharding) und meistens
außerdem mehrmals auf verschiedenen Rechnern (Stichwort Replikation)
gespeichert werden können. Durch diese Eigenschaften lassen sich eine
horizontale Skalierung und eine hohe Verfügbarkeiten gewährleisten.
Ein Beispiel wäre ein Append-Only-Log, wie es häufig bei Sensor-, Log-
und anderen Monitoring-Daten anfällt. Solche Daten sind meist besser in
einer spezialisierten Zeitseriendatenbank aufgehoben, beispielsweise
InfluxDB, Prometheus, Graphite, und Ähnlichen.
Strukturierte Daten (etwa: JSON) hingegen lassen sich dagegen meist
besser in einer NoSQL- oder Dokumentendatenbank speichern, zum Beispiel
MongoDB, Apache Cassandra, Apache CouchDB oder Elasticsearch.
Ohne also die weiteren Voraussetzungen zu kennen -- Art der Daten,
Anforderungen an Verfügbarkeit und Skalierbarkeit -- ist es daher nicht
ganz einfach, Dir eine ideale Lösung zu empfehlen. Für die genannten
Datenbanksysteme, aber auch für PostgreSQL und andere RDBMS, gibt es
generisches Webfrontend namens Grafana zur Analyse und Visualisierung
Deiner Daten, aber Du kannst Dir natürlich auch etwas in Python (zB. mit
Pandas), R oder ähnlichen Technologien schreiben.
Wenn Du einen guten Allrounder suchst, mit dem Du viele Anwendungsfälle
abdecken kannst (wenngleich nicht alle ideal), dann neige ich gerne zu
Elasticsearch. Das speichert Deine Daten spaltenweise indexiert und
ermöglicht so einen besonders schnellen lesenden Zugriff auf Deine
Daten, das Schreiben einzelner Datensätze ist dagegen nicht ganz so
schnell (dafür gibt es allerdings ein Bulk-Feature). Elasticsearch
unterstützt Sharding und Replikation und bietet obendrein einige weitere
spannende Features, zum Beispiel eine performante Volltextsuche, welche
auch unscharf (Levenshtein, phonetische Suche nach verschiedenen
Algorithmen) suchen kann. Und für Deinen speziellen Anwendungsfall, die
Daten hinterher noch analysieren zu wollen, gibt es aus demselben Hause
das Webinterface Kibana, das das Durchsuchen, Analysieren, und
Visualisieren Deiner Daten ermöglicht.
Du siehst: der Möglichkeiten gibt es viele, und ohne weitere
Informationen zu Deinen Daten und Deinen Anforderungen fällt es schwer,
eine ideale Lösung zu empfehlen. Vielleicht magst Du noch etwas dazu
sagen?
Emil Kaiser schrieb:> eine Datenbank von gut 100 Millionen einträgen verwalten kann, am Ende> vermutlich um die 20GB groß
Kinderkram, dss passt heute ja sogar in den Hauptspeicher:
Udo S. schrieb:> Ein Rechner mit 32GByte Ram hilft bei der PerformanceUdo S. schrieb:> MS SQL Server Express kann es nicht> Allerdings kann man die Developer Edition verwenden wenn das Ganze nicht> kommerziell ist. Die hat keine Einschränkungen.
Ich hab nicht gelesen, dass er nur kostenlose Demosoftware verwenden
darf. MariaDB wäre kostenlos.
Purzel H. schrieb:> Falls die Datensaetze gleich, oder aehnlich gross waeren, wuerde> auch ein Array auf einem Stream taugen, welches schliesslich noch etwas> schneller waere.
Vorausgesetzt man muss die Daten nicht wiederfinden, so ohne
Indizierung.
Purzel H. schrieb:> Falls die Datensaetze gleich, oder aehnlich gross waeren, wuerde auch> ein Array auf einem Stream taugen, welches schliesslich noch etwas> schneller waere.
Hahaha. Für Write-Only Speicher ist das eine super schnelle Alternative.
MaWin schrieb:> Emil Kaiser schrieb:>> eine Datenbank von gut 100 Millionen einträgen verwalten kann, am Ende>> vermutlich um die 20GB groß>> Kinderkram, dss passt heute ja sogar in den Hauptspeicher:>> Udo S. schrieb:>> Ein Rechner mit 32GByte Ram hilft bei der Performance
Das könnte man je nach den Umständen natürlich auch prima mit einem
In-Memory-Key-Value-Store wie Redis abfackeln. Macht auf moderner
Hardware lockere 400k Transaktionen pro Sekunde... ;-)
> Ich hab nicht gelesen, dass er nur kostenlose Demosoftware verwenden> darf. MariaDB wäre kostenlos.
PostgreSQL auch.
Emil Kaiser schrieb:> ich möchte ein Programm erstellen
Noch ein Tip aus der Praxis: Erst einmal schauen, zu welchen Datenbanken
die gewünschte Programmiersprache eine Schnittstelle bietet, die
möglichst ohne irgendwelche Konfigurationsorgien auskommt (falls doch
mal die Hardware gewechselt werden muß, bzw. falls Entwicklungs- und
Produktivsystem unterschiedliche Hard/Software haben) und im Idealfall
auch noch leicht zu benutzen ist.
Von den untertützten DB suchst Du Dir dann eine aus.
MaWin, der Schlaue schrieb :
>>Purzel H. schrieb:>> Falls die Datensaetze gleich, oder aehnlich gross waeren, wuerde>> auch ein Array auf einem Stream taugen, welches schliesslich noch etwas>> schneller waere.>>Vorausgesetzt man muss die Daten nicht wiederfinden, so ohne>Indizierung.
Ein Array ist ja schon indexiert.
MaWin schrieb:> Udo S. schrieb:>> MS SQL Server Express kann es nicht>> Allerdings kann man die Developer Edition verwenden wenn das Ganze nicht>> kommerziell ist. Die hat keine Einschränkungen.>> Ich hab nicht gelesen, dass er nur kostenlose Demosoftware verwenden> darf. MariaDB wäre kostenlos.
Kostenlose DBMS waren ja von Andreas B. schon genannt.
Und wer solche Fragen stellt will mit großer Wahrscheinlichkeit kein
Geld für ein kommerzielles DBMS ausgeben.
MaWin schrieb:> Purzel H. schrieb:>> Ein Array ist ja schon indexiert.>> Soll das nun ein Aprilscherz sein oder blanke Unwissenheit ?
Hoffe das Eine aber wette auf das Andere.
MaWin schrieb:> Purzel H. schrieb:>> Ein Array ist ja schon indexiert.>> Soll das nun ein Aprilscherz sein oder blanke Unwissenheit ?
Wieso Aprilscherz? Für jede Aufgabe gibt es passende Lösungen. Das kann
ein fettes DBMS oder eine Lowlevel-Datei sein. Vor 10 Jahren oder mehr
stand ich auch vor dem Problem meine Logdaten (Heizung, Solaranlage,
Wetterdaten u.s.w) irgendwo zu lassen. Für diesen Zweck ist die Zeit
dass Maß der Dinge. Alle 2min ein Record bei ca 100 Messstellen. Ich
wüsste nicht wozu ich dafür einen Index brauche. Es gibt eine Datei die
an einem festen Zeitpunkt startet und im 2min Raster an ausrechenbaren
Positionen die feste Anzahl Sensordaten speichert. Das ganze in c++ zu
schreiben dauert keine Tag incl. json Requests auswerten und die Daten
json-Formatiert zurück zu liefern damit eine Webanwendung Diagramme
malen kann ö.ä. In der Summe über 10Jahre ergeben sich da auch ca. 1Gb
Daten und 2,5 Mio Datensätze. Wenn man Gesamtauswertungen machen will,
wird die ganze Datei in den Speicher gemappt oder geladen alle weiteren
Zugriffe sind dann reine Pointer/Array Arithmetik. Ich wage zu
bezweifeln, dass irgendein DBMS egal welcher Art das
geschwindigkeitsmäßig schlagen kann.
Aber wie gesagt, was bei mir passt muss nicht bei anderen passen, aber
solche Sprüche wie Aprilscherz oder Unwissenheit zeugen nur von einem:
Dummheit.
mh schrieb im Beitrag #6648732:
> welche DB schneller ist als ein Arrayzugriff> in C++?
Jede, wenn die Informationen die man sucht nicht im Array Index
abgebildet sind.
Jim M. schrieb:> mh schrieb:>> welche DB schneller ist als ein Arrayzugriff>> in C++?>> Jede, wenn die Informationen die man sucht nicht im Array Index> abgebildet sind.
Gerade von diesem Spezialfall redet er hier. Dann und nur dann stimmt
das auch.
Das alte Spiel: Fehlen wesentliche Information in der Frage, bleibt nur
raten oder die Klappe halten. Rückfrage kann funktionieren, aber manche
bleiben auch dann sehr zugeknöpft.
(prx) A. K. schrieb:> Fehlen wesentliche Information in der Frage, bleibt nur> raten oder die Klappe halten.
Oder das streiten der anderen Forenteilnehmer. Wie hier. ;-)
Andreas B. schrieb:> 100Ω W. schrieb:>> Excel ist KEINE Datenbank.>> Warum nur wurde Access bisher nicht erwähnt?
Weil Access auch keine Datenbank ist, sondern eher ein Frontend?
Andreas B. schrieb:> Gerade von diesem Spezialfall redet er hier. Dann und nur dann stimmt> das auch.
Genau, und was anderes habe ich nie behauptet. Eigentlich hat man bei so
was immer nur einen Request: Startzeit, Endzeit welche Daten. Ich wüßte
nicht was mir ein Index über die Sensordaten bringen sollte.
Auswertungen in irgendeiner Art erfolgen immer in einem zeitlichen
Bereich.
Man könnte sich auch solche Requests vorstellen: In welchem Jahr war der
kälteste Januartag am Aussensensor und wie hoch war an diesem Tag der
Gasverbrauch? Bei so was helfen Indexe (außer der Zeit die ein Array
auch hat) eines DBMS auch nicht wirklich und es muss auch dort jeder
Record im Januarbereich jedes Jahres durchgerödelt werden.
Sogar bei Zählerständen (Strom, Wasser, Gas) brauche ich für eine
Abfrage wann der Zählerstand 234567 war keinen Index. Da Zählerstände
automatisch aufsteigend sind, geht eine binäre Suche im Array wenigstens
so schnell wie in einem Index eines DBMS.
temp schrieb:> Bei so was helfen Indexe (außer der Zeit die ein Array> auch hat) eines DBMS auch nicht wirklich und es muss auch dort jeder> Record im Januarbereich jedes Jahres durchgerödelt werden.
Das stimmt wiederum nicht.
Andreas B. schrieb:> temp schrieb:>> Bei so was helfen Indexe (außer der Zeit die ein Array>> auch hat) eines DBMS auch nicht wirklich und es muss auch dort jeder>> Record im Januarbereich jedes Jahres durchgerödelt werden.> Das stimmt wiederum nicht.
Ich bin kein DB-Experte. Wie findet denn die DB (such dir eine aus, wenn
es nicht allgemein geht) diesen Wert?
Udo S. schrieb:> MS SQL Server Express kann es nicht, der hat eine künstliche> Beschränkung auf 1G Ram, 1 CPU und max. 10G Datenbankgröße.
Dann nimmt halt den MS-Mist nicht.
SQLLITE. Zitat Google.
Eine SQLite-Datenbank ist auf 140 Terabyte (2 47 Byte, 128 Tibibyte)
begrenzt. Und selbst wenn es größere Datenbanken handhaben könnte,
speichert SQLite die gesamte Datenbank in einer einzigen
Festplattendatei, und viele Dateisysteme begrenzen die maximale Größe
von Dateien auf etwas weniger.
Ich durchsuche auf meinen Rechner eine Datenbank mit 4,2 Mio Datensätzen
nach einen NICHT indizierten Feld mit der LIKE-abfrage in ca. 25
Sekunden unter VB als Programmiersprache und der passenden
DLL-Einbindung. Datenbank lokal auf SSD.
Nur damit da mal einer eine Haus-Nr. hat.
mh schrieb:> Wie findet denn die DB (such dir eine aus, wenn> es nicht allgemein geht) diesen Wert?
Ja, mit einem Index eben. Bei einer relationalen DB kann man jedes Feld
mit einem Key versehen. Diese Indextabelle (die Realisierung ist DBMS
abhängig) wird dann bei jedem Einfügen eines Satzes aktualisiert. Man
muß sich eben beim Aufbau der Tabellen schon Gedanken über die Anwendung
machen. Bei einer Suche über dieses Feld kann dann direkt via Index auf
das betreffende Feld zugegriffen werden.
Schlaumaier schrieb:> Ich durchsuche auf meinen Rechner eine Datenbank mit 4,2 Mio Datensätzen> nach einen NICHT indizierten Feld mit der LIKE-abfrage in ca. 25> Sekunden
Ewigkeiten. So etwas macht man aber auch nicht. Das zeigt, daß man beim
Datenbankdesign nicht nachgedacht hat.
Andreas B. schrieb:> mh schrieb:>> Wie findet denn die DB (such dir eine aus, wenn>> es nicht allgemein geht) diesen Wert?> Ja, mit einem Index eben. Bei einer relationalen DB kann man jedes Feld> mit einem Key versehen. Diese Indextabelle (die Realisierung ist DBMS> abhängig) wird dann bei jedem Einfügen eines Satzes aktualisiert. Man> muß sich eben beim Aufbau der Tabellen schon Gedanken über die Anwendung> machen. Bei einer Suche über dieses Feld kann dann direkt via Index auf> das betreffende Feld zugegriffen werden.
Also dein "Das stimmt wiederum nicht" trifft nur zu, wenn man den
richtigen Index erstellt hat? Wenn man beim Planen der DB (im
beschriebenen Fall also vor mehr als 10 Jahren) nicht vorausgesehen hat
was man heute untersuchen möchte, hat man Pech gehabt und muss ne neue
Indextabelle erstellen?
Andreas B. schrieb:> Ewigkeiten. So etwas macht man aber auch nicht. Das zeigt, daß man beim> Datenbankdesign nicht nachgedacht hat.
Ich habe nachgedacht.
Aber JEDES Feld was man 1 x in 5 Jahren mal abfragen will mit einen
Index zu versehen ist auch nicht das Gelbe von Ei. Davon abgesehen habe
ich die Abfrage nur programmiert um mal zu sehen wo die Grenzen sind.
mh schrieb:> nicht vorausgesehen hat> was man heute untersuchen möchte, hat man Pech gehabt und muss ne neue> Indextabelle erstellen?
JA und. Der einzige Index der wirklich wichtig ist, ist ID aus
Automatischer Index.
Ich gehe bei der Datenbankpflege und besonders bei der Enwicklung der
Software oft hin + lege neue Indexe an, bzw. lösche alte die nicht
gebraucht werden.
Wie oben schon beschrieben sind zu viel u./o. falsche Indexe halt ein
Zeitfaktor-Problem meiner Meinung nach.
Also einfach ein häufig benötigtes Feld nach-Indizieren.
Ist zwar nicht die feine Art des Programmieren aber wat-mut-dat-mut.
Danach baut die DB halt den Index auf und gut ist. Kann aber je nach
DB-Größe etc. einige Zeit dann dauern. Also nix für "mal eben" ;)
Ich persönlich merke oft erst beim Entwickeln der Software manchmal erst
das es Sinnvoll ist ein Feld zu indexieren.
Und ein VACUUM Befehl sollte man eh hin + wider machen. Da geht das in
ein Abwasch. Ist halt die Datenbankpflege auf Admin-Ebene.
mh schrieb:> hat man Pech gehabt und muss ne neue> Indextabelle erstellen?
Natürlich. Aber das ist auch nachträglich noch zu machen. Dann rödelt
die DB halt eine Weile herum, um diese Indextabelle zu erstellen.
Im übrigen sollte man sich grundsätzlich bei der SW Entwicklung Gedanken
über die spätere Anwendung machen. Spätere Änderungen sind immer teuer.
Schlaumaier schrieb:> Ich habe nachgedacht.> Aber JEDES Feld was man 1 x in 5 Jahren mal abfragen will mit einen> Index zu versehen ist auch nicht das Gelbe von Ei.
Das verstehe ich aber auch nicht als Nachdenken. Erst sollte man sich
Gedanken machen was man denn überhaupt programmmieren will.
> Ich persönlich merke oft erst beim Entwickeln der Software manchmal erst> das es Sinnvoll ist ein Feld zu indexieren.
Ja, was denn nun? Nachgedacht oder nicht?
Ok, so etwas passiert, sollte aber nicht der Normalfall sein.
temp schrieb:> geht eine binäre Suche im Array wenigstens so schnell wie in einem Index> eines DBMS.
Abgesehen davon, dass schnelle Indizes heute meist gehasht sind, also
schneller als O(log(N))
Andreas B. schrieb:> mh schrieb:>> hat man Pech gehabt und muss ne neue>> Indextabelle erstellen?> Natürlich. Aber das ist auch nachträglich noch zu machen. Dann rödelt> die DB halt eine Weile herum, um diese Indextabelle zu erstellen.
Was einem nur etwas bringt, wenn man die gleiche Anfrage in Zukunft
häufiger stellen will.
Andreas B. schrieb:> Im übrigen sollte man sich grundsätzlich bei der SW Entwicklung Gedanken> über die spätere Anwendung machen. Spätere Änderungen sind immer teuer.
Über die spätere Anwendung Gedanken machen und wissen was man in der
Zukunft braucht sind zwei sehr unterschiedliche Dinge.
Andreas B. schrieb:>> Ich persönlich merke oft erst beim Entwickeln der Software manchmal erst>> das es Sinnvoll ist ein Feld zu indexieren.> Ja, was denn nun? Nachgedacht oder nicht?> Ok, so etwas passiert, sollte aber nicht der Normalfall sein.
Ich habe immer nachgedacht. Aber die Kunden damals meist nicht.
Besonders wenn sie nachträglich statistische Abfragen wollen. Für die
99% Standardsachen musste ich nie was ändern. Das wäre allein schon
wegen des Programmcode ein Horror an sich. Besonders wenn man Felder
vergessen hat etc.
Bloß wenn der Kunde z.b. plötzlich wissen will wie hoch der Umsatz einer
Unterwarengruppe im Zeitraum X-Y gewesen ist, dann ist es vielleicht
keine schlechte Idee die Unterwarengruppe zu indizieren. Das Datum
selbst ist eh immer Index bei der Art von Software die ich meist
geschrieben habe.
Da ich es aber selbst hasse wenn ich gewisse, eigentlich unwichtige
Felder, nicht abfragen kann, erlaube ich in meiner Software die Abfrage
fast jeden Feld was Sinn macht. Und das sogar in Kombination mit bis zu
4 anderen Feldern und mit LIKE Möglichkeit. Das mache ich sogar in der
für mich Privat geschriebene Software.
Da ich aber nicht jedes dieser Feld indiziere, kommt dann halt die
Meldung "Diese Abfrage kann etwas länger dauern, wollen Sie das
wirklich" o.s.ä.
Der Kunde sagt ja, und es geht los. Wenn er mir irgendwann erzählen
sollte das er die o. die Abfrage dauernd macht weil er die braucht, dann
programmierte ich in einen Update halt eine beschleunigte Variante.
mh schrieb:> Über die spätere Anwendung Gedanken machen und wissen was man in der> Zukunft braucht sind zwei sehr unterschiedliche Dinge.
Stimmt. zum Teil.
Ich habe die Angewohnheit gehabt, Funktionen die ich für Sinnvoll
gehalten habe, die aber nie Gegenstand des Auftrags waren, einfach ins
Geheim vorzubereiten.
Weil mit 95% Wahrscheinlichkeit werden diese Funktionen der Software
hinterher verlangt.
Aber selbst ich hatte keinen Glaskugel. Und wenn es dann mal eine
Funktion gibt die ich nicht vorher gesehen habe, kommt richtig Freude
auf. Das Ergebnis war dann meist, das ich die Wahl hatte zwischen
Spagetti-Code, oder die Routine neu zu schreiben.
Und bei meinen Glück war die "Kleinigkeit" dann so schwer zu coden, das
die Änderung 'mal eben' 4 Wochen gekostet hat.
Emil Kaiser schrieb:> Ich suche also Lösung, mit der ich eine Datenbank von gut 100 Millionen> einträgen verwalten kann, am Ende vermutlich um die 20GB groß
Ich sehe hier keinen Zusammenhang zum Titel ("riesige Datenbank
verwalten"). Soll die 20GB Spielzeugdatenbank als Übungsaufgabe erstellt
werden, um später eine riesige Datenbank vorzubereiten?
Oder soll die riesige Datenbank ein paar Millionen von diesen Winzlingen
akkumulieren?
MaWin schrieb:> temp schrieb:>> geht eine binäre Suche im Array wenigstens so schnell wie in einem Index>> eines DBMS.>> Abgesehen davon, dass schnelle Indizes heute meist gehasht sind, also> schneller als O(log(N))
Ob das finden über einen Hash tatsächlich schneller ist als binäre
Suche, hängt dann schon noch von ein paar Faktoren ab. Davon abgesehen
funktioniert das nur, wenn der gesuchte Wert tatsächlich im Index steht.
Wenn der gesuchte Zählerstand zwischen zwei Messungen liegt, hilft dir
der gehashte Index wenig.
Schlaumaier schrieb:> mh schrieb:>> Über die spätere Anwendung Gedanken machen und wissen was man in der>> Zukunft braucht sind zwei sehr unterschiedliche Dinge.>> Stimmt. zum Teil.>> Ich habe die Angewohnheit gehabt, Funktionen die ich für Sinnvoll> gehalten habe, die aber nie Gegenstand des Auftrags waren, einfach ins> Geheim vorzubereiten.
Schön dass das für dich funktioniert. Für mich würde das nicht
funktionieren. Ich kann nicht voraussagen was ich in ein paar Jahren mit
meinen Daten mache.
Schlaumaier schrieb:> Ich habe immer nachgedacht. Aber die Kunden damals meist nicht.
Oder umgekehrt. Manche Entwickler haben kein Gespür dafür, dass die
Daten des Kunden etwas grösseres Volumen haben, als die paar Testdaten,
mit denen sie ihr Programm fütterten. Und wunderten sich dann drüber,
dass es bei uns so langsam war. Dann kanns halt passieren, dass der
Kunde den Entwickler drauf hinweisen muss, wo ein Index fehlt. ;-)
Schlaumaier schrieb:> Weil mit 95% Wahrscheinlichkeit werden diese Funktionen der Software> hinterher verlangt.
Ist das kommerziell sinnvoll? Das ist doch genau jener Teil von
Aufträgen, mit dem das Geld verdient wird. Mit dem, was nicht im
Pflichtenheft steht, und wodurch der Auftrag hinterher viel teurer wird.
Postgres unterstuezt auch sog "Temporal Types", da kann ein Timstamp zum
schluessel bzw. index werden
https://blog.timescale.com/blog/building-a-distributed-time-series-database-on-postgresql/
Selbst ohne eingebaute Unterstuetzung ist es nicht so schwer, einen
timestamp als milli-, micro- oder nanosekunden seit dem 01.01.1970
darzustellen, das kann einfach indiziert werden.
Ob sich dieser Aufwand lohnt ist eine andere Frage, ich bevorzuge zB.
CSV bzw. binaere Dateien mit festen strukturen fuer timeseries (4-5 GiB
pro 3 Monate), weil das einfacher fuer mich ist.
(prx) A. K. schrieb:> Und wunderten sich dann drüber,> dass es bei uns so langsam war. Dann kanns halt passieren, dass der> Kunde den Entwickler drauf hinweisen muss, wo ein Index fehlt. ;-)
Naja das Problem habe ich dadurch umgangen das ich den Kunden eines sehr
strengen Verhör unterzogen habe, mit Fangfragen sogar. Der Kunde war am
Anfang nicht glücklich, aber als er das Ergebnis als Zusammenfassung
gelesen hat, strahlte er und meinte nur. "Das alles haben sie durch ihre
Fragen heraus gefunden da habe ich nie dran gedacht".
Markus W. schrieb:> Ich sehe hier keinen Zusammenhang zum Titel ("riesige Datenbank> verwalten"). Soll die 20GB Spielzeugdatenbank als Übungsaufgabe erstellt> werden, um später eine riesige Datenbank vorzubereiten?
Die Frage ist halt auch hier. Was sind das für Daten und WO sollen sie
verwaltet werden. 20 GB sind für eine Access-Datenbank fast unmöglich.
Wenn man mein Google-Post oben liest für eine SQL-DB die was taugt nicht
wirklich was besonderes.
Es kommt halt immer auf die Sichtweise des Betroffenen an. Wer bisher
nur die Adressen seiner Freundinnen verwaltet hat, für den sich 20 GB
eine Mega-Datenbank ;)
https://www.tagesspiegel.de/meinung/wir-reden-hier-eigentlich-von-peanuts/676978.html
(prx) A. K. schrieb:> Schlaumaier schrieb:>> Ich habe immer nachgedacht. Aber die Kunden damals meist nicht.>> Oder umgekehrt. Manche Entwickler haben kein Gespür dafür, dass die> Daten des Kunden etwas grösseres Volumen haben, als die paar Testdaten,> mit denen sie ihr Programm fütterten. Und wunderten sich dann drüber,> dass es bei uns so langsam war. Dann kanns halt passieren, dass der> Kunde den Entwickler drauf hinweisen muss, wo ein Index fehlt. ;-)
Ich bin immer sehr glücklich, dass ich weder "Kunde" noch
Softwareentwickler bin, wenn sich meine Freunde über "ihre"
Programmierer beschweren, die fachlich keine Ahnung haben von der
Andwendung die sie entwickeln sollen. In so einem Fall sind meistens
beide Seiten schuld.
Schlaumaier schrieb:> Der Kunde war am> Anfang nicht glücklich, aber als er das Ergebnis als Zusammenfassung> gelesen hat, strahlte er und meinte nur.
Klar strahlt der, er muss ja auch nicht die "Strafe" fürs Ändern der
Anforderungen zahlen, die er bei deiner Konkurrenz zahlen müsste.
mh schrieb:> Ob das finden über einen Hash tatsächlich schneller ist als binäre> Suche, hängt dann schon noch von ein paar Faktoren ab. Davon abgesehen> funktioniert das nur, wenn der gesuchte Wert tatsächlich im Index steht.> Wenn der gesuchte Zählerstand zwischen zwei Messungen liegt, hilft dir> der gehashte Index wenig.
Was schreibst du denn für einen Blödsin. Der Wert braucht nicht
tatsächlich im nicht vorhandenen Index stehen. Er steht im Record wie
alle andern auch.
Die binäre Suche endet dann genau einem Record vor dem gesuchten Wert
wenn es den exakten nicht gibt. Und was willst du mit Hash? Wozu soll
man den an dieser Stelle brauchen? Wenn du das nicht mal verstehst,
solltest du anfangen zu lernen.
mh schrieb:> Schön dass das für dich funktioniert. Für mich würde das nicht> funktionieren. Ich kann nicht voraussagen was ich in ein paar Jahren mit> meinen Daten mache.
Das kann ich sicher auch nicht. Aber ich habe alles selbst in der Hand.
Sensordaten sind nicht dynamisch. Alles was Vergangenheit ist, ist
statisch. Und so wie man bei Bedarf in einem DBMS zusätzliche Indexe
baut, kann ich aus einem statischen Datenbestand auch angepasste
Vorextrakte generieren.
Ich will hier aber niemanden zu irgendwas bekehren, sondern nur sagen
dass es nicht immer nur die eine Lösung gibt. Und ob das jemand versteht
oder gut findet ist mir Wumpe. Nur solche idiotischen Aussagen, dass man
bei einer binären Suche nur den exakten Wert finden kann, das lass ich
so nicht im Raum stehen.
Mladen G. schrieb:> Ob sich dieser Aufwand lohnt ist eine andere Frage, ich bevorzuge zB.> CSV bzw. binaere Dateien mit festen strukturen fuer timeseries (4-5 GiB> pro 3 Monate), weil das einfacher fuer mich ist.
Volle Zustimmumg von mir. Das kann aber heute keiner mehr. Wenn ich
sehe, daß selbst für das Erzeugen simpler json-Dateien fette Libs
verwendet werden die den ganzen Baum in dyn. Strukturen verwalten, dann
fehlen mir oft die Worte.
Schlaumaier schrieb:> Ich durchsuche auf meinen Rechner eine Datenbank mit 4,2 Mio Datensätzen> nach einen NICHT indizierten Feld mit der LIKE-abfrage in ca. 25> Sekunden unter VB als Programmiersprache und der passenden> DLL-Einbindung. Datenbank lokal auf SSD.
Ok, hier mein Senf.
Raspberry Pi 4B 4G, Kingston SA2000M8250G M.2 NVME SSD, PostgreSQL 11
1
CREATE TABLE public.iot (
2
ts timestamptz NOT NULL DEFAULT now(),
3
"json" jsonb NOT NULL,
4
rowid int4 NOT NULL GENERATED ALWAYS AS IDENTITY,
5
CONSTRAINT iot_pkey PRIMARY KEY (rowid)
6
);
7
CREATE INDEX idxginp ON public.iot USING gin (json jsonb_path_ops);
8
CREATE INDEX iot_ts_idx ON public.iot USING btree (ts);
3,2GB bei 3,5M Datensätzen beispielsweise folgender Art:
select count(*) from iot where json ->> 'sw' like '%control07%';
dauert 10s.
Ich habe dazu noch Trigger definiert die Funktionen rufen dir mir die
JSON-Daten zusätzlich noch in (sehr breite) relationale Tabellen
materialisieren.
Zur Darstellung benutze ich dann zur Zeit Orange. Power BI ist mir zu
langsam und unhandlich, und Tableau kann sich nur meine Firma leisten :)
LG, Sebastian
temp schrieb:> Volle Zustimmumg von mir. Das kann aber heute keiner mehr. Wenn ich> sehe, daß selbst für das Erzeugen simpler json-Dateien fette Libs> verwendet werden die den ganzen Baum in dyn. Strukturen verwalten, dann> fehlen mir oft die Worte.
Das gibt es schon noch, nur scheint es nicht "gut genug" bzw. "zu
einfach".
Wenn man sich umsieht meint man schnell, dass Software a besten nie
geaendert werden sollte, am besten gleich wissen was man mit den Daten
in 10 Jahren macht und dann versucht so flexibel wie moeglich zu
bleiben, was die komplexitaet enorm steigert und selten wirklich dazu
fuehrt dass man die flexibilitaet wirklich nutzen kann.
Dinge aendern sich, je weniger Code ich habe umso schneller kann ich den
anpassen, wenn ich nur das programmiere von dem ich sicher weiss dass es
gebraucht wird, bin ich flexibler, weil nix flexibler ist als Code den
es nicht gibt.
Edit:
Auch Datenbank Tabellen kann man aendern, Indizes hinzufuegen und wieder
entfernen.
Einige sehr bekannte Produkte nutzten zB. gar keine Fremdschluessel in
RDBMS, weil diese Produkte sehr viele Datenbanksysteme unterstuetzten
(in mehreren Versionen) und die Migration von Tabellen die
Fremdschluessel referenzieren sehr unterschiedlich ist bei diesen
verschiedenen DBs.
temp schrieb:> [...]
Vielleicht solltest du, nachdem du dich beruhigt hast, nochmal lesen was
ich geschrieben habe, und worauf ich geantwortet habe. Ich bin mir
relativ sicher, dass wir etwas sehr ähnliches ausdrücken wollen.
temp schrieb:> Man könnte sich auch solche Requests vorstellen: In welchem Jahr war der> kälteste Januartag am Aussensensor und wie hoch war an diesem Tag der> Gasverbrauch? Bei so was helfen Indexe (außer der Zeit die ein Array> auch hat) eines DBMS auch nicht wirklich und es muss auch dort jeder> Record im Januarbereich jedes Jahres durchgerödelt werden.
Könnten wir uns bitte darauf einigen, daß Du die Datenbanktechnik Leuten
überläßt, die etwas davon verstehen? Danke. :-)
Sheeva P. schrieb:> temp schrieb:>> Man könnte sich auch solche Requests vorstellen: In welchem Jahr war der>> kälteste Januartag am Aussensensor und wie hoch war an diesem Tag der>> Gasverbrauch? Bei so was helfen Indexe (außer der Zeit die ein Array>> auch hat) eines DBMS auch nicht wirklich und es muss auch dort jeder>> Record im Januarbereich jedes Jahres durchgerödelt werden.>> Könnten wir uns bitte darauf einigen, daß Du die Datenbanktechnik Leuten> überläßt, die etwas davon verstehen? Danke. :-)
Verstehst du etwas von Datenbanktechnik? Wie löst man das Problem bei
einer existierenden DB, die keinen passenden Index hat, ohne einen
passenden Index zu erstellen?
mh schrieb:> Wie löst man das Problem bei> einer existierenden DB, die keinen passenden Index hat, ohne einen> passenden Index zu erstellen?
Nun, offensichtlich gar nicht.
Andererseits ist man mit SSD und flottem Prozessor in der Lage, relativ
problemlos 200 MB/s per table-scan zu verarbeiten. Viele Leute haben
derartig niedrige Ansprüche, daß sie das als schnell empfinden.
Sehe^H^H^H ah ich regelmäßig.
Kunde: "Unsere Datenbank ist gewachsen und jetzt sind unsere Abfragen zu
langsam geworden..."
Ich: <nachschau> 100MB in der Tabelle ... Moment mal. Keinerlei Index
(ja, nichtmal ein PRIMARY KEY) drauf. Und die Query wäre ... WHERE foo =
42 ... "Mach halt einen Index auf (foo)"
Kunde: "Ist immer noch langsam!!1!elf"
Ich: "Zeig mal die Query"
Kunde: "SELECT ... WHERE foo = '42' ..."
Meine Tischkante hat immer noch Bißspuren von damals. Wenigstens war es
nicht ... WHERE foo LIKE '%42%'.
Mittlerweile bin ich nicht mehr in Support. Und die Wunden vernarben.
Axel S. schrieb:> Viele Leute haben> derartig niedrige Ansprüche, daß sie das als schnell empfinden.
Den Eindruck habe ich auch wenn ich manche Beiträge hier so lese.
Axel S. schrieb:> Meine Tischkante hat immer noch Bißspuren von damals
Bei Dir waren es wenigstens die Kunden. Da stört es mich nicht, die
bezahlen ja. Aber wenn so etwas die eigenen Programmierer machen....
Sheeva P. schrieb:> Könnten wir uns bitte darauf einigen, daß Du die Datenbanktechnik Leuten> überläßt, die etwas davon verstehen? Danke. :-)
Ich habe in meinem Leben schon viele Schwätzer gesehen die der Meinung
waren sie verstehen was von Datenbanktechnik. Und dann kommen da
Datenbestände dabei raus die selbst in großen Firmen keiner mehr unter
Kontrolle hat weil zu viele Leute daran rumfummeln und immer nur aus der
Sicht ihres Problems Schnellschüsse veranstalten. Ganz zu schweigen von
der Validierung der Daten bevor sie in die DB kommen. Klassisches
Beispiel ist der bunte Mix aus ANSI und UTF8 in den gleichen Feldern,
den findet man in fast allen DBs die eine Weile "gewachsen" sind und
viele Herren hatten. Reale Beispiele könnte ich nennen, allerdings hab
ich keinen Bock mich mit bekannten großen Firmen anzulegen.
Je größer die Firma desto größer ist auch der Schiss der
verantwortlichen "Datenbankexperten" überhaupt Alternativen in Betracht
zu ziehen. Bleibt man beim Platzhirsch-DBMS kann man ja nichts verkehrt
machen. Das muss perfekt sein und auch zu jedem Problem passen weil es
ja Unsummen an Geld kostet. Wird es langsam, hat man einen auf den man
es schieben kann und gleichzeitig den Grund für die Investition in die
nächste noch fettere Hardware-Generation. So kann man seinen Sessel
schön vollfurzen ohne Angst um die nächste Gehaltserhöhung haben zu
müssen. Und nebenbei verblödet man ohne es zu merken und schreibt im
MC-Forum schlaue Beiträge.
mh schrieb:> Vielleicht solltest du, nachdem du dich beruhigt hast, nochmal lesen was> ich geschrieben habe, und worauf ich geantwortet habe.
Bitte um Verzeihung, da habe ich deinen Beitrag wirklich falsch
interpretiert.
Jim M. schrieb:> Jede, wenn die Informationen die man sucht nicht im Array Index> abgebildet sind.
Bei Temp sind die Daten aber nun mal im Index abgebildet.
temp schrieb:> Mladen G. schrieb:>> Ob sich dieser Aufwand lohnt ist eine andere Frage, ich bevorzuge zB.>> CSV bzw. binaere Dateien mit festen strukturen fuer timeseries (4-5 GiB>> pro 3 Monate), weil das einfacher fuer mich ist.>> Volle Zustimmumg von mir. Das kann aber heute keiner mehr.
Oh, da täuschst du dich. Gerade bei größeren Datenmengen abseits der
Bereiche um die hier geredet wird stößt man auf immer wieder auf solche
scheinbar primitiven Lösungen. Da lieben z.B. PB an CSV-Dateien in S3
und werden linear mit Spark, https://prestodb.io oder Amazon Athena
durchgenudelt wenn man eine Analyse fahren will. Unter anderem weil man
nicht mal eben ein PostgreSQL-Cluster für 100 TB aufsetzt (und du da
auch nicht für jeden Anwendungsfall einen Index erstellen willst nur
weil Mitarbeiter X gerade nach Spalte Y filtern will).
mh schrieb:> Verstehst du etwas von Datenbanktechnik?
Tucholsky kannte noch keinen Datenbanker, hatte jedoch schon den
schlauen Spruch "Traue keinem Experten, der das immer schon so macht"...
Ein alter Kollege hatte 14 Tage Oracle-Lehrgang NUR zur DB-Optimierung.
Da geht noch was...
Niemandem fiel auf dass sich der Poster nie mehr meldete. Und trotzdem
bestehen viele Moechtegerne Datenbank Experten auf einer Datenbank...
schoen das wieder mal gesehen zu haben. Das war schon vor 30 Jahren so.
mh schrieb:> Sheeva P. schrieb:>> temp schrieb:>>> Man könnte sich auch solche Requests vorstellen: In welchem Jahr war der>>> kälteste Januartag am Aussensensor und wie hoch war an diesem Tag der>>> Gasverbrauch? Bei so was helfen Indexe (außer der Zeit die ein Array>>> auch hat) eines DBMS auch nicht wirklich und es muss auch dort jeder>>> Record im Januarbereich jedes Jahres durchgerödelt werden.>>>> Könnten wir uns bitte darauf einigen, daß Du die Datenbanktechnik Leuten>> überläßt, die etwas davon verstehen? Danke. :-)>> Verstehst du etwas von Datenbanktechnik?
Die einen sagen so, die anderen so. :-)
> Wie löst man das Problem bei> einer existierenden DB, die keinen passenden Index hat, ohne einen> passenden Index zu erstellen?
Das ist jetzt eine andere Aussage als die unseres Vorposters "temp". Er
behauptet, daß passende Indizes in einem solchen Fall "nicht wirklich
[...] helfen" würden, während Du bezweifelst, daß die Aufgabe ohne Index
lösbar ist. Nun, beide Behauptungen können wir doch einfach mal
überprüfen; ich habe nun einfach mal eine Tabelle erzeugt, mit Pythons
"faker"-Modul für jede Minute zwischen Epoch (1.1.1970, 00:00:00 Uhr)
und dem 1.1.2022 zufällige Daten erzeugt und eingetragen. Die Zeiten
beziehen sich auf einen AMD Ryzen 7 3800X mit 64 GB Arbeitsspeicher und
einer Samsung Evo 980 Pro mit Kubuntu 20.04 und PostgreSQL 12.6 in der
Standardkonfiguration des Distributors.
Die Tabelle sieht so aus:
und enthält insgesamt 27.349.921 Zeilen. Ohne Indizes benötigt die
Abfrage
1
EXPLAIN ANALYZE VERBOSE
2
SELECT sum(heat)
3
FROM gen
4
WHERE ts::date = (
5
SELECT ts::DATE
6
FROM gen
7
WHERE temp = (
8
SELECT min(temp)
9
FROM gen
10
WHERE extract(month from ts) = 1
11
)
12
);
ca. 1880 ms, also ca. 1,8 Sekunden. Damit wäre im Übrigen dann auch
schon Deine Frage geklärt, wie die Aufgabe ohne Indizes gelöst werden
kann: mit Subqueries. Untersuchen wir also mal die Behauptung von
"temp", daß Indices bei der Abfrage "nicht helfen" würden, und erstellen
uns zwei einfache Indices:
1
CREATE INDEX i1 ON gen (temp);
2
CREATE INDEX i2 ON gen (date(ts));
Jetzt benötigt die oben gezeigte Abfrage auf denselben Daten nurmehr ca.
57 ms, also 0.057 Sekunden. Holla, Faktor 32 -- also ich finde das nicht
schlecht für Indices, die angeblich "nicht helfen".
Aber das ist ja noch lange nicht das... Ende der Fahnenstange. Ein
probater Weg, um die Menge der zu verarbeitenden Datensätze zu
reduzieren, ist, sie in eine temporären Tabelle zu kopieren. Das
Elegante an so einer temporären Tabelle ist, daß sie -- wie der Name
schon sagt -- temporär ist, mithin: wenn die Verbindung des Client mit
dem Datenbankserver abgebaut wird, dann werden auch die temporäre
Tabelle mitsamt all ihren Indices etc. wieder verworfen. Also frisch ans
Werk, erzeugen wir uns eine temporäre Tabelle für die Januar-Monate und
legen die zwei Indices darauf an, die wir schon oben benutzt haben:
1
CREATE TEMPORARY TABLE t1 AS
2
SELECT * FROM gen WHERE extract(month FROM ts) = 1;
3
CREATE INDEX i3 ON t1 (temp);
4
CREATE INDEX i4 ON t1 (date(ts));
Wir benutzen dieselbe Abfrage wie oben, nur daß alle Vorkommen des
Tabellennamens "gen" nun durch den Namen der temporären Tabelle "t1"
ersetzt wird. Und außerdem können wir die Bedingung "WHERE extract(month
from ts) = 1" nun weglassen, denn diese Bedingung ist ja schließlich
durch die Auswahl der Daten unserer temporären Tabelle erfüllt. Jetzt
kommt unsere Abfrage auf eine Ausführungszeit von nurmehr 0,448 ms, also
0.0004 Sekunden. Mit diesem kleinen, einfachen Trick haben wir die
Ausführungszeit also nun um den Faktor(!) 4196(!) beschleunigt -- klar,
nur eine kleine Spielerei, aber sie zeigt: es geht zwar ohne Indices,
aber Indices helfen durchaus eine ganze Menge. q.e.d.
temp schrieb:> Sheeva P. schrieb:>> Könnten wir uns bitte darauf einigen, daß Du die Datenbanktechnik Leuten>> überläßt, die etwas davon verstehen? Danke. :-)>> Ich habe in meinem Leben schon viele Schwätzer gesehen die der Meinung> waren sie verstehen was von Datenbanktechnik.
Ja, mir auch, und Deine von mir mittlerweile auch praktisch widerlegte
Behauptung von oben, daß Indices in dem von Dir genannten Szenario nicht
helfen würden, lassen mich vermuten, daß dies für mich wieder einer
dieser Momente ist.
> Und dann kommen da> Datenbestände dabei raus die selbst in großen Firmen keiner mehr unter> Kontrolle hat
Was Du alles zu wissen glaubst... ;-)
> Je größer die Firma desto größer ist auch der Schiss der> verantwortlichen "Datenbankexperten" überhaupt Alternativen in Betracht> zu ziehen.
Genau... und deswegen war ich in diesem Thread auch bisher der Erste
und, sofern ich das richtig sehe, auch der Einzige, der diverse
alternative Datenbanksysteme aufgezeigt und beispielhaft erläutert hat,
wann diese sinnvoll sind.
> Bleibt man beim Platzhirsch-DBMS kann man ja nichts verkehrt> machen. Das muss perfekt sein und auch zu jedem Problem passen weil es> ja Unsummen an Geld kostet.
Das ist jetzt vor allem deswegen ganz besonders lustig, weil mein RDBMS
der Wahl natürlich PostgreSQL ist, das als OpenSource-Software kostenlos
bezogen werden kann und dennoch den Vergleich mit kommerziellen RDBMS
nicht scheuen muß.
> Und nebenbei verblödet man ohne es zu merken und schreibt im> MC-Forum schlaue Beiträge.
Mit diesem Thema kenne ich mich tatsächlich nicht aus; da Du dazu
offensichtlich auf einen reichhaltigen Erfahrungsschatz zurückgreifen
kannst, verlasse ich mich diesbezüglich gänzlich auf Deine Expertise.
Sheeva P. schrieb:> Das ist jetzt eine andere Aussage als die unseres Vorposters "temp". Er> behauptet, daß passende Indizes in einem solchen Fall "nicht wirklich> [...] helfen" würden, während Du bezweifelst, daß die Aufgabe ohne Index> lösbar ist.
Ich habe nie behauptet, dass es die gleiche Aussage ist. Ich habe eine
Frage gestellt. Ich habe nicht bezweifelt, dass es ohne Index lösbaar
ist.
Sheeva P. schrieb:> Damit wäre im Übrigen dann auch> schon Deine Frage geklärt, wie die Aufgabe ohne Indizes gelöst werden> kann: mit Subqueries.
Um auf die ursprüngliche Aussage von temp zurückzukommen: "es muss auch
dort jeder Record im Januarbereich jedes Jahres durchgerödelt werden.",
oder was macht
1
SELECT min(temp)
> uns zwei einfache Indices:> CREATE INDEX i1 ON gen (temp);> CREATE INDEX i2 ON gen (date(ts));>> Jetzt benötigt die oben gezeigte Abfrage auf denselben Daten nurmehr ca.> 57 ms, also 0.057 Sekunden. Holla, Faktor 32 -- also ich finde das nicht> schlecht für Indices, die angeblich "nicht helfen".
Wie lange dauert denn das erstellen der Indices?
> Jetzt> kommt unsere Abfrage auf eine Ausführungszeit von nurmehr 0,448 ms, also> 0.0004 Sekunden. Mit diesem kleinen, einfachen Trick haben wir die> Ausführungszeit also nun um den Faktor(!) 4196(!) beschleunigt
Und wie lange dauert es diese temporäre Tabelle zu erzeugen?
Sheeva P. schrieb:> Also frisch ans> Werk, erzeugen wir uns eine temporäre Tabelle für die Januar-Monate und> legen die zwei Indices darauf an, die wir schon oben benutzt haben:
Du musst ja ganz schön angefressen sein, aber deine Beispiele sind
lächerlich. Das was du an zusätzlichen Indices baust ist in etwa so als
würde ich meine Extracts in eine Datei schreiben. Oder am besten gleich
das gesamte Ergebnis. Dann ist aber nicht die Frage wieviel µs es dauert
das auszulesn, sonder die Zeit zum Erstellen.
Sheeva P. schrieb:> Das ist jetzt vor allem deswegen ganz besonders lustig, weil mein RDBMS> der Wahl natürlich PostgreSQL ist, das als OpenSource-Software kostenlos> bezogen werden kann und dennoch den Vergleich mit kommerziellen RDBMS> nicht scheuen muß.
Ich bin sehr selten mit dir einer Meinung, aber hier schon. PostgreSQL
ist sicherlich ein RDBMS der absoluten Spitzenklasse, dazu kostenlos und
ohne jegliche künstliche Einschränkungen nutzbar.
Das einzig Negative, was ich über PostgreSQL sagen könnte, ist der
(relativ kurz zurück liegende) Wechsel beim grafischen Verwaltungstool
von einer schnellen und überschaubaren lokalen Lösung zu einer
aufgeblähten (und natürlich durch die viele zusätzliche Komplexität
inhärent unsichereren) WebService-Scheiße.
Das ist sicherheitstechnisch der vorgrogrammierte GAU á la
Exchange-Server-Problem, welches kürzlich für Schlagzeilen sorgte.
Konzeptionell ist der Angriffsvektor in etwa der Gleiche. Es fehlt nur
die kleine Lücke, die ihn ausnutzbar macht. Angesichts der Komplexität
bin ich nahezu zu 100% sicher, dass sie existiert. Sie wurde nur noch
nicht gefunden...
mh schrieb:> Sheeva P. schrieb:>> Das ist jetzt eine andere Aussage als die unseres Vorposters "temp". Er>> behauptet, daß passende Indizes in einem solchen Fall "nicht wirklich>> [...] helfen" würden, während Du bezweifelst, daß die Aufgabe ohne Index>> lösbar ist.>> Ich habe nie behauptet, dass es die gleiche Aussage ist. Ich habe eine> Frage gestellt. Ich habe nicht bezweifelt, dass es ohne Index lösbaar> ist.
Deine Frage war:
"Wie löst man das Problem bei einer existierenden DB, die keinen
passenden Index hat, ohne einen passenden Index zu erstellen?"
Nun, Deine Frage ist jetzt wohl beantwortet, korrekt?
> Sheeva P. schrieb:>> Damit wäre im Übrigen dann auch>> schon Deine Frage geklärt, wie die Aufgabe ohne Indizes gelöst werden>> kann: mit Subqueries.> Um auf die ursprüngliche Aussage von temp zurückzukommen: "es muss auch> dort jeder Record im Januarbereich jedes Jahres durchgerödelt werden.",
Naaajaaa... nicht ganz. Seine Aussage war:
"Bei so was helfen Indexe (außer der Zeit die ein Array auch hat)
eines DBMS auch nicht wirklich und es muss auch dort jeder
Record im Januarbereich jedes Jahres durchgerödelt werden."
Nun, wir haben ja gesehen, daß Indices hier wirklich helfen, so daß die
Aussage als widerlegt anzusehen ist. Richtig?
> oder was macht>
1
> SELECT min(temp)
2
>
Einen Index-Only-Scan, wenn ein Index vorhanden ist.
>> uns zwei einfache Indices:>> CREATE INDEX i1 ON gen (temp);>> CREATE INDEX i2 ON gen (date(ts));>>>> Jetzt benötigt die oben gezeigte Abfrage auf denselben Daten nurmehr ca.>> 57 ms, also 0.057 Sekunden. Holla, Faktor 32 -- also ich finde das nicht>> schlecht für Indices, die angeblich "nicht helfen".> Wie lange dauert denn das erstellen der Indices?
Für 'i1' etwa 9348 ms, für i2 etwa 5803 ms.
>> Jetzt>> kommt unsere Abfrage auf eine Ausführungszeit von nurmehr 0,448 ms, also>> 0.0004 Sekunden. Mit diesem kleinen, einfachen Trick haben wir die>> Ausführungszeit also nun um den Faktor(!) 4196(!) beschleunigt> Und wie lange dauert es diese temporäre Tabelle zu erzeugen?
Etwa 1400 ms, und Indices darauf anzulegen dauert für ii1 (entspricht i1
auf gen) ca. 1123 ms, für ii2 ca. 928 ms.
Um dem erwartbaren freundlichen Hinweis vorzubeugen: ja, die Indices und
auch die temporäre Tabelle nutzen unter dem Strich natürlich nur dann
etwas, wenn man mehr als eine Abfrage darauf ausführt, für One-Shots
lohnt sich das nicht. Das war und ist mir und jedem, der was von
Datenbanken versteht und der damit arbeitet, klar -- hoffentlich
jedenfalls. Aber das betrifft ja weder Deine vorherige Frage, noch die
widerlegte Behauptung unseres Vorposters "temp".
temp schrieb:> Sheeva P. schrieb:>> Also frisch ans>> Werk, erzeugen wir uns eine temporäre Tabelle für die Januar-Monate und>> legen die zwei Indices darauf an, die wir schon oben benutzt haben:>> Du musst ja ganz schön angefressen sein,
Kein bisschen, ich wollt's nur wissen. Und natürlich auch mal schauen,
wie so ein ungetuntes PostgreSQL auf meiner neuen Büchse performt. ;-)
> aber deine Beispiele sind lächerlich.
Natürlich, aber zum Glück nicht halb so lächerlich wie Deine voherige
Behauptung. ;-)
Emil Kaiser schrieb:> Ich suche also Lösung, mit der ich eine Datenbank von gut 100 Millionen> einträgen verwalten kann, am Ende vermutlich um die 20GB groß
20GB? Das ist ein Witz, oder?
Lade den Mist ins RAM, und fertig ist der Lack.
c-hater schrieb:> Das einzig Negative, was ich über PostgreSQL sagen könnte, ist der> (relativ kurz zurück liegende) Wechsel beim grafischen Verwaltungstool> von einer schnellen und überschaubaren lokalen Lösung zu einer> aufgeblähten (und natürlich durch die viele zusätzliche Komplexität> inhärent unsichereren) WebService-Scheiße.
Ach, solche webbasierten Verwaltungswerkzeuge gibt es ja schon lange,
PHPMyAdmin für MySQL und Co., PhpPgAdmin für PostgreSQL. Pgadmin4 ist
zudem zunächst darauf ausgelegt, lokal betrieben zu werden, und bringt
dazu sogar eigens einen minimalen Webbrowser mit.
Andererseits wollen Kunden, insbesondere im Enterprise-Umfeld, zunehmend
weniger FatClients. Die für ihre jeweilige Deploymentlösung zu
paketieren, für jede neue Version neu, und sie auf eine Vielzahl von
Clientrechnern auszurollen, da haben etliche Kunden keine Lust mehr
'drauf.
Deswegen bevorzugen sie webbasierte Lösungen, die sie zentral
installieren und pflegen können. Und, mal ehrlich: HTTPS -- die
Kombination aus HTTP und TLS -- ist gut verstanden und etabliert,
Webserver, Webbrowser und Python sind es ebenso, da macht sich heute im
Unternehmen heute niemand mehr einen großen Kopf. Pgadmin4 ist aus
meiner Sicht ein guter und richtiger Schritt.
Sheeva P. schrieb:> Nun, Deine Frage ist jetzt wohl beantwortet, korrekt?
Ja, ohne passenden Index muss man den ganzen Speicher durchnudeln.
> Um dem erwartbaren freundlichen Hinweis vorzubeugen: ja, die Indices und> auch die temporäre Tabelle nutzen unter dem Strich natürlich nur dann> etwas, wenn man mehr als eine Abfrage darauf ausführt, für One-Shots> lohnt sich das nicht. Das war und ist mir und jedem, der was von> Datenbanken versteht und der damit arbeitet, klar -- hoffentlich> jedenfalls.
Gut, dass wir dafür einen Datenbankspezialisten gebraucht haben ...
mh schrieb:> Sheeva P. schrieb:>> Nun, Deine Frage ist jetzt wohl beantwortet, korrekt?> Ja, ohne passenden Index muss man den ganzen Speicher durchnudeln.
Du mußt Dich schon mit Dir selbst einigen, ob Du Deine Frage jetzt auf
die Behauptung unseres Vorposters beziehen wolltest oder nicht. ;-)
>> Um dem erwartbaren freundlichen Hinweis vorzubeugen: ja, die Indices und>> auch die temporäre Tabelle nutzen unter dem Strich natürlich nur dann>> etwas, wenn man mehr als eine Abfrage darauf ausführt, für One-Shots>> lohnt sich das nicht. Das war und ist mir und jedem, der was von>> Datenbanken versteht und der damit arbeitet, klar -- hoffentlich>> jedenfalls.> Gut, dass wir dafür einen Datenbankspezialisten gebraucht haben ...
Wenn Ihr was gelernt habt, ist das doch schön. ;-)
Sheeva P. schrieb:> Ach, solche webbasierten Verwaltungswerkzeuge gibt es ja schon lange,
Natürlich. Auch beim Exchange-Server gab es die schon lange. Das Debakel
geschah trotzdem (oder vielmehr: gerade deswegen).
Glaub' mir: Es ist keine Frage, ob es passiert. Es ist nur die Frage
wann. Wird dadurch gesteuert, wie attraktiv es für Blackhats ist, sich
mit dem Code auseinander zu setzen.
Ein einziger Finanzier, der eigentlich nur an einem einzigen konkreten
Ziel interessiert ist, kann das global auslösen, weil die Blackhats den
einmal gefundenen Angriff natürlich recyclen und auch für andere Zwecke
nutzen...
Das genau ist, was beim Exchange-Server passiert ist...
Sheeva P. schrieb:> Ach, solche webbasierten Verwaltungswerkzeuge gibt es ja schon lange,> PHPMyAdmin
...hat sich z.B. mehrfach durch ultimative Lücken ausgezeichnet. Ist
also quasi ein Beispiel par excelance, wie heiß die Scheisse ist...
Sheeva P. schrieb:> Etwa 1400 ms, und Indices darauf anzulegen dauert für ii1 (entspricht i1> auf gen) ca. 1123 ms, für ii2 ca. 928 ms.>> Um dem erwartbaren freundlichen Hinweis vorzubeugen: ja, die Indices und> auch die temporäre Tabelle nutzen unter dem Strich natürlich nur dann> etwas, wenn man mehr als eine Abfrage darauf ausführt, für One-Shots> lohnt sich das nicht. Das war und ist mir und jedem, der was von> Datenbanken versteht und der damit arbeitet, klar -- hoffentlich> jedenfalls. Aber das betrifft ja weder Deine vorherige Frage, noch die> widerlegte Behauptung unseres Vorposters "temp".
Also, ich habe eben auch mal ein paar Test gemacht mit meinem Beispiel
oben. 30Mio Datensätze a 64 Messstellen (int16_t) mit random Daten
gefüllt in eine binäre Datei. Das ergibt ca. 3.8GB Daten.
Die komplette Datei habe ich dabei in den Speicher gemappt und nicht
geladen, damit würde das auch auf einem Raspi(64bit) mit 1GB laufen.
Klar kann jetzt das Argument mit dem Cache kommen, aber von dem
profitiert eine Datenbank auch.
Die ganze Schleife besteht aus knapp 30 Zeilen Code und rödelt die knapp
ca. 100 Jahre in 0.14s durch auf einem betagen Wald und Wiesen Rechner.
Und dran denken, hier sind schon 64 Werte pro Record drin und nicht wie
bei dir einer. Versuch doch mal dein Beispiel für alle 64 Spalten
auszutesten und wie sehen die nötigen Indexe dann aus? 64 Indexe + einen
für den Timestamp?
Im übrigen will ich hier nicht gegen ausgewachsene Datenbanken meckern,
es geht hier nur um den einen geschilderten Anwendungsfall.
Ein weiter Vorteil ist für mich, das ganze compiliere ich in eine
einzige ausführbare Datei ohne weitere Abhängigkeiten, incl. Webserver.
Die paar wenigen nötigen Libs (openssl) werden statisch gelinkt. Rein
kommen die Daten per CAN-Bus. Damit entsteht ein minimalistisches System
das auch in der kleinsten busybox Umgebung läuft.
Emil Kaiser schrieb:> ich möchte ein Programm erstellen, dass zahlreiche Datensätze> liefert.> Mit dem Programm an sich hab ich keine Probleme. Die Daten sollten> allerdings in eine Datenbank übernommen werden und dort anschließend> ausgewertet.> Ich suche also Lösung, mit der ich eine Datenbank von gut 100 Millionen> einträgen verwalten kann, am Ende vermutlich um die 20GB groß>> Hat jemand eine Idee?
Aber, nach welchen Kriterien willst Du die Datenbank warten, pflegen und
aktuell halten?
temp schrieb:> Also, ich habe eben auch mal ein paar Test gemacht mit meinem Beispiel> oben. 30Mio Datensätze a 64 Messstellen (int16_t) mit random Daten> gefüllt in eine binäre Datei. Das ergibt ca. 3.8GB Daten.> Die komplette Datei habe ich dabei in den Speicher gemappt und nicht> geladen, damit würde das auch auf einem Raspi(64bit) mit 1GB laufen.> Klar kann jetzt das Argument mit dem Cache kommen, aber von dem> profitiert eine Datenbank auch.> Die ganze Schleife besteht aus knapp 30 Zeilen Code und rödelt die knapp> ca. 100 Jahre in 0.14s durch auf einem betagen Wald und Wiesen Rechner.
Wenn Deine 3.8 GB Daten auf einem beliebigen Persistierungsmedium liegen
und Du über diese kompletten Datensätze iterieren möchtest, ist mir kein
anderer Weg bekannt, als daß die gesamten Daten einmal gelesen werden
müssen -- ob jetzt per mmap(2), read(2) oder wie auch immer. Einmal die
Mathematik machen: wenn Du 3,8 GB Daten in 0.14 Sekunden einlesen
kannst, dann kann Deine Persistenzschicht also ca. 27 GB/s liefern, wenn
ich mich nicht verrechnet habe. Ziemlich netter "Wald und Wiesen
Rechner", würde ich sagen... ;-)
Nun kannst Du das natürlich über eine Art... nunja... eigenen "Index"
deutlich beschleunigen, weil Dir der Startzeitpunkt Deiner Daten und die
Häufigkeit, mit der Deine Daten anfallen und gespeichert werden, bekannt
sind. Dann kannst Du mit ein bisschen Hin- und Herrechnen die
Dateioffsets Deiner interessanten Datensätze berechnen und die dann
direkt anspringen... also, Du könntest das. Das wäre aber extrem
fehleranfällig, denn ich habe in Deiner Beschreibung keine(n)
Zeitstempel gesehen. Wenn Dir also einmal für einen bestimmten Zeitraum
Daten fehlen oder doppelt gespeichert wurden, dann funktioniert das mit
den Offsets leider nicht mehr korrekt und Du kannst es wegen des
fehlenden Zeitstempels auch nicht mehr überprüfen.
Nun ist das bei generierten Daten ja nicht das Thema, die sind immer
wunderbar gleichförmig, und es gibt weder Lücken noch Duplikate, wenn
man so etwas nicht absichtlich einbaut. Die Erfahrung lehrt, daß reale
Daten leider oft von einer gänzlich anderen... Qualität sind. Wenn mir
ein Kunde solche Daten geben würde, bekäme er schon nach einer ersten
Sichtung eine E-Mail von mir mit dem Hinweis, daß ich die Offsets leider
nicht überprüfen und für absolut korrekte Ergebnise darum leider nicht
garantieren kann.
> Und dran denken, hier sind schon 64 Werte pro Record drin und nicht wie> bei dir einer. Versuch doch mal dein Beispiel für alle 64 Spalten> auszutesten und wie sehen die nötigen Indexe dann aus? 64 Indexe + einen> für den Timestamp?
Du hattest oben von einem Außensensor und einer Heizung, und den Daten
für Januar... und jetzt auf einmal kommst Du mit etwas völlig anderem?
;-)
temp schrieb:> Für diesen Zweck ist die Zeit> dass Maß der Dinge. Alle 2min ein Record bei ca 100 Messstellen. Ich> wüsste nicht wozu ich dafür einen Index brauche.Sheeva P. schrieb:> Du hattest oben von einem Außensensor und einer Heizung, und den Daten> für Januar... und jetzt auf einmal kommst Du mit etwas völlig anderem?> ;-)
Nö, ich habe am Anfang von 100 geredet, den Test aber auf 64 begrenzt.
Sheeva P. schrieb:> Wenn Dir also einmal für einen bestimmten Zeitraum> Daten fehlen oder doppelt gespeichert wurden, dann funktioniert das mit> den Offsets leider nicht mehr korrekt und Du kannst es wegen des> fehlenden Zeitstempels auch nicht mehr überprüfen.
An welcher Position die Daten stehen bestimmt die Zeit. Ohne wenn und
aber. Zeitliche Lücken, wenn das System steht werden als solche
markiert, belegen aber den dafür vorgesehenen Bereich. Und soviel
Intelligez, dass der Timestamp mit drin steht und eine Kennung pro
Record kannst du mir ruhig zutrauen. Auch eine Checksumme passt in eine
fixe Struktur. Real habe ich bei mir aktuell nur 100 weil der Rest mit
solchen Sachen belegt ist. Aber es geht und ging hier hier nicht um
solche Details.
Um das von meiner Seite abzuschließen, meine Testergebnisse.
Ähnliche Daten wie Sheeva, also 27349921 Tupel aus Timestamp und zwei
Real und gespeichert als Array in ner Binärdatei.
Nen 30 Zeilen C++ Programm, dass die Daten per ifstream aus der Datei in
nen vector kopiert und das Ergebnis per min_element, equal_range und
accumulate bestimmt. Dabei nutze ich nur aus, dass die Daten
chronologisch geordnet sind. Die Möglichkeiten dabei einen Fehler zu
machen sind die gleichen wie beim Formulieren der SQL Abfrage.
Mit dem kleinen Bruder von Sheevas Rechner (Ryzen 3600, 32GB RAM,
Crucial MX500 SSD), komme ich auf 1600ms wenn die Datei sicher nicht im
Cache ist und 280ms wenn sie im Cache ist.
Hi ,
kannst Du das Script mir bitte mal zur Verfügung stellen ?
Gruß Ingo
Sheeva P. schrieb:> ich habe nun einfach mal eine Tabelle erzeugt, mit Pythons> "faker"-Modul für jede Minute zwischen Epoch (1.1.1970, 00:00:00 Uhr)> und dem 1.1.2022 zufällige Daten erzeugt und eingetragen. Die Zeiten
Ingo D. schrieb:> kannst Du das Script mir bitte mal zur Verfügung stellen ?
Selbstverständlich gerne, Du findest es im Anhang. Bitte beachte, daß es
die Module "faker" und "psycopg2-binary" benötigt, die Du in einem
Virtualenv mit "pip install faker psycopg2-binary" installieren kannst.
In Zeile 3 findest Du zudem die Angabe des Connectionstrings der
Datenbank in dem Format
die Du natürlich auf Deine Gegebenheiten anpassen mußt.
Außerdem möchte ich auf eine Neuigkeit in Zeile 31 hinweisen. Dort
benutze ich mit dem ":=" die neue "Assignment Expression" nach PEP 572
[1], so daß das Skript -- in dieser Form -- erst ab Python 3.8
funktioniert.
Solltest Du noch weitere Fragen zu den Skript haben, bist Du gerne
willkommen.
[1] https://www.python.org/dev/peps/pep-0572/
Hi Sheeva P,
super, vielen Dank !
Da komme ich gut mit klar,mit Python mache ich auch sehr viel.
Bin hier gerade im Dockerumfeld was am Testen, da kam mir das mit dem
Faker gerade recht.
also, Danke Dir und einen schönen Sonntagabend.
Gruß Ingo , DH1AAD
Was soll das Anrempeln ? Ein Array im Memory ist immer viel schneller
wie etwas auf einer Disk oder im Netzwerk.
Kann nur noch uebertroffen werden, wenn ich die Daten in eine GPU mit
2000 Kernen geladen bekomme... Denn die bringen ihre TB/s Speicher
bandbreite
Pandur S. schrieb:> Was soll das Anrempeln ? Ein Array im Memory ist immer viel> schneller> wie etwas auf einer Disk oder im Netzwerk.> Kann nur noch uebertroffen werden, wenn ich die Daten in eine GPU mit> 2000 Kernen geladen bekomme... Denn die bringen ihre TB/s Speicher> bandbreite
Ich bin auch sehr darüber erstaunt, dass das universelle System mit
Konsistenzgarantien, Transaktionsisolation, etc. nicht ganz mit einem
auf genau einen Anwendungsfall spezialisierten Code mithalten kann :)
Jemand schrieb:> Ich bin auch sehr darüber erstaunt, dass das universelle System mit> Konsistenzgarantien, Transaktionsisolation, etc. nicht ganz mit einem> auf genau einen Anwendungsfall spezialisierten Code mithalten kann :)
Und zur Sicherheit gehen wir noch davon aus, das universelle
Datenbanksystem liegt auf einer HDD von 1995, das Array allerdings im
RAM eines aktuellen HP Computers.
Cyblord -. schrieb:> Jemand schrieb:>>> Ich bin auch sehr darüber erstaunt, dass das universelle System mit>> Konsistenzgarantien, Transaktionsisolation, etc. nicht ganz mit einem>> auf genau einen Anwendungsfall spezialisierten Code mithalten kann :)>> Und zur Sicherheit gehen wir noch davon aus, das universelle> Datenbanksystem liegt auf einer HDD von 1995, das Array allerdings im> RAM eines aktuellen HP Computers.
Das ist fast das, was wir oben getestet haben, nur dass die DB auf dem
schnelleren Rechner läuft ...
Jemand schrieb:> Pandur S. schrieb:>> Was soll das Anrempeln ? Ein Array im Memory ist immer viel>> schneller wie etwas auf einer Disk oder im Netzwerk.
Wenn das Array dagegen serialisiert auf der Disk liegt, dann muß es vor
seiner Benutzung doch genauso gelesen und deserialisiert werden, wie die
SQL-Datenbank das auch machen muß. Hinzu kommt, daß die Indexe in der
SQL-Datenbank üblicherweise in einer zugriffsoptimierten Struktur, oft
einem Binärbaum, gespeichert werden.
>> Kann nur noch uebertroffen werden, wenn ich die Daten in eine GPU mit>> 2000 Kernen geladen bekomme... Denn die bringen ihre TB/s Speicher>> bandbreite>> Ich bin auch sehr darüber erstaunt, dass das universelle System mit> Konsistenzgarantien, Transaktionsisolation, etc. nicht ganz mit einem> auf genau einen Anwendungsfall spezialisierten Code mithalten kann :)
Wenn ich Sheevas Variante mit der temporären Tabelle betrachte, dann
sind seine 47 Millisekunden doch bislang ungeschlagen, oder? Noch nicht
einmal von dem besagten spezialisierten Code... Oder habe ich da etwas
verpaßt?
Jemand schrieb:> Wenn ich Sheevas Variante mit der temporären Tabelle betrachte, dann> sind seine 47 Millisekunden doch bislang ungeschlagen, oder? Noch nicht> einmal von dem besagten spezialisierten Code... Oder habe ich da etwas> verpaßt?
Klar hast du was verpennt, diese zusätzlichen Tabellen sind nichts
weiter als eine Vorverarbeitung der Daten und Speichern der Ergebnisse.
Die 47ms sind mehr oder weniger nur das Lesen der Ergebnisse aus der
Tabelle.
Sheeva P. schrieb:>> Und wie lange dauert es diese temporäre Tabelle zu erzeugen?>> Etwa 1400 ms, und Indices darauf anzulegen dauert für ii1 (entspricht i1> auf gen) ca. 1123 ms, für ii2 ca. 928 ms.
Das gleiche könnte ich mit 30 Zeilen Code auch lowlevel machen. Erst
danach können wir wieder die Zeiten vergleichen. Und wohl gemerkt, der
bisherige DBMS Test war für einen Messwert in der Tabelle. Ganz am
Anfang habe ich von 100 gesprochen, meinen binären Test dann auf 64
reduziert.
Jemand schrieb:> Wenn das Array dagegen serialisiert auf der Disk liegt, dann muß es vor> seiner Benutzung doch genauso gelesen und deserialisiert werden, wie die> SQL-Datenbank das auch machen muß.
Das stimmt so nicht. Das Array kann wie es ist 1zu1 von/in den Speicher
kopiert werden bzw. man mappt sich die gesamte Datei in den Speicher.
Der Rest ist simple Pointer/Array-Arithmetik. Und da wir nur die Januare
brauchen, muss man nur die Startpositionen der Januare ausrechnen und
von da an
betrachten. Es ist da nicht notwendig die gesamte Datei zu lesen. Mit
memory mapped files sorgt das Betriebssystem selbst dafür, dass nur die
Speicherbereiche aus der Datei gelesen werden, auf die über Pointer-
oder Arrayarithmetik zugegriffen wird. Wie oben schon erwähnt, das kann
am Ende nur eine GPU toppen. Alle anderen Varianten über Indexe sind für
diesen Zweck mehr oder wenig aufbereitete Zwischenergebnisse. Bei einem
(oder n) zusätslichen Indexen muss man auch die Zeit der Pflege der
Indexe bei jedem Record der hinzukommt berücksichtigen wenn man fair
bleiben will.
temp schrieb:> Jemand schrieb:>> Wenn ich Sheevas Variante mit der temporären Tabelle betrachte, dann>> sind seine 47 Millisekunden doch bislang ungeschlagen, oder? Noch nicht>> einmal von dem besagten spezialisierten Code... Oder habe ich da etwas>> verpaßt?>> Klar hast du was verpennt, diese zusätzlichen Tabellen sind nichts> weiter als eine Vorverarbeitung der Daten und Speichern der Ergebnisse.
Es ist ein bisschen enervierend, daß Du ständig wieder was Neues aus
Deinem Hut zauberst. Mal gibt es nur Array von 100 int16_t, mal eines
von 64, dann hast Du sowohl einen Zeitstempel als auch eine Prüfsumme in
jeder Zeile, und jetzt wieder nicht. Mach's doch einfach wie ich und
zeig' mal Deinen Code... und ein konkretes Beispiel für Deine Daten,
dann können mh und ich das auch einfach mal auf unseren Maschinen
übersetzen und mit passenden Zufallsdaten ausprobieren.
> Die 47ms sind mehr oder weniger nur das Lesen der Ergebnisse aus der> Tabelle.
Deine Behauptung war doch, nichts sei schneller als ein direkter Zugriff
auf ein Array. Ich habe gezeigt, daß es durchaus eine schnellere Methode
gibt, auch wenn sie durch die Vorselektion ein bisschen, nunja,
"getrickst" ist. Nichtsdestotrotz ist sie aber, schlicht und ergreifend:
schneller. Und zwar um Größenordnungen.
> Das gleiche könnte ich mit 30 Zeilen Code auch lowlevel machen.
Klar könntest Du. Dazu mußt Du dann wieder neuen Code entwickeln und
testen, während mein RDBMS das alles schon kann -- und zwar
benutzerfreundlich über die domänenspezifische Sprache SQL abgebildet,
die sogar fortgeschrittene Anwender häufig benutzen und bedienen können.
Aber das nur am Rande.
> Erst> danach können wir wieder die Zeiten vergleichen. Und wohl gemerkt, der> bisherige DBMS Test war für einen Messwert in der Tabelle. Ganz am> Anfang habe ich von 100 gesprochen, meinen binären Test dann auf 64> reduziert.
Ja, genau das meine ich mit "ständig etwas Neues". Zwischendurch hatten
Deine Daten auch einen Zeitstempel und eine Prüfsumme -- die hier, sowie
in Deiner Berechnung etwas weiter unten, jetzt aber schon wieder
verschwunden sind.
> Das stimmt so nicht. Das Array kann wie es ist 1zu1 von/in den Speicher> kopiert werden bzw. man mappt sich die gesamte Datei in den Speicher.
Mir ist auch noch nicht ganz klar, welchen Vorteil das Memory Mapping
für Dich haben soll. Auch ohne mußt Du ja nicht die ganze Datei in den
Speicher lesen, sondern kannst mit lseek(2) oder fseek(3) direkt die
gewünschten Offsets der Datei anspringen... So mußt Du die Datei also
auch nicht komplett lesen.
Übrigens, nur so ein Tipp: auch RDBMS wie PostgreSQL können mmap(2)
benutzen. Meines Wissens tun sie das sogar!
> Der Rest ist simple Pointer/Array-Arithmetik. Und da wir nur die Januare> brauchen, muss man nur die Startpositionen der Januare ausrechnen und> von da an>
> betrachten. Es ist da nicht notwendig die gesamte Datei zu lesen.
Diese Formel funktioniert natürlich nur für alle Monate, die kein
Februar sind. Aber so ein Februar kann ja mal 28 und mal 29 Tage haben,
so daß Deine Offsets anhand der jeweiligen Anzahl der Tage berechnen
müßtest. Aber gut, Deine Idee waren die Januare...
> Bei einem> (oder n) zusätslichen Indexen muss man auch die Zeit der Pflege der> Indexe bei jedem Record der hinzukommt berücksichtigen wenn man fair> bleiben will.
Naja, wenn Du auch fair bleiben willst, dann kommst Du mir diesem Ansatz
nicht besonders weit, wie ich oben bereits erwähnt habe. Denn Du gehst
einfach fest davon aus, daß Deine Daten immer absolut perfekt sind und
Du darum immer direkt genau die korrekten Positionen anspringen kannst.
Auf meinen vorherigen Hinweis, daß da keine Zeitstempel in Deinen
Datensätzen seien, hattest Du erklärt, daß da sehr wohl welche seien. In
dieser neuerlichen Beschreibung lese ich allerdings weder etwas von
Deinen Zeitstempeln, noch von den Prüfsummen, die Du eingebaut haben
willst. Und ich lese leider auch nichts von deren Überprüfung?!
Das Blöde ist halt, daß Deine ganze Geschichte unglaublich anfällig
gegen alle möglichen Arten von Fehlern ist -- jedoch lustigerweise
trotzdem nicht einmal ansatzweise so viel schneller als PostgreSQL, daß
sich Dein ganzer Aufwand auch nur ansatzweise lohnen würde. Für Deine
privaten Meßdaten ist das sicher eine nette kleine Fingerübung, aber für
wichtige Daten... nee, ne?
Stell' Dir vor, Du hast einen Stromausfall. Oder das Netzteil Deiner
Büchse raucht ab. Wir sind uns vermutlich einig, daß Dein Rechner nicht
in Deine Datei schreiben kann, wenn er mangels Stromversorgung gar nicht
läuft. (Und bitte, tu' mir einen Gefallen und komm' mir jetzt nicht mit
einer USV, ja? Danke.) Wenn Du solch eine Lücke in Deinen Daten hast,
dann stimmen Deine Offsets nicht mehr. Und wenn Du dem nicht mit wieder
neuen magischen Tricks vorbeugst, und auch Deinen Zeitstempel nicht
überprüfst, dann stimmen Deine Offsets ab diesem Zeitpunkt alle nicht
mehr. Und eigentlich ist es ja noch viel schlimmer, denn wenn Du nach
dem write(2) nicht noch einen fsync(2) durchführst, schreibt Dein
Datensammler doch nur in den Dateisystempuffer des Rechners, und Du
kannst nicht vorhersagen, wann und ob der Systemkernel die Daten
geschrieben hat.
Noch schlimmer wäre, wenn ein Problem während des konkreten
Schreibvorgangs auf die Festplatte auftritt. Denn dann wird ein
Datensatz womöglich unvollständig geschrieben. Selbst wenn dies nur
einen einzigen Datensatz beträfe, wären Deine Offsets und unter
Umständen sogar Deine ganzen Daten kaputt!
Schau, ich hab' auch schon C++' std::map für etwas benutzt, wo
PostgreSQL und Python zu langsam waren. Das ist ja gar nicht schlimm,
man muß halt wissen, was man tut. Für Deinen Anwendungsfall sehe ich den
Benefit des Handgeklöppelten nun allerdings wirklich nicht einmal im
Ansatz: ein Datenbanksystem, unabhängig davon ob das denn nun ein
klassisches SQL-RDBMS wie PostgreSQL, ein NoSQL-Datastore wie
Elasticsearch, oder ein In-Memory-Key-Value-Store wie Redis ist, sie
alle bieten eine deutlich höhere Datensicherheit, eine wesentlich
bessere Flexibilität, und können obendrein auch von sehr vielen
Nicht-Entwicklern genutzt werden. Das hat zwar alles nichts mit Deiner
ursprünglichen Aufgabe zu tun, aber man sollte der Fairneß halber darauf
hinweisen, wenn man jemandem wie dem TO sowas empfiehlt.
Sheeva P. schrieb:> Noch schlimmer wäre, wenn ein Problem während des konkreten> Schreibvorgangs auf die Festplatte auftritt. Denn dann wird ein> Datensatz womöglich unvollständig geschrieben. Selbst wenn dies nur> einen einzigen Datensatz beträfe, wären Deine Offsets und unter> Umständen sogar Deine ganzen Daten kaputt!
Das Problem hat man nur, wenn man grob fahrlässig oder bösartig vorgeht.
Und auch wenn du es nicht wahrhaben willst, kann ein Festplattenfehler
auch bei deiner DB zu Datenverlust führen.
Sheeva P. schrieb:> Schau, ich hab' auch schon C++' std::map für etwas benutzt, wo> PostgreSQL und Python zu langsam waren.
Das Geschwindigkeitsmonster std::map ;-)
> Das ist ja gar nicht schlimm,> man muß halt wissen, was man tut. Für Deinen Anwendungsfall sehe ich den> Benefit des Handgeklöppelten nun allerdings wirklich nicht einmal im> Ansatz:
Ich sehe keinen Vorteil von deinem DB-Ansatz, es sei denn man hat den
ganzen DB-Kram eh schon am Laufen.
> ein Datenbanksystem, unabhängig davon ob das denn nun ein> klassisches SQL-RDBMS wie PostgreSQL, ein NoSQL-Datastore wie> Elasticsearch, oder ein In-Memory-Key-Value-Store wie Redis ist, sie> alle bieten eine deutlich höhere Datensicherheit, eine wesentlich> bessere Flexibilität, und können obendrein auch von sehr vielen> Nicht-Entwicklern genutzt werden. Das hat zwar alles nichts mit Deiner> ursprünglichen Aufgabe zu tun, aber man sollte der Fairneß halber darauf> hinweisen, wenn man jemandem wie dem TO sowas empfiehlt.
Du musst dann aber auch fairerwaise darauf hinweisen, dass einiges an
Aufwand bedeutet, die DB zu konfigurieren und zu warten, Backups zu
erstellen, oder wenn man die Daten mal eben auf einem anderen Rechner
auswerten möchte.
Sheeva P. schrieb:> Das Blöde ist halt, daß Deine ganze Geschichte unglaublich anfällig> gegen alle möglichen Arten von Fehlern ist -- jedoch lustigerweise> trotzdem nicht einmal ansatzweise so viel schneller als PostgreSQL, daß> sich Dein ganzer Aufwand auch nur ansatzweise lohnen würde. Für Deine> privaten Meßdaten ist das sicher eine nette kleine Fingerübung, aber für> wichtige Daten... nee, neSheeva P. schrieb:> Noch schlimmer wäre, wenn ein Problem während des konkreten> Schreibvorgangs auf die Festplatte auftritt. Denn dann wird ein> Datensatz womöglich unvollständig geschrieben. Selbst wenn dies nur> einen einzigen Datensatz beträfe, wären Deine Offsets und unter> Umständen sogar Deine ganzen Daten kaputt!
Nimms mir nicht übel, aber ich kann dich nicht mehr enst nehmen. Wie ist
denn deine Datenbank mit 100erten Indexen und temp. Tabellen vor einem
Festplattencrash geschützt? Bei mir kann kein Offset kaput sein. Selbst
wenn nur ein halber Record geschrieben wird und 2 Tage später gehts
weiter, dann wird die Position zur Zeit berechnet und ab da gehts
weiter. Die Lücke wird mit 0en gefüllt und eine simple crc oder Kennung
sorgt dafür, zu kennzeichnen dass für diesen Zeitstempel keine gültigen
Daten vorliegen. Ich hab doch gesagt ein wenig Intelligenz ist bei der
ganzen Geschichte schon noch vorhanden, hier rede ich nur von
beispielhaften Basics.
Deinen ganze Abhandlung zur Datensicherheit kannst du in die Tonne
treten. Egal wie der Rechner abschmiert und ob ein sync gemacht wird
oder nicht. Mehr als ein paar wenige ungültige Daten kommen dabei nicht
zustande. Und ein (bei mir tägliches) Backup benötige ich genauso wie
jede andere DB.
Sheeva P. schrieb:> Das Blöde ist halt, daß Deine ganze Geschichte unglaublich anfällig> gegen alle möglichen Arten von Fehlern ist
Du hast überhaupt nichts verstanden.
Sheeva P. schrieb:> Ja, genau das meine ich mit "ständig etwas Neues". Zwischendurch hatten> Deine Daten auch einen Zeitstempel und eine Prüfsumme -- die hier, sowie> in Deiner Berechnung etwas weiter unten, jetzt aber schon wieder> verschwunden sind.
Sorry, glaubst du wirklich ich würde extra für dich hier realen Code
posten oder das gesamte Konzept diskutieren? Jedes Byte? Dazu bist du
viel zu polarisiert und voreingenommen. Es geht ums Prizip und nicht
realen Code. Ich beende jetzt auch die Diskussion mit dir wegen
Sinnlosigkeit. Ich muss dir nichts beweisen und du wirst mir für solche
trivialen Sachen kein DBMS aufschwatzen können. Aber du kannst schon mal
die Kanonen laden um damit auf Spatzen zu schießen.
ich finde es ja immer spannend, wenn man das letzte Quäntchen an Speed
aus bestehender Hardware holen will und ich habe das vor vielen Jahren
auch oft gemacht (das war dann auch in Assembler inkl. x86
Pointer-Arithmetik etc.).
Aber deine Argumentation scheint mir nur mehr um des vorher festgelegten
Standpunkts willen.
Entweder habe ich eine Hardware mit MMU und entsprechend Speicher und
SSD oder ich muss ev. auf einem ATMEGA 8-Bitter was abbilden.
Oder es ist eine sehr spezielle Datenstruktur, die man weder in SQL oder
NoSQL sinnvoll und schnell abbilden kann.
Natürlich steht es jedem frei, seine eigene DB zu bauen, wenn man die
Zeit und die Lust dazu hat, gerne.
Ich würde aber die Sinnhaftigkeit sehr stark anzweifeln.
Spätestens dann, wenn eine unvorhergesehene komplexere Abfrage kommt,
bin ich mir ziemlich sicher, dass eine eigene Implementation sehr sehr
viel Zeit in Anspruch nimmt und alleine die Test-Routinen für Konsistenz
und Sicherheit ein Vielfaches an Zeit ausmachen, was vergleichsweise
Einrichtung und Wartung einer DB ausmacht.
Von der Geschwindigkeit ganz zu schweigen.
Auch ein Raspi hat schon mehrere Kerne, es ist alles andere als easy,
flexible Routinen zu parallelisieren und dabei alle möglichen
Side-Effects zu berücksichtigen.
Ich verarbeite auf ganz normalen Servern (o.k. größer als Raspi)
stündlich zig Millionen neuer Datensätze.
Die landen am Ende alle in einer Postgres DB.
Ich hatte das Einlesen und Aufbereiten für die DB ursprünglich mit
python und numpy realisiert, das war recht ernüchternd.
Also dachte ich, dass ich das in C(++) selber besser hinkriege.
Das war zwar der Fall, spätestens ab dem Zeitpunkt, wo ich aber passende
python-Libraries gefunden und verwendet habe, hatte mein C-Code keine
Chance mehr.
Mag sein, dass ich das besser hingekriegt hätte, aber wie schon erwähnt,
multithreading kann sehr komplex werden, das würde ich mir ob des zu
erwartenden Perfomance-Gewinns nie mehr antun. Vermutlich würde ich den
gar nie lukrieren können, ohne Unmengen an Zeit zu investieren, wie man
spezifische CPU/OS-Features und Compiler entsprechend optimal ausnutzt.
Das machen nämlich bei Postgres, Elastic usw. Leute, die sich verm.
hauptsächlich auch mit solchen Dingen beschäftigen.
Aber vielleicht bist du ja der Wunderwuzzi, der das alles aus dem FF
beherrscht.
Für den TO reicht vermutlich eine sqlite-DB locker, wenn es akkumulative
Daten sind, kann ev. sogar ein rrdtool reichen.
Aber so komplex ist jetzt das Aufsetzen einer Postgres-/Maria- oder
Mongo-DB auch nicht.
Sollte das Ding mal wirklich skalieren müssen, dann wünsche ich dir
jedenfalls viel Spaß, in ein paar Zeilen C++ online-Replikation oder
Master-Slave zu programmieren....(IMHO wird es bei deinen 30 Zeilen
schon sehr eng, ein einigermaßen vernünftiges Locking zu implementieren,
die von anderen schon angesprochenen Fehlerfälle abzufangen, dürfte sich
nur äußerst rudimentär und entsprechend unsicher ausgehen)
Wie gesagt, kann man machen, aber warum sollte man... (verm. kann man
auch mit dem Ruderboot nach Australien kommen...)
Besser und vernünftig halte ich es aber auf keinen Fall...
@temp
btw.
Sheeva P. hat ja schon echte Messwerte geliefert, was ich von dir noch
immer vermisse.
Ich würde fast jede Wette eingehen, dass Postgres auch ohne Index
spätestens bei der zweiten Abfrage genauso schnell, wenn nicht schneller
wie deine 30 Zeilen Code ist. Spätestens dann, wenn die CPU mehr als
einen Core hat und sonst DB-mäßig nix tut (wie auch dein Code) und die
Abfrage (und so würde ich die Frage des TOs interpretieren) auch noch
parallelisierbar ist....
Außer du hüpfst uns vor, wie du in deinen wenigen Zeilen Code auch noch
flexibel mehrere CPUs nutzt (und ich da auch noch solche Dinge wie
parallel-setup-costs etc. setzen kann)
mh schrieb:> Das Problem hat man nur, wenn man grob fahrlässig oder bösartig vorgeht.> Und auch wenn du es nicht wahrhaben willst, kann ein Festplattenfehler> auch bei deiner DB zu Datenverlust führen.
Du verstehst aber schon, daß das zwar eine mögliche Fehlerquelle ist,
daß der Ansatz von "temp" aber über diese Fehlerquelle hinaus noch viele
weitere hat?
Zudem ist es natürlich so, daß meine wichtigen Daten auf einem RAID-1
liegen und zudem regelmäßig automatische Backups davon gemacht werden.
> Ich sehe keinen Vorteil von deinem DB-Ansatz, es sei denn man hat den> ganzen DB-Kram eh schon am Laufen.> [...]> Du musst dann aber auch fairerwaise darauf hinweisen, dass einiges an> Aufwand bedeutet, die DB zu konfigurieren und zu warten, Backups zu> erstellen, oder wenn man die Daten mal eben auf einem anderen Rechner> auswerten möchte.
Äh... bitte sei so lieb und denk' noch einmal darüber nach, was Du
gerade gesagt hast. Die Installation von PostgreSQL kostet mich keine
fünf Minuten ("apt-get install postgresql"). Die Backups macht rsnapshot
ohnehin ohne weiteres Zutun, und wenn ich mal eben von einem anderen
Rechner auf die Daten zugreifen möchte, dann spreche ich meinen
PostgreSQL-Server einfach übers Netzwerk an. Der kann das nämlich schon
von Hause aus, ist das nicht cool?
Unser oberschlauer Mitdiskutant dagegen muß alles selbst basteln.
Glaubst Du nicht auch, daß sein Selbstgehäkeltes einen wesentlich
höherer Entwicklungs-, Wartungs- und Pflegeaufwand benötigt als mein
PostgreSQL? Wenn nicht, dann benötigt natürlich kein Mensch auf der Welt
ein RDBMS, und es ist ein Rätsel, warum Oracle, IBM, SAP, Microsoft und
andere dafür kommerzielle Produkte im Portfolio haben und wohl auch ganz
gut daran verdienen.
Schau, wie ich -- immer noch als Einziger -- schon oben in meinem ersten
Beitrag schon geschrieben habe, gibt es verschiedene
Datenspeichersysteme, die für verschiedene Arten von Daten mehr oder
weniger gut geeignet sind. Im Prinzip ist das, was "temp" da
verarbeitet, wohl prädestiniert für ein Append-Only-Log wie eine
Zeitseriendatenbank, oder für einen Hybriden wie Elasticsearch. Aber
alle diese Lösungen sind für die Implementierung und Wartung mit
Sicherheit weniger aufwändig als alles selbst zu frickeln.
temp schrieb:> Nimms mir nicht übel, aber ich kann dich nicht mehr enst nehmen.
Das darfst Du gerne halten, wie Du magst.
> Du hast überhaupt nichts verstanden.
Ach, weißt Du, da haben wir leider eher ein Sender- als ein
Empfängerproblem. Ich lese sehr genau, was Du schreibst, aber es ist
halt a) immer wieder etwas anderes und b) immer nur höchstens ein
Viertel dessen was zu einem sinnvollen Verständnis minimal notwendig
wäre. Und auch jetzt wieder, auf gezielte Nachfrage mit einigen
Beispielen, was bei Deinem Gefrickel alles schiefgehen kann, zauberst Du
plötzlich wieder irgendetwas aus dem Hut...
Nehmen wir mal an, daß das alles so stimmt, was Du hier erzählst. Daß Du
Dir also wirklich Gedanken gemacht und ungefähr den hundertfachen
Aufwand betrieben hast, etwas zu basteln, das es bereits fertig gibt und
das seine Stabilität, Sicherheit, und Performanz seit Jahrzehnten in
hunderttausenden Installation bewiesen hat. Wenn das alles so stimmt,
wie Du es Dir bei Bedarf aus dem Ärmel zauberst: wäre es dann nicht
klug, fair, und sinnvoll, es dem TO auch vollständig mitzuteilen, wenn
Du ihm so eine Lösung empfiehlst?
Emil Kaiser schrieb:> am Ende vermutlich um die 20GB groß
Wenn man sehr viele Messdaten und deren Erfassungszeitpunk abspeichern
möchte, sollte die Datenbank die Messdaten am besten gleich etwas
komprimieren (XOR+Huffman oder so).
Ist denn dafür TimescaleDB oder InfluxDB besser geeignet?
zagge schrieb:> Sollte das Ding mal wirklich skalieren müssen, dann wünsche ich dir> jedenfalls viel Spaß, in ein paar Zeilen C++ online-Replikation oder> Master-Slave zu programmieren....(IMHO wird es bei deinen 30 Zeilen> schon sehr eng, ein einigermaßen vernünftiges Locking zu implementieren,
Alleine dass du das Wort Locking erwähnst, zeugt von kompletter
Ahnungslosigkeit. Zeitreihendaten und noch dazu in festen Rastern sind
die simpelsten Daten die man sich vorstellen kann. Und alles in der
Vergangenheit ist statisch bzw. readonly. Außerdem gibt es nur eine
einzige Instanz die die Daten schreibt. Was soll man da vor was locken?
Sheeva P. schrieb:
Ich werde auf deine ständigen Wiederholungen der gleichen Phrasen nicht
mehr antworten.
zagge schrieb:> Ich würde fast jede Wette eingehen, dass Postgres auch ohne Index> spätestens bei der zweiten Abfrage genauso schnell, wenn nicht schneller> wie deine 30 Zeilen Code ist.
Wenn du wetten willst, geh auf die Rennbahn...
zagge schrieb:> Außer du hüpfst uns vor, wie du in deinen wenigen Zeilen Code auch noch> flexibel mehrere CPUs nutzt
Multithreading muss ich ja per se schon machen, da die Anwendung auch
httpd(s)-Server spielen muss da die Requests sowieso parallel in
mehreren Threads auflaufen können. Bei Requests auf statischen Daten ist
an der Stelle aber nicht mal ein Mutex oder eine andere Synchronisation
nötig.
zagge schrieb:> Für den TO reicht vermutlich eine sqlite-DB locker
Um den geht es hier schon lange nicht mehr, oder hat der sich nochmal
gemeldet?
zagge schrieb:> Sollte das Ding mal wirklich skalieren müssen, dann wünsche ich dir> jedenfalls viel Spaß, in ein paar Zeilen C++ online-Replikation oder> Master-Slave zu programmieren
Vergiss es, davon war und wird nie die Rede sein. Und selbst wenn, es
gibt nur eine einzige Datendatei an die nur angehängt wird. Da reicht
rsync aus um das zu replizieren. Und das kopieren einer einzigen
ausführbaren Datei, mehr gibt es nämlich nicht.
zagge schrieb:> Spätestens dann, wenn eine unvorhergesehene komplexere Abfrage kommt
Wo soll die herkommen wenn nicht von mir? Und wenn sie von mir kommt,
dann ist sie nicht unvorhersehbar. Der schlaue Sheeva muss für sowas
sogar temp. Dateien und Indexe anlegen. Und am Ende bleibt irgendwann
auch nur noch übrig durch die Datenbank zu rödeln.
Sheeva P. schrieb:> Noch schlimmer wäre, wenn ein Problem während des konkreten> Schreibvorgangs auf die Festplatte auftritt.Jemand schrieb:> Wo genau wird von einem Festplattencrash geschrieben? Strohmann?
Kannst du lesen, B...mann?
temp schrieb:> Alleine dass du das Wort Locking erwähnst, zeugt von kompletter> Ahnungslosigkeit. Zeitreihendaten und noch dazu in festen Rastern sind> die simpelsten Daten die man sich vorstellen kann. Und alles in der> Vergangenheit ist statisch bzw. readonly. Außerdem gibt es nur eine> einzige Instanz die die Daten schreibt. Was soll man da vor was locken?
Ach ja, wie stellst du denn sicher, dass dein ganzer Satz geschrieben
ist, bevor du das nächste Mal zugreifst?
Es mag ja nur eine Instanz geben, die schreibt (warum eigentlich die
Einschränkung?), es könnten aber mehrere Quellen Eintrage-Requests
schicken, wer kümmert sich dann um die Queue? Ich hoffe wohl nicht der
httpd-Part....
> zagge schrieb:>> Ich würde fast jede Wette eingehen, dass Postgres auch ohne Index>> spätestens bei der zweiten Abfrage genauso schnell, wenn nicht schneller>> wie deine 30 Zeilen Code ist.>
temp schrieb:
> Wenn du wetten willst, geh auf die Rennbahn...
Vielleicht ist dir klar geworden, dass auch DBs wie Postgres eine Suche
soweit als möglich optimieren und Daten recht optimal so lange wie
möglich auch im RAM durchsuchen können. Und zusätzlich Statistiken
führen, bei welcher Abfrage welche Organisations- und Suchmethode am
effizientesten ist und entsprechend dynamisch den passenden Algo nehmen.
Es macht nämlich einen großen Unterschied ob du einzelne Datensätze
haben willst, wie die sortiert sein sollen, oder ob du z.B. min max
Werte raussuchen willst.
Anders kann ich mir deine Antwort nicht erklären.
temp schrieb:
> Multithreading muss ich ja per se schon machen, da die Anwendung auch> httpd(s)-Server spielen muss da die Requests sowieso parallel in> mehreren Threads auflaufen können. Bei Requests auf statischen Daten ist> an der Stelle aber nicht mal ein Mutex oder eine andere Synchronisation> nötig.
Ich rede hier nicht vom http-Server (wieviel Zeilen Code braucht denn da
was halbwegs Funktionables, ohne dass man auf "fette" Libraries usw.
zurückgreift?), sondern vom Eintragen in dein und dem Suchen aus deinem
"File". Klar kann man das Array auf mehrere Threads aufsplitten, um das
zu beschleunigen, aber schon schreibt man wieder Code der von der
Datenstruktur abhängig ist und damit kaum wiederverwendbar ist.
Wie du parallele "Eintrage-Requests" ohne Locking machen willst, ist so
oder so schleierhaft.
> zagge schrieb:>> Sollte das Ding mal wirklich skalieren müssen, dann wünsche ich dir>> jedenfalls viel Spaß, in ein paar Zeilen C++ online-Replikation oder>> Master-Slave zu programmieren
temp schrieb:
> Vergiss es, davon war und wird nie die Rede sein. Und selbst wenn, es> gibt nur eine einzige Datendatei an die nur angehängt wird. Da reicht> rsync aus um das zu replizieren. Und das kopieren einer einzigen> ausführbaren Datei, mehr gibt es nämlich nicht.>
Ahja, und wie willst du ohne Locking sicherstellen, dass rsync nicht
grad dann läuft, wenn du grad einträgst?
> zagge schrieb:>> Spätestens dann, wenn eine unvorhergesehene komplexere Abfrage kommt
temp schrieb:
> Wo soll die herkommen wenn nicht von mir? Und wenn sie von mir kommt,> dann ist sie nicht unvorhersehbar. Der schlaue Sheeva muss für sowas> sogar temp. Dateien und Indexe anlegen. Und am Ende bleibt irgendwann> auch nur noch übrig durch die Datenbank zu rödeln.
Nehmen wir mal den durchwegs nicht unwahrscheinlichen Fall an, dass im
Laufe der Zeit neue Sensoren dazu kommen:
In deinem Fall änderst du deinen Core-Code, im anderen fügst du im
Großen und Ganzen einfach ein (paar) DB-Feld(er) dazu.
Rate mal, was fehleranfälliger und aufwändiger ist...
Wenn man das selbst und dann auch noch wie du effizient machen will, ist
es nicht mit einfachen Auffüllen von Nullen in den archivierten Daten
getan...(btw. man sollte dann natürlich auf keinen Fall vergessen rsync
neu anzustarten, die nächste unnötige Fehlerquelle).
Von ev. zusätzlichen Quellen, die asyncron eintragen könnten, rede ich
noch nicht mal...
zagge schrieb:> Ach ja, wie stellst du denn sicher, dass dein ganzer Satz geschrieben> ist, bevor du das nächste Mal zugreifst?
Wozu sollte ich das müssen? Wenn was fehlt gibts den ganzen Record halt
noch nicht.
> Es mag ja nur eine Instanz geben, die schreibt (warum eigentlich die> Einschränkung?), es könnten aber mehrere Quellen Eintrage-Requests> schicken, wer kümmert sich dann um die Queue? Ich hoffe wohl nicht der> httpd-Part....
Wenns der httpd-Part wäre, wären es ja mehr. Nein, das kommt alles per
CAN rein, und da der Rechner nur 1 CAN-Interface hat, ist auch nur 1
Thread damit beschäftigt und der langweilt sich zu Tode.
zagge schrieb:> Ahja, und wie willst du ohne Locking sicherstellen, dass rsync nicht> grad dann läuft, wenn du grad einträgst?
Siehe oben, gleicher Sachverhalt. Da in den Dateien niemals was geändert
wird, kann es nur das Ende betreffen, fehlt was wird es halt nicht
beachtet.
zagge schrieb:> Nehmen wir mal den durchwegs nicht unwahrscheinlichen Fall an, dass im> Laufe der Zeit neue Sensoren dazu kommen:
Ok, wenn sie vom Himmel fallen hast du recht. Machen sie aber nicht.
Erstens gibt es eine Reserve und wenn das nicht reicht, läuft eine
kleines Programm einmal offline über die Dateien und passt das an. War
bei mir in den vergangenen 10 Jahren aber nicht nötig.
zagge schrieb:> im anderen fügst du im> Großen und Ganzen einfach ein (paar) DB-Feld(er) dazu.
Und ein paar Indexe sowie temp. Tabellen lt. dem anderen Schlaumeier.
Ausserdem haben zusätzliche Sensoren eine Aufgabe die im gesamten System
abgebildet werden müssen. Wenn ich einen Wasserzähler neu hinzufüge,
will ich den ja auch irgendwie visuell wiederfinden. Datenpflege ist da
das simpelste und das was am wenigsten Zeit braucht. Ich ändere
insgesamt nur in einem Programm. Die Datenbankexperten ändern die DB,
das Programm was die Daten einpflegt und in einer schönen Scriptsprache
daherkommt sowie den Webserverteil in PHP, Java oder Javascript.
Kann man machen, ich mach's eben anders.
zagge schrieb:> Rate mal, was fehleranfälliger und aufwändiger ist...
Da brauch ich nicht raten. Mag sein, dass dein Horizont nur soweit
reicht, aber schließ nicht von dir auf andere.
zagge schrieb:> Ich rede hier nicht vom http-Server (wieviel Zeilen Code braucht denn da> was halbwegs Funktionables, ohne dass man auf "fette" Libraries usw.> zurückgreift?), sondern vom Eintragen in dein und dem Suchen aus deinem> "File".
Um den httpd Server geht es hier nicht, den habe ich selbst geschrieben
ohne fette xy-Lib, Ausnahme openssl und zlib. Und wer nicht mal einen
simplen httpd-Server programmieren kann, sollte sich nicht Programmierer
nennen.
> Klar kann man das Array auf mehrere Threads aufsplitten, um das> zu beschleunigen, aber schon schreibt man wieder Code der von der> Datenstruktur abhängig ist und damit kaum wiederverwendbar ist.
Sorry, an die Grenze komme ich frühestens mit der zig-fachen Anzahl an
Messstellen.
> Wie du parallele "Eintrage-Requests" ohne Locking machen willst, ist so> oder so schleierhaft.
Warum musst du 5mal in einem Post den gleichen Mist schreiben? Lerne mal
ein paar Tage lowlevel zu Programmieren, da lernst du mehr als beim
Zusammenstöpseln von fetten Komponenten.
temp schrieb:> Jemand schrieb:>> Wo genau wird von einem Festplattencrash geschrieben? Strohmann?> Kannst du lesen, B...mann?
Ich helfe dir gerne bei deinem offensichtlichen Bildungsdefizit:
https://de.wikipedia.org/wiki/Strohmann-Argument
Die geschilderte Ausgangssituation ist:
Sheeva P. schrieb:
> Noch schlimmer wäre, wenn ein Problem während des konkreten> Schreibvorgangs auf die Festplatte auftritt.
d. h. von irgendwelchen kritischen Hardwarefehler ist überhaupt nicht
notwendigerweise die Rede, eher übliche Fehlermodi wie ein plötzlicher
Stromausfall. Wieviele bereits existierende Daten können dabei
zerstört werden? DBMS nutzen hier spezielle Techniken (z. B.
WAL-Logging), um Datenverlusten vorzubeugen, warum werden diese in
deinem Fall nicht benötigt? Auf Basis welcher Garantien?
Jemand schrieb:> d. h. von irgendwelchen kritischen Hardwarefehler ist überhaupt nicht> notwendigerweise die Rede, eher übliche Fehlermodi wie ein plötzlicher> Stromausfall. Wieviele bereits existierende Daten können dabei> zerstört werden? DBMS nutzen hier spezielle Techniken (z. B.> WAL-Logging), um Datenverlusten vorzubeugen, warum werden diese in> deinem Fall nicht benötigt? Auf Basis welcher Garantien?
Von mir aus können die DBMS da veranstalten was sie wollen, ich habe das
nicht nötig. Punkt. Es wird alle 2min genau 1 Record auf Platte
geschrieben. Und genau der kann bei Stromausfall zur Hälfte oder
garnicht oder mit Müll drin auf Platte landen. Und wo ist das Problem?
Nach dem Fehler gehts beim nächsten Schreiben an der Position weiter wo
der Record hingehört. Klar, dazwischen steht was weiss ich was, aber das
ist eindeutig detektierbar. Wenn ich den Rechner aus mache habe ich auch
"Lücken" im File die ich berücksichtigen muss. Das sind völlig andere
Verhältnisse als bei einer komplexen Dateistruktur oder eines Indexes.
Da reicht ein falsches Byte und die Tabelle/der Index ist Schrott. Und
solange dein super DBMS nur auf dem normalen Filesystem aufgesetzt ist,
stirbt das im Ernstfall genauso mit. Das ganzen Geschwafel über mögliche
Datenverluste ist doch ein völliger Nebenkriegsschauplatz. Jedenfalls
für den beschriebenen Zweck. Wenn mir die Daten wichtig sind, brauche
ich eine vernünftige Backupstrategie oder Onlinereplikation egal wie das
DBMS heisst.
Jemand schrieb:> Ich helfe dir gerne bei deinem offensichtlichen Bildungsdefizit:> https://de.wikipedia.org/wiki/Strohmann-Argument
Der, und nur der Punkt geht an dich.
temp schrieb:> Von mir aus können die DBMS da veranstalten was sie wollen, ich habe das> nicht nötig. Punkt. Es wird alle 2min genau 1 Record auf Platte> geschrieben.
Also betreibst Du den ganzen Aufwand für... genau: nichts. Premature
optimization is the root of all evil. Und wer mir erzählen will, daß er
mal schnell "lowlevel" einen Webserver schreibt... alles Gelaber, Du
hast überhaupt nichts. Darum kannst Du auch nichts vorzeigen. ;-)
Sheeva P. schrieb:> Und wer mir erzählen will, daß er> mal schnell "lowlevel" einen Webserver schreibt... alles Gelaber, Du> hast überhaupt nichts. Darum kannst Du auch nichts vorzeigen. ;-)
Ich kann dir zu mindestens etwas vom Ergebnis zeigen. Sämtliche
Bestandteile sind von mir lowlevel geschrieben als da wären:
- Modbus-Communikation zu 2 Wechselrichtern
- eBus Protokoll zum Vaillant Heizkessel (da gibt es auch auf GitHub nur
Raspi-Lösungen)
- Komminikation zu einem SDM630 Energiezähler und zum 2-Richtungszähler
der TEAG
- Steuerung der Brauchwasserwärmepumpe
- Steuerung des selbst gebauten AC gekoppelten LiFePo4 Speichers für die
Solaranlage
- Regelung der beiden INV350/60 Modulwechselrichter um beim Akkubetrieb
auf 0 zu Regeln
- ca. 15 CAN Knoten die dafür sorgen das alles per CAN in den Rechner
kommt
- 15 Rfm02 Sensoren (Sensoren, Bewegungsmelder), 8 AM Modulierte
Temperatursensoren S555, 4 per Lora, auf Funk umgerüstete Personenwage
- Sender für 6 Funksteckdosen (Obi,Intertechno) für die
Weihnachtsbaumbeleuchtung
das ganze wird von 3 verteilten Empfängern bedient in in den CAN Bus
eingespeisen.
....
Singel File Executable zur Verwaltung der Daten und Httpd-Server
Kurz vor der Rente kann man von seinem Erfahrungsschatz leben und
schreibt auch nicht jede Zeile Code ständig neu.
Wie du sehen kannst, dauert die Datenaufbereitung incl. AJAX-Request zu
einer virtuellen energie.js 69ms.
temp schrieb:> Ich kann dir zu mindestens etwas vom Ergebnis zeigen.
Sehr schick! Gefällt mir.
Aber ein Favicon hättest du schon noch auf den Server schieben können 😅
DBaseAmnesia schrieb:> Ist denn dafür TimescaleDB oder InfluxDB besser geeignet?
TimescaleDB funktioniert sehr gut, damit bin ich sehr zufrieden. Und
dazu noch den vollen Power von Postgres. Meiner Meinung nach einer der
besten (OpenSource)-Lösungen in dieser Ecke.
Mit InfluxDB habe ich gemischte Erfahrungen. Triviale Dinge, mit nicht
zu großen Datenmengen, funktionieren recht gut. Doch wehe die
Kardinalität ist etwas höher, oder die Abfragen werden etwas komplexer,
dann bricht das Ding zusammen.
An Postgres (mit TimescaleDB) kommt vieles nicht ran. Ist ja auch kein
Wunder, sind schließlich Jahrzehnte an Optimierungen drin.
temp schrieb:> zagge schrieb:>> Ach ja, wie stellst du denn sicher, dass dein ganzer Satz geschrieben>> ist, bevor du das nächste Mal zugreifst?> Wozu sollte ich das müssen? Wenn was fehlt gibts den ganzen Record halt> noch nicht.
Achja und dafür machst du (was auch immer einen CRC) über das gesamte
File ???
Und wann kann dann der nächste Request was reinschreiben??
>>> Es mag ja nur eine Instanz geben, die schreibt (warum eigentlich die>> Einschränkung?), es könnten aber mehrere Quellen Eintrage-Requests>> schicken, wer kümmert sich dann um die Queue? Ich hoffe wohl nicht der>> httpd-Part....>> Wenns der httpd-Part wäre, wären es ja mehr. Nein, das kommt alles per> CAN rein, und da der Rechner nur 1 CAN-Interface hat, ist auch nur 1> Thread damit beschäftigt und der langweilt sich zu Tode.>
hmm nur weil es nur ein CAN-Interface gibt, heißt das bei weitem noch
nicht, dass nur ein Sender da ist.....
> zagge schrieb:>> Ahja, und wie willst du ohne Locking sicherstellen, dass rsync nicht>> grad dann läuft, wenn du grad einträgst?>> Siehe oben, gleicher Sachverhalt. Da in den Dateien niemals was geändert> wird, kann es nur das Ende betreffen, fehlt was wird es halt nicht> beachtet.>
hmm du willst ja so effizient als möglich sein, mit rsync inplace hast
du da am Ende nur mehr Schrott..., abgesehen davon dass es äußerst
nieffizient ist (wo dir du ja immer die Fahne der Effizienz anheftest
), ganze File zu transferieren...
> zagge schrieb:>> Nehmen wir mal den durchwegs nicht unwahrscheinlichen Fall an, dass im>> Laufe der Zeit neue Sensoren dazu kommen:>> Ok, wenn sie vom Himmel fallen hast du recht. Machen sie aber nicht.> Erstens gibt es eine Reserve und wenn das nicht reicht, läuft eine> kleines Programm einmal offline über die Dateien und passt das an. War> bei mir in den vergangenen 10 Jahren aber nicht nötig.
o.k. wenn die letzten 10 Jahre nix dazu gekommen ist, dann mag das ja
passen, realistisch ist es aber eher nicht...
Und was bitte ist eine Reserve (1 Byte/2Bytes/2Kbytes)?
>> zagge schrieb:>> im anderen fügst du im>> Großen und Ganzen einfach ein (paar) DB-Feld(er) dazu.> Und ein paar Indexe sowie temp. Tabellen lt. dem anderen Schlaumeier.
ich bin mir sehr sicher, dass die Indexe und die Temp-Tabellen zwar was
bringen, aber das System auch ohne diese schneller und sicherer
funktionieren wird wie deine Lösung.
> Ausserdem haben zusätzliche Sensoren eine Aufgabe die im gesamten System> abgebildet werden müssen. Wenn ich einen Wasserzähler neu hinzufüge,> will ich den ja auch irgendwie visuell wiederfinden. Datenpflege ist da> das simpelste und das was am wenigsten Zeit braucht. Ich ändere> insgesamt nur in einem Programm. Die Datenbankexperten ändern die DB,> das Programm was die Daten einpflegt und in einer schönen Scriptsprache> daherkommt sowie den Webserverteil in PHP, Java oder Javascript.> Kann man machen, ich mach's eben anders.>
Hmm, bisher änderst du Offsets, greist per Pointer irgenwdow hin, wer
das mag...
Sei dir unbestritten, wenn wer vom MVC-Modell unbedingt abweichen will,
sei es jedem freigestellt. Ich frage mich halt, wie du mit deiner
Methode wiederverwertbaren Code und Tests fahren willst...
> zagge schrieb:>> Rate mal, was fehleranfälliger und aufwändiger ist...> Da brauch ich nicht raten. Mag sein, dass dein Horizont nur soweit> reicht, aber schließ nicht von dir auf andere.>
nochmal, ich verzichte auf Beleidigungen, wie du sie machst.
Auch ich habe lange Zeit monolithische Programme geschrieben, die vielen
Ansprüchen genügen mussten (RAM, Adressbereich, Geschwindigkeit...)
Nur die Zeiten sind im Großen und Ganzen vorbei (außer man muss was auf
einem 8Bit-ATMega o.ä machen...)
Ich für mich gestehe ein, dass ich keine Ahnung habe, wie ich das letzte
Quentchen aus den aktuellen CPUs rauspressen könnte...
> zagge schrieb:>> Ich rede hier nicht vom http-Server (wieviel Zeilen Code braucht denn da>> was halbwegs Funktionables, ohne dass man auf "fette" Libraries usw.>> zurückgreift?), sondern vom Eintragen in dein und dem Suchen aus deinem>> "File".> Um den httpd Server geht es hier nicht, den habe ich selbst geschrieben> ohne fette xy-Lib, Ausnahme openssl und zlib. Und wer nicht mal einen> simplen httpd-Server programmieren kann, sollte sich nicht Programmierer> nennen.>
hmm, sowie sich da anhört, wäre ein Link auf deinen http-Server-Code ja
vielleicht recht nützlich. Wäre sehr gespannt, ob du da was besser wie
viele Community Projekte hingekriegt hättest....
Ich für mich halte einen "simplen" httpd-Server der auch sicher und
schnell sein sein soll, alles andere als einfach...
Aber du kannst gern mal deine Benchmarks vs. nginx & Co.
veröffentlichen, möglicherweise wirst du reich....
>> Klar kann man das Array auf mehrere Threads aufsplitten, um das>> zu beschleunigen, aber schon schreibt man wieder Code der von der>> Datenstruktur abhängig ist und damit kaum wiederverwendbar ist.> Sorry, an die Grenze komme ich frühestens mit der zig-fachen Anzahl an> Messstellen.
hmm du hast ja die Performance deines Codes gepriesen, die dürfte also
nur für single-Threads zutreffen? Allein der Raspi hat vier Cores....
Nun sind wir hier im MC-Forum, aber auch der 2€ ESP hat zwei Cores....
>> Wie du parallele "Eintrage-Requests" ohne Locking machen willst, ist so>> oder so schleierhaft.> Warum musst du 5mal in einem Post den gleichen Mist schreiben? Lerne mal> ein paar Tage lowlevel zu Programmieren, da lernst du mehr als beim> Zusammenstöpseln von fetten Komponenten.
Weil du IMHO nicht verstanden hast, was Datenintegrität bedeutet..
Du hast geschrieben, dass man kein Locking braucht....
Nach meiner Meinung programmierst du wirklich lowlevel, ich habe noch
Ampelsteuerungen (im Auftrag für ganze Städte) auf der PDP-11 (z.T. in
Assembler) programmiert. Lowlevel bedeutet nicht gut. Möglicherweise
weiß man manchmal eine bessere Lösung als alle anderen, der Normalfall
ist das nicht. Weil es nämlich Leute gibt, die sich explizit mit
bestimmten Themen auseinandersetzen, das kann eine Einzelperson IMHO nie
erreichen.
Dein Ansatz ist, auch wenn gut gemeint einfach, aber nicht zielführend
....und das wird auch für dich irgendwie ausreichen, es ist nur
unglaublich kompliziert, nicht sinnvoll erweiterbar und auf keinen Fall
ein "best practcse" Beispiel.
zagge schrieb:> Dein Ansatz ist, auch wenn gut gemeint einfach, aber nicht zielführend> ....und das wird auch für dich irgendwie ausreichen, es ist nur> unglaublich kompliziert, nicht sinnvoll erweiterbar und auf keinen Fall> ein "best practcse" Beispiel.
Auf dein anderes Geschreibsel was du zum x-ten mal wiederholst gehe ich
nicht mehr ein. Und ob das für mich kompliziert ist oder erweiterbar
oder "best practce" kannst du nicht beurteilen. Den Thread-Starter gibt
es nicht mehr, und dich nehme ich nicht mehr ernst weil du nur Sprüche
und Wiederholungen klopfen kannst. Also am besten zu mit dem Theard.
zagge schrieb:> Achja und dafür machst du (was auch immer einen CRC) über das gesamte> File ???
Über was ihr euch streitet, ist mir egal, zur Sache habe ich aber
Mitteilungsbedürfnis.
Man kann eine CRC nicht nur über die komplette Datei machen, sondern
auch pro Datensatz. Das sind z.B. 4 kleine Bytes. Oder man macht eine
CRC alle N Datensätze. Praktischerweise kann man eine CRC (oder etwas
mehr) auch pro "Block" machen, wie auch immer man einen Block definiert.
Blöcke macht man praktischerweise eine fixe Größe, optional mit Start-
und End-Pattern um auch verlorene Bytes (im PC-Bereich selten, bei
seriellen Protokollen durchaus möglich) zu erkennen und zu beheben.
Wenn die Datensätze historisch monoton gespeichert sind, spielt es auch
keine Rolle wenn Datensätze mit unterschiedlicher Häufigkeit in
bestimmten Zeitbereichen anfallen. Mit einer heuristischen Suche kommt
man in diesen Fällen sehr schnell durch die Daten, und/oder man hält nur
einen Bruchteil der Daten im RAM, z.B. 1%. Das wären bei 100 GB Daten
nur 1 GB im RAM. Zusätzlich aggregiert man die üblichen Auswertungen
auch auf Partitionen. Solche Aggregate können wiederum hierarchisch
aggregiert werden.
Die Spielwiese ist riesig, und für bestimmte Spezialanwendungen auch
absolut notwendig. Ob man es bei einem Feld-Wald-Wiesen-System machen
muss/soll, ist fraglich. Die Fälle wo man sich einen bestimmten
Transistor herstellen lässt, sind eher selten. Statt dessen nimmt man
was es schon fertig gibt.
So auch bei den Daten. Eine ernste Datenbank macht viele dieser Dinge
automatisch. Solange das ausreicht, nehme ich lieber den Komfort und die
Universalität. Solche Lösungen kann auch jeder andere ohne weitere
Einarbeitung, verstehen. Auch ein sehr wichtiger Punkt.
temp schrieb:> Egal wie der Rechner abschmiert und ob ein sync gemacht wird> oder nicht. Mehr als ein paar wenige ungültige Daten kommen dabei nicht> zustande.
Bei den üblichen DBMS hast du keine ungültige Daten wenn der PC
abschmiert.
So etwas wie einen 50% erfolgreichen commit hab ich noch nicht gesehen.
Gegen halb kaputte Dateisysteme und SSDs helfen Prüfsummen die man aber
z.B. bei postgres einmalig aktivieren muss (pg_checksums -e).
Experte schrieb:> DBaseAmnesia schrieb:>> Ist denn dafür TimescaleDB oder InfluxDB besser geeignet?>> TimescaleDB funktioniert sehr gut, damit bin ich sehr zufrieden. Und> dazu noch den vollen Power von Postgres. Meiner Meinung nach einer der> besten (OpenSource)-Lösungen in dieser Ecke.>> Mit InfluxDB habe ich gemischte Erfahrungen. Triviale Dinge, mit nicht> zu großen Datenmengen, funktionieren recht gut. Doch wehe die> Kardinalität ist etwas höher, oder die Abfragen werden etwas komplexer,> dann bricht das Ding zusammen.>> An Postgres (mit TimescaleDB) kommt vieles nicht ran. Ist ja auch kein> Wunder, sind schließlich Jahrzehnte an Optimierungen drin.
Vielen Dank für den prima Tipp mit Timescaledb, das ist wirklich schick.
Nachdem die InfluxDB-Leute den Mund auf ihrer Website ja recht voll
nehmen haben, hab' ich mir die Software (in der mit Kubuntu 20.04 LTS
gelieferten Version 1.6.4 einmal installiert und meine mit dem oben
erwähnten Python-Script erzeugten Daten mal 1:1 in die InfluxDB
übertragen. Danach mußte ich leider feststellen, daß ich leider keine
Möglichkeit gefunden habe, im SQL-Dialekt von InfluxDB eine Abfrage auf
die Zeitserien eines bestimmten Monats zu machen, was ich schon
hinreichend unelegant fand...
Einige Zwischenschritte und Versuche später hatte ich eine Lösung, indem
ich den ersten und letzten Timestamp geholt, daraus eine Liste der Jahre
gemacht und diese dann mit
1
first = dateparse(next(infl.query(
2
'''SELECT time, first(temp) FROM gen;''').get_points())['time'])
3
last = dateparse(next(infl.query(
4
'''SELECT time, last(temp) FROM gen;''').get_points())['time'])
5
where = ' OR '.join([
6
"""(time > '{}-01-01 00:00:00' AND time < '{}-02-01 00:00:00')"""\
7
.format(i, i)
8
for i in range(first.year, last.year+1)])
9
query = 'SELECT count(*) FROM gen WHERE {}'.format(where)
zu einem Query mit einer drölfzig Kilometer langen WHERE-Klausel
zusammengebaut, was dann einen... enorm schlechten Eindruck bei mir
hinterlassen hat. Aber dann kam die eigentliche Höhe: der Query lieferte
keine Ergebnisse. Mit zwei bis drei Klauseln funktioniert das auch, aber
mit den vielen... schiet: keine Ergebnisse, aber auch keine
Fehlermeldung. Das hat mir gereicht, "apt-get purge".
TimescaleDB dagegen war eine ganz andere Nummer: PPA eingetragen,
Apt-Schlüssel importiert, installiert, create_hypertable()... Der oben
in meinem Beitrag [1] gezeigte Query braucht ohne Indices nicht mehr
1800, sondern nurmehr knapp 1200 Millisekunden, mit Indices sogar
nurmehr ca 10 statt wie zuvor 57. Das find ich bei einem ausgereiften
RDBMS wie PostgreSQL schon recht beeindruckend... und, wohlgemerkt: ohne
Optimierungen! Danke für diesen feinen Tipp! ;-)
[1] Beitrag "Re: riesige Datenbank verwalten"
Thread beobachten
Seitenaufteilung abschalten