Ich habe auch nur einen Teil gesehen, daher meine Frage
Was den Speicherplatz angeht, habe ich von einem Verhältnis von etwa 1/3 gehört… Stimmt das?
Wenn es also schneller ist und weniger Speicherplatz benötigt, was hält uns dann auf?
Entwicklung und Tests oder gibt es noch technische Fragen (Migration)?
Und ich habe es nicht gesagt, aber… Danke für das Live-Coding!
@guim31 : Zu diesem Zeitpunkt testete er mit 3 Jahren Daten, denn mit 1 Jahr und 300 Daten sah man den Unterschied nicht so deutlich.
Deshalb wollte er 10 Millionen Daten senden, um es besser zu sehen.
@GBoulvin : Nein, der Unterschied ist sehr groß,
am Anfang des Videos war es ein Faktor 12,
am Ende hat man 1,4 GB für SqlLite und 33 MB für Duck…
Es ist ein großes Entwicklungsprojekt, aber Pierre-Gilles ist interessiert und wird sich wahrscheinlich darum kümmern, aber er sagt nicht, dass man vor mehreren Monaten nichts erwarten kann.
Mein Fehler!
Der Unterschied ist so groß, dass ich dachte, ich hätte mich verhört (oder @pierre-gilles hätte falsch gelesen ) und es wären 330 MB
Das würde alle Probleme mit kleinen Hardware lösen… Speicher, Backup, Grafikerstellung…
Am Ende des Lives hatte die DB 1,3 GB für die aktuelle Implementierung im Vergleich zu 33 MB bei DuckDB
DuckDB ist extrem leistungsfähig bei der Berechnung aggregierter Daten „live“ direkt auf den Rohdaten. Wir können den Aggregationsprozess alle Stunden freigeben.
Eine Grenze bei DuckDB: max. 1 Client pro DB. Keine Möglichkeit, eine bereits geöffnete DB zu lesen, vielleicht nicht praktisch für die Entwicklung, aber kein Problem für Gladys.
Es gibt jedoch noch einige Dinge zu testen:
Unterstützt DuckDB das gleiche Schreibvolumen wie SQLite? DuckDB ist nicht der beste beim Schreiben, es ist für das Lesen/Analysieren großer Volumen gemacht, aber nicht unbedingt für große Schreibvolumen. Vielleicht müssen wir auf eine „periodische“ Batch-Schreibung umsteigen (z. B. max. 1 Schreibvorgang pro Sekunde)
Ist DuckDB genauso stabil/robust wie SQLite? SQLite ist eines der robustesten Programme der Welt (Ihre Testmethodik ist ziemlich beeindruckend, für diejenigen, die sich dafür interessieren: How SQLite Is Tested). DuckDB ist letzte Woche in Version 1.0 erschienen. Ich denke, wir müssen unsere eigenen Tests in der Praxis durchführen und DuckDB etwas Zeit geben, um alle kleinen Bugs zu beheben, die mit dem Übergang zu 1.0 entdeckt werden. Es wird wahrscheinlich eine 1.0.1 geben. Bisher scheint die Stabilität von Gladys „gesichert“, aber ein vorzeitiger Wechsel zu DuckDB könnte diese Stabilität gefährden. Für mich müssen wir bei diesem Schritt sehr sorgfältig sein. Wir haben es nicht eilig, für den Endbenutzer wird es ohnehin kaum einen Unterschied geben
Informationen zum Verbindungssystem einholen, ist es besser, eine Verbindung pro DuckDB-Client zu haben, oder eine Schreibverbindung/eine Leseverbindung, oder einen Pool von N Verbindungen? Testen in der Praxis mit gleichzeitigen Schreib-/Lesevorgängen.
Informationen zum Backup-/Wiederherstellungsprozess einholen? Ohne Ausfallzeit oder mit Unterbrechung?
Anschließend auf der Entwicklungsebene:
Das gesamte Schreib-/Lese-System ordnungsgemäß codieren (der Live von heute Morgen war nur ein Proof of Concept zum Testen, nichts Ernstes)
Das Backup und die Wiederherstellung der Datenbank über Gladys Plus codieren. Wie kann man rückwärtskompatibel mit den bestehenden Backups bleiben?
Die Migration aller bestehenden Daten zu DuckDB und die Löschung der Daten in SQLite codieren. Wie kann man ein VACUUM durchsetzen, ohne Gladys bei den bestehenden Benutzern zu lange auszuschalten? Ziel ist eine minimale Dienstunterbrechung.
Kurz gesagt, es sieht sehr vielversprechend aus, aber es gibt viel zu tun Ich bin sehr motiviert, es zu tun, aber es wird Zeit in Anspruch nehmen.
Ich werde jedoch bald eure Hilfe benötigen, um mit euren Daten zu testen (außerhalb eurer Produktionsumgebungen, versteht sich).
Ein weiterer beeindruckender Test heute Morgen: Ich habe eine CSV-Datei mit 50 Millionen Zeilen für 5 Sensoren über die letzten 3 Jahre mit zufälligen Werten erstellt.
Die Datei ist genau 3,0 GB groß:
pierregilles staff 3.0G Jun 21 10:33 output.csv
Ich habe ein kleines Skript geschrieben, das die CSV-Datei mit der DuckDB-CSV-Import-API importiert:
CREATE TABLE device_feature_state AS
SELECT * FROM read_csv('output.csv');
Die CSV-Datei wird in 3,34 Sekunden eingelesen:
[ { Count: 50000000n } ]
start: 3.348s
Die DuckDB-Datei ist nur 75 MB groß!
pierregilles staff 75M Jun 21 10:34 imported_from_csv.duckdb
@Hizo In der CSV gibt es viel Redundanz, von den 50 Millionen Zeilen gibt es nur 5 verschiedene Sensor-UUIDs, die jeweils 10 Millionen Mal wiederholt werden.
Jeder Kompressionsalgorithmus erkennt solche Muster und eliminiert den Großteil des Gewichts, indem er jeden UUID nur einmal speichert. Von 50 Millionen auf 5 Zeilen Der Rest sind DOUBLE (8 Bytes) und DATETIME, dort könnte es auch Redundanz in den generierten Werten geben.
Wirklich sehr beeindruckend!
Auf einem RPi, wie schätzt man den Zeitfaktor für die Transkription ein? Zeit, in der ich mir vorstelle, dass Gladys nicht verfügbar wäre… Einen Button vorsehen, um manuell zu migrieren, wenn/sofern der Benutzer es entscheidet?
Vielleicht warte ich noch ein bisschen, bevor ich meine Partitionen neu dimensioniere
) und es wären 330 MB 
Ich bin sehr motiviert, es zu tun, aber es wird Zeit in Anspruch nehmen.
Der Rest sind DOUBLE (8 Bytes) und DATETIME, dort könnte es auch Redundanz in den generierten Werten geben.