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.
