{"id":4823,"date":"2023-01-20T22:47:59","date_gmt":"2023-01-20T21:47:59","guid":{"rendered":"https:\/\/launix.de\/launix\/?p=4823"},"modified":"2024-04-12T16:21:44","modified_gmt":"2024-04-12T14:21:44","slug":"cpdb-eine-opensource-hochperformante-spaltenbasierte-in-memory-datenbank-als-alternative-zu-proprietaeren-analytischen-datenbanken","status":"publish","type":"post","link":"https:\/\/launix.de\/launix\/en\/cpdb-eine-opensource-hochperformante-spaltenbasierte-in-memory-datenbank-als-alternative-zu-proprietaeren-analytischen-datenbanken\/","title":{"rendered":"memcp: Eine OpenSource hochperformante Spaltenbasierte In-Memory-Datenbank als Alternative zu propriet\u00e4ren analytischen Datenbanken"},"content":{"rendered":"
In den letzten 13 Jahren gab es eine Menge Innovationen im Bereich spaltenbasierte Datenbanken. Zu verdanken ist das vor allem einem deutschen ERP-Hersteller, der sich entschieden hat, sich vom Datenbank-Marktf\u00fchrer abzusetzen und sein eigenes Ding zu machen. Es wurde zu einer Erfolgsstory. Zeit, dass OpenSource nachzieht.<\/p>\n\n\n\n\n\n\n\n
In der kommerziellen Datenbank-Welt haben sich spaltenbasierte Datenbanken bereits l\u00e4ngst durchgesetzt. Die OpenSource-Welt hinkt unterdes immer noch mit MariaDB und PostgreSQL hinterher. Das behindert nicht nur OpenSource-Projekte, sondern s\u00e4mtliche Produkte, die auf OpenSource-Datenbanken setzen.<\/p>\n\n\n\n
Aus diesem Grund stellen wir in diesem Artikel die memcp<\/code> vor, eine spaltenbasierte In-Memory-Datenbank, die sowohl OLAP, als auch OLTP-Arbeitslasten performant handhaben kann.<\/p>\n\n\n\n
Gerade komplexere Anwendungen wie z.B. ERP-Systeme haben oft Tabellen mit \u00fcber hundert Spalten. Meistens steht in vielen Spalten nicht einmal ein Wert. Zeilenbasierte Datenbanken m\u00fcssen aber f\u00fcr jede Speicherzelle entsprechend Speicher vorhalten.<\/p>\n\n\n\n
Gleichzeitig gibt es auch viele Datenbank-Anfragen, die nur auf 2 Spalten arbeiten – meist einem Fremdschl\u00fcssel, nach dem gefiltert wird und einer Wert-Spalte, nach der summiert wird. Beispiel:<\/p>\n\n\n\n
SELECT SUM(lineItem.quantity * lineItem.price) FROM lineItem WHERE lineItem.line = [ID]<\/code><\/pre>\n\n\n\n
In dieser SQL-Abfrage werden zum Beispiel von einer Liste von Verk\u00e4ufen die Umsatzsumme gebildet – ein durchaus h\u00e4ufiger Anwendungsfall. Die Krux: Nutzt man eine Zeilenbasierte Datenbank wie MySQL, muss man immer die kompletten Datenbankzeilen von der Festplatte einlesen, um die zwei Spalten Menge und Preis miteinander zu multiplizieren. Die Spalten Einheit, Artikelnummer, Beschreibung, MwSt-Satz usw. h\u00e4ngen einfach am Datensatz “mit dran”.<\/p>\n\n\n\n
Spaltenbasierte Speicher haben dieses Problem nicht. In einem spaltenbasierten Speicher werden alle Spalten separat voneinander im Speicher aufbewahrt. Das macht das Auslesen einer einzelnen “Komplett”-Zeile zwar etwas langsamer, die Gesamtperformance des Systems steigt aber im Verh\u00e4ltnis dazu st\u00e4rker.<\/p>\n\n\n\n
Spaltenbasierte Datenbanken erlauben auch Komprimierung und Optimierung<\/h2>\n\n\n\n
W\u00e4hrend Datenbank-Zeilen sehr komplex aufgebaut sind – eine Datenbank-Zeile hat etliche Spalten und jede Spalte kann einen anderen Datentyp haben – sind spaltenbasierte Speicher einfacher aufgebaut: Man hat einfach eine riesige homogene Liste von Zahlen.<\/p>\n\n\n\n
Das macht das Rechnen mit gro\u00dfen Datenmengen einfacher. So k\u00f6nnen zum Beispiel Zahlen “Bit-komprimert” werden, das hei\u00dft: Enth\u00e4lt die Spalte nur Nullen und Einsen, braucht man keine 64 Bit, sondern nur ein einziges Bit, um die Zahl darzustellen. Eine Speicher-Ersparnis um das 64-fache!<\/strong><\/p>\n\n\n\n
F\u00fcr Zeichenketten (Strings) gilt dasselbe: Sie k\u00f6nnen “W\u00f6rterbuch-komprimiert” werden. Enth\u00e4lt die Spalte Geschlecht zum Beispiel nur abwechselnd die Werte “m\u00e4nnlich” und “weiblich”, speichern traditionelle Datenbanken die komplette Zeichenkette ab. Mit einer W\u00f6rterbuch-Komprimierung w\u00fcrde man jedem Wort eine Zahl zuweisen und k\u00f6nnte die Werte mit einem Speicherverbrauch von 1 Bit pro Wert abspeichern, anstatt mit 8 Bytes. Eine Ersparnis vom 256-fachen!<\/strong><\/p>\n\n\n\n
Die Balance zwischen OLAP und OLTP<\/h2>\n\n\n\n
Bei OLTP-Arbeitslasten haben zeilenbasierte Speicher hingegen weiterhin die Nase vorn. Eine typische OLTP-Anfrage w\u00e4re zum Beispiel das Anlegen eines neuen Datensatzes oder das ver\u00e4ndern eines einzelnen Datums. <\/p>\n\n\n\n
In einer zeilenbasierten Datenbank \u00e4ndert man nur die eine Zeile – nutzt man hingegen einen bereits komprimierten Spalten-Speicher, kann es sein, dass man die komplette Komprimierung aufl\u00f6sen muss, den Speicher neu alloziieren und den kompletten Spaltenspeicher neu aufbauen muss.<\/p>\n\n\n\n
Doch daf\u00fcr gibt es auch eine L\u00f6sung: Man kombiniert einfach beide Welten.<\/p>\n\n\n\n
Im sogenannten Stammspeicher<\/strong> (engl. “Main Storage<\/strong>“) werden die alten unver\u00e4nderten Daten spaltenbasiert abgelegt. Der Stammspeicher ist performant f\u00fcr Statistiken einsetzbar und \u00e4ndert sich nie. Im Stammspeicher werden auch Indizes gebildet, um Daten schneller suchen zu k\u00f6nnen.<\/p>\n\n\n\n
Im \u00c4nderungsspeicher<\/strong> (engl. “Delta Storage<\/strong>“) hingegen speichert man die L\u00f6sch-Markierungen, sowie die zeilenbasierten neuen oder ver\u00e4nderten Datens\u00e4tze. Das Einf\u00fcgen in den \u00c4nderungsspeicher geht dabei sehr schnell, da man keine Komprimierung anwendet.<\/p>\n\n\n\n
In einem gewissen Intervall “verfestigt” man anschlie\u00dfend die \u00c4nderungen aus dem \u00c4nderungsspeicher, indem man einen neuen Stammspeicher <\/strong>aus dem alten Stammspeicher und dem \u00c4nderungsspeicher aufbaut. Somit hat man – wenn das Intervall 15 Minuten betr\u00e4gt – sp\u00e4testens nach 15 Minuten f\u00fcr alle neuen Daten die volle OLAP-Performance, w\u00e4hrend man trotzdem mit voller Performance OLTP-Arbeitslasten in den \u00c4nderungsspeicher schreiben kann.<\/p>\n\n\n\n
OLAP-Lasten durch verteiltes Rechnen z\u00e4hmen<\/h2>\n\n\n\n
Ein gro\u00dfer Nutzer von OLAP-Datenbanken sind sogenannte BI-Tools<\/strong> (Business Intelligence). Diese Programme erlauben das Analysieren und Durchforsten von Daten. Die Problematik hier: Je mehr Daten anfallen, desto langsamer wird die Analytik. Ein Klick im BI-Programm dauert dann mehrere Sekunden bis hin zu Minuten oder Stunden. <\/p>\n\n\n\n
Allerdings ist hier Abhilfe m\u00f6glich: Analytische Datenbank-Anfragen lassen sich sehr leicht parallelisieren. Anstatt dass eine CPU die Summe \u00fcber alle Datens\u00e4tze bildet, kann man den Speicher zum Beispiel auf 8 verschiedene Rechenknoten aufteilen. Das Kommando zum Errechnen der Summe verteilt man dann auf alle 8 Knoten und errechnet das Ergebnis dann aus den 8 Teilsummen.<\/p>\n\n\n\n
Will man zum Beispiel, dass jeder Klick im BI-Tool nicht l\u00e4nger als 100ms Rechenzeit in Anspruch nimmt, kann man genau errechnen, wie gro\u00df das Verh\u00e4ltnis von RAM zu CPU-Kernen sein muss. So k\u00f6nnte man alle 1 GiB RAM dann einen CPU-Kern dazustellen.<\/p>\n\n\n\n
In Produkten gesprochen, w\u00fcrde man beispielsweise einen Mini-Server aus einem Raspberry Pi mit 4 Kernen und 8 GiB RAM f\u00fcr die ersten 8 GiB Daten in der Datenbank verkaufen. Sobald der Nutzer mehr als 8 GiB Daten hat, kauft er einen zweiten Mini-Server und so weiter – damit steht f\u00fcr eine definierte Menge Speicher immer ausreichend Rechenzeit zur Verf\u00fcgung, um den Speicher auch “verarbeiten” zu k\u00f6nnen.<\/p>\n\n\n\n
Datenbanken neu denken<\/h2>\n\n\n\n
Neben den \u00dcberlegungen zur bestm\u00f6glichen Speicherung, Komprimierung und Parallelisierung, soll auch die Kommunikation mit der Au\u00dfenwelt etwas \u00fcberdacht werden.<\/p>\n\n\n
![\"\"](\"https:\/\/launix.de\/launix\/wp-content\/uploads\/2023\/01\/memcp-logo.png\")
<\/a><\/figure><\/div>\n\n\n