Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.
Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.
This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
ich stelle heute mal ein etwas ungewöhnliches Projekt vor: eine In-Memory-Datenbank (oder erst mal: Storage Engine) mit String- und Integer-Kompression, die später mal ein vollwertiger Nachbau eienr nicht näher benannten In-Memory-Datenbank eines ERP-Herstellers werden soll.
Kurz zum Abriss: Die DB ist besonders gut für analytische Queries geeignet, da man in einer spaltenbasierten Datenbank viel schneller so etwas wie Summen zusammenrechnen kann.
Dazu blogge ich auch auf launix.de. Der erste Blogbeitrag ist hier zu bestaunen:
Generell sehr interessant.
Bedarf an einer guten Storage-Lösung besteht auf jeden Fall in der Welt.
Spaltenbasierte Datenbanken sind gar nicht mal so gut; es ist quasi das ECS der Datenbanken :-)
Kann Vorteilhaft sein, wenn es deinem Usecase entspricht, aber man kommt sehr schnell an die Grenzen (z.B. wenn du große Tabellen filtern willst).
Spannend wären auf jeden Fall die TradeOffs, die du machen willst.
(d.h. sind die Daten bei einem Crash/Neustart weg, oder gibt es ein Backing-Store, und wie kommen die Daten performant da hin, usw. :-)
Mach am besten relativ früh Performance-Tests und vergleiche sie mit bestehenden DBs (z.B. einfach MariaDB, wenn >6GB Daten drin sind).
ich habe selbst in den Forschungsteams rund um die Datenbank-Forschung gearbeitet und deshalb auch Erfahrung in der DB-Entwicklung.
Große Tabellen filtern geht bei Columnar Storages sogar ziemlich gut, da du im Filter-State nur die Spalten laden musst, nach denen auch gefiltert wird.
Allein die Kompressionsmöglichkeiten (Hey! Die Datenbank nimmt nur 50% des Platzes gegenüber der InnoDB ein. Damit bist du allein schon beim Full Scan um Größenordnungen schneller fertig, weil du weniger Speicherseiten einlesen musst)
Zuletzt geändert von antisteo am 20.01.2023, 20:19, insgesamt 2-mal geändert.
So, der SQL Parser ist Tail Recursive und nach etwas Eingewöhnung ziemlich straigt-forward zu schreiben. Inzwischen kann ich die ersten SQL Queries nach scheme übersetzen und somit per (eval) auswerten:
Einen ähnlichen Algorithmus nutzt auch ZIP/Deflate. Ich habe ihn mal aufgeschlüsselt inkl. Code-Beispielen. In einem 64-bit-Chunk bekomme ich ca. 200 Bits untergebracht gegeben eine unbalancierte Wahrscheinlichkeitsverteilung.
Der Algorithmus sieht ganz interessant aus (ich kannte ihn glaube ich noch nicht und habe ihn jetzt auch eher überflogen), aber die Überschrift finde ich ein wenig, naja, albern. Zunächst einmal speicherst du ja nicht 1 Bit mit weniger als 1 Bit. Du speicherst eine große Anzahl an Bits in einer kleineren Anzahl an Bits. Und warum das irgendwie erstaunlich sein sollte erschließt sich mir überhaupt nicht, das ist halt die Definition von "Kompression" und das hat nun wirklich jeder schon mal gehört. In gewisser Weise wäre "Yet another compression algorithm" die bessere Überschrift gewesen. Das "Yet another" deshalb, weil im Artikel ja weder erwähnt wird, für was für Daten sich das besonders gut eignet, noch der Algorithmus mit irgendwelchen anderen verglichen wird.
Krishty hat geschrieben: ↑16.03.2023, 15:21
Nutzt ZIP/Deflate nicht Huffmann Trees, während deins näher an Arithmetic Coding ist?
Du hast recht. Die Kompressionsrate von Arithmetic Coding kommt ja sogar noch näher ans Optimum heran als der Huffman Tree, der nur dann effizient ist, wenn die Wahrscheinlichkeit exakt einer 0,5-er-Potenz entspricht.
