Forum: PC Hard- und Software riesige Datenbank verwalten


von Emil Kaiser (Gast)


Lesenswert?

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?

von Andreas B. (bitverdreher)


Lesenswert?

Das kann eigentlich jede Datenbank.

von g457 (Gast)


Lesenswert?

> 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

von Udo S. (urschmitt)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Udo S. (urschmitt)


Lesenswert?

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.

von Purzel H. (hacky)


Lesenswert?

Falls die Datensaetze gleich, oder aehnlich gross waeren, wuerde auch 
ein Array auf einem Stream taugen, welches schliesslich noch etwas 
schneller waere.

von xxxyyy (Gast)


Lesenswert?

DBMS wie DB2 oder oracle haben auch mit 20TB kein Problem.
Postgres macht Sinn.

von Klaus P. (Gast)


Lesenswert?

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

von Sheeva P. (sheevaplug)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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
von Sheeva P. (sheevaplug)


Lesenswert?

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.

von kleiner Admin (Gast)


Lesenswert?

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.

von Purzel H. (hacky)


Lesenswert?

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
von MaWin (Gast)


Lesenswert?

Purzel H. schrieb:
> Ein Array ist ja schon indexiert.

Soll das nun ein Aprilscherz sein oder blanke Unwissenheit ?

von Udo S. (urschmitt)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.
von oszi40 (Gast)


Lesenswert?

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

von Jim M. (turboj)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

(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. ;-)

von Proktologe (Gast)


Lesenswert?

Emil Kaiser schrieb:
> vermutlich um die 20GB groß
> Hat jemand eine Idee?

Ein Textfile

von Datenbanken mit Excel sind toll!!! (Gast)


Lesenswert?

Mit Excel

von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Datenbanken mit Excel sind toll!!! schrieb:
> Mit Excel

Excel ist KEINE Datenbank.

SCNR

von Andreas B. (bitverdreher)


Lesenswert?

100Ω W. schrieb:
> Excel ist KEINE Datenbank.

Warum nur wurde Access bisher nicht erwähnt?

von Cyblord -. (cyblord)


Lesenswert?

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?

von Mladen G. (mgira)


Lesenswert?

Postgres schafft das ohne mit der Wimper zu zucken.
Wenn es richtig schnell gehen soll, mal den COPY Befehl probieren.

: Bearbeitet durch User
von Andreas B. (bitverdreher)


Lesenswert?

Cyblord -. schrieb:
> Weil Access auch keine Datenbank ist, sondern eher ein Frontend?

Dein Ironiedetektor ist kaputt.

von Sheeva P. (sheevaplug)


Lesenswert?

Jim M. schrieb:
> Jede, wenn die Informationen die man sucht nicht im Array Index
> abgebildet sind.

...nicht in EINEM Array-Index... ;-)

von temp (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von mh (Gast)


Lesenswert?

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?

von Schlaumaier (Gast)


Lesenswert?

Andreas B. schrieb:
> Das kann eigentlich jede Datenbank.

Das muss heißen : Das kann eigentlich jede SQL Datenbank.

von Schlaumaier (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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
von mh (Gast)


Lesenswert?

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?

von Schlaumaier (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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))

von Εrnst B. (ernst)


Lesenswert?

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

von mh (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Markus W. (mawinter)


Lesenswert?

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?

von mh (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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.

von Mladen G. (mgira)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

(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

von mh (Gast)


Lesenswert?

(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.

von temp (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von Sebastian W. (wangnick)


Lesenswert?

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

von Mladen G. (mgira)


Lesenswert?

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
von mh (Gast)


Lesenswert?

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.

von Mladen G. (mgira)


Lesenswert?

Ich hab keine Widersprueche gesehen :)

wollte nur darauf eingehen dass Dinge oft zu komplex geloest werden, und 
kompliziert werden Dinge von selber

von Sheeva P. (sheevaplug)


Lesenswert?

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. :-)

von mh (Gast)


Lesenswert?

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?

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> dauert 10s.
Das finde ich gar nicht so schlecht, Volltextsuchen wie "like %[blah]%" 
sind ein echter Performance-Killer.

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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....

von temp (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Andreas (Gast)


Lesenswert?

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).

von oszi40 (Gast)


Lesenswert?

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...

von Pandur S. (jetztnicht)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von mh (Gast)


Lesenswert?

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?

von temp (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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...

von Sheeva P. (sheevaplug)


Lesenswert?

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".

von Sheeva P. (sheevaplug)


Lesenswert?

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. ;-)

von Experte (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von mh (Gast)


Lesenswert?

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 ...

von Sheeva P. (sheevaplug)


Lesenswert?

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. ;-)

von c-hater (Gast)


Lesenswert?

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...

von c-hater (Gast)


Lesenswert?

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...

von temp (Gast)


Lesenswert?

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.

von Dr. Pin (Gast)


Lesenswert?

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?

von Sheeva P. (sheevaplug)


Lesenswert?

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? 
;-)

von temp (Gast)


Lesenswert?

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.

von mh (Gast)


Lesenswert?

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.

von Ingo D. (ingo2011)


Lesenswert?

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

von Sheeva P. (sheevaplug)


Angehängte Dateien:

Lesenswert?

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/

von Ingo D. (ingo2011)


Lesenswert?

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

von Pandur S. (jetztnicht)


Lesenswert?

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

von Jemand (Gast)


Lesenswert?

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 :)

von Cyblord -. (cyblord)


Lesenswert?

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.

von mh (Gast)


Lesenswert?

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 ...

von Jemand (Gast)


Lesenswert?

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?

von temp (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von mh (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von Jemand (Gast)


Lesenswert?

temp schrieb:
> Tabellen vor einem
> Festplattencrash geschützt?

Wo genau wird von einem Festplattencrash geschrieben? Strohmann?

von zagge (Gast)


Lesenswert?

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...

von zagge (Gast)


Lesenswert?

@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)

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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?

von DBaseAmnesia (Gast)


Lesenswert?

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?

von temp (Gast)


Lesenswert?

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?

von zagge (Gast)


Lesenswert?

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...

von temp (Gast)


Lesenswert?

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.

von Jemand (Gast)


Lesenswert?

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?

von temp (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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. ;-)

von temp (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Rene K. (xdraconix)


Lesenswert?

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 😅

von Experte (Gast)


Lesenswert?

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.

von zagge (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von Experte (Gast)


Lesenswert?

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.

von data shredder (Gast)


Lesenswert?

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).

von Sheeva P. (sheevaplug)


Lesenswert?

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
Noch kein Account? Hier anmelden.