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?
> Hat jemand eine Idee? man DBMS [1], anschließend [1], danach HF. [0] https://de.wikipedia.org/wiki/DBMS [1] https://de.wikipedia.org/wiki/Liste_der_Datenbankmanagementsysteme
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.
DBMS wie DB2 oder oracle haben auch mit 20TB kein Problem. Postgres macht Sinn.
20GB sind heutzutage eher Durchschnitt, nicht mehr "riesig" - also kein Grund, Geld auszugeben. PostgreSQL kann das "locker": https://wiki.postgresql.org/wiki/FAQ#What_is_the_maximum_size_for_a_row.2C_a_table.2C_and_a_database.3F
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 Performance 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. 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Purzel H. schrieb: > Ein Array ist ja schon indexiert. Soll das nun ein Aprilscherz sein oder blanke Unwissenheit ?
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.
Beitrag #6648658 wurde von einem Moderator gelöscht.
Beitrag #6648670 wurde von einem Moderator gelöscht.
Beitrag #6648674 wurde von einem Moderator gelöscht.
Beitrag #6648677 wurde von einem Moderator gelöscht.
Beitrag #6648732 wurde von einem Moderator gelöscht.
Emil Kaiser schrieb: > um die 20GB groß Die kannst Du doch fast im RAM verwalten. Es darf dann bloß niiie der Strom fehlen. :-) https://administrator.de/forum/transaktionssicherung-schl%C3%A4gt-fehl-190618.html
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?
Postgres schafft das ohne mit der Wimper zu zucken. Wenn es richtig schnell gehen soll, mal den COPY Befehl probieren.
:
Bearbeitet durch User
Cyblord -. schrieb: > Weil Access auch keine Datenbank ist, sondern eher ein Frontend? Dein Ironiedetektor ist kaputt.
Jim M. schrieb: > Jede, wenn die Informationen die man sucht nicht im Array Index > abgebildet sind. ...nicht in EINEM Array-Index... ;-)
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?
Andreas B. schrieb: > Das kann eigentlich jede Datenbank. Das muss heißen : Das kann eigentlich jede SQL Datenbank.
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.
:
Bearbeitet durch User
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))
Schlaumaier schrieb: > Kann aber je nach > DB-Größe etc. einige Zeit dann dauern. Also nix für "mal eben" dafür hat Postgres z.B. "CREATE INDEX CONCURRENTLY", dann geht das Index-Aufbauen ohne Exclusive-Table-Lock. https://www.postgresql.org/docs/current/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY
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. ;-)
:
Bearbeitet durch User
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:
1 | 2021-04-06 16:53:32.129211 +0200 MESZ | {"hl": 2, "hw": "W5500_MEGA_V02", "id": "5656616E6742", "ip": "192.168.6.127", "ms": 166324150, "sw": "w5500_optolink_httpboot_13.ino, Feb 1 2021 21:45:53", "AuG": 4.3, "AuI": 4, "AuT": 3.9, "B1S": 91687948, "B1Z": 0, "B2S": 1955951, "B2Z": 0, "BrE": 0, "BrN": 197737, "BrU": 0, "Fr1": 255, "H1P": 1, "KeI": 63.8, "KeT": 63.7, "MaT": 170.5, "OeT": 4379.42, "Py1": 0, "S1F": 28.1, "S1T": 22.5, "S4F": 30.6, "S4T": 21.7, "S6F": 71.5, "S6T": 2.7, "S7F": 75.5, "S7T": 1.6, "S8F": 27.5, "S8T": 18, "S9F": 1.4, "S9T": 0.8, "SaE": 0, "Sp1": 0, "SpI": 58.2, "SpP": 0, "SpS": 60, "SpT": 58.3, "Tim": "2021040602164515", "W1A": 3, "ZiP": 0, "cycle": 2773, "topic": "haus", "tsred": "2021-04-06T14:53:32.106Z", "garage": {"ms": 433935998, "sw": "lueftung06.ino, Aug 27 2020 16:01:22", "c0c": 28929, "c0f": 87.1, "c0n": "Zu", "c0t": 0.8, "c1c": 28929, "c1f": 61.5, "c1n": "Wa", "c1t": 15.1, "c2c": 28929, "c2f": 64.8, "c2n": "Ab", "c2t": 6.4, "c3c": 28929, "c3n": "Mi", "c3t": 14.8, "c4c": 28929, "c4n": "Ob", "c4t": 15.9, "c5c": 28929, "c5n": "Hz", "c5t": 15.3, "clk": 433936, "fan": 0, "cycle": 28929, "msend": 433946001, "recms": 166313232, "topic": "garage"}} | 3543342 |
2 | 2021-04-06 16:53:32.299663 +0200 MESZ | {"hw": "iom328pb.h,16000000L,16000000L", "id": 6661, "ms": 337680029, "no": 5, "sw": "valvecontrol08.ino,Mar 19 2021 08:47:39,10813", "vcc": 352, "rain": 0, "topic": "valvebox", "touch": 0, "tsred": "2021-04-06T14:53:32.298Z", "thhumi": 94.6, "thtemp": 3.4, "rain_ms": 10, "valve,1": "DISCONNECT", "valve,2": "DISCONNECT", "valve,3": "DISCONNECT", "thlastms": 337679564, "rain_stat": 1, "rain_lowms": 0} | 3543343 |
Abfrage
1 | 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.
:
Bearbeitet durch User
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.
Ich hab keine Widersprueche gesehen :) wollte nur darauf eingehen dass Dinge oft zu komplex geloest werden, und kompliziert werden Dinge von selber
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?
> dauert 10s.
Das finde ich gar nicht so schlecht, Volltextsuchen wie "like %[blah]%"
sind ein echter Performance-Killer.
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:
1 | CREATE TABLE gen(id SERIAL PRIMARY KEY, ts TIMESTAMP, temp REAL, heat REAL); |
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
1 | postgresql://<username>:<password>@<hostname>/<dbname> |
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
1 | 31Tage*720Einträge/Tag*sizeof(int16_t)*Anzahl Messtellen |
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 >
1 | > 31Tage*720Einträge/Tag*sizeof(int16_t)*Anzahl Messtellen |
2 | >
|
> 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, ne 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! 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.
temp schrieb: > Tabellen vor einem > Festplattencrash geschützt? Wo genau wird von einem Festplattencrash geschrieben? Strohmann?
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"
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.