Erfahren Sie, wie spaltenorientierte Datenbanken Daten spaltenweise speichern, effizient komprimieren und scannen und BI‑Abfragen beschleunigen. Vergleichen Sie mit zeilenorientierten Speichern und wählen Sie klug.
Analytics‑ und Reporting‑Abfragen treiben BI‑Dashboards, wöchentliche KPI‑Mails, „Wie lief das letzte Quartal?“‑Reviews und Ad‑hoc‑Fragen wie „Welcher Marketing‑Kanal brachte den höchsten Lifetime Value in Deutschland?“ an. Sie sind in der Regel leseintensiv und darauf ausgerichtet, große Mengen historischer Daten zusammenzufassen.
Statt einen einzelnen Kunden‑Datensatz abzurufen, tun Analytics‑Abfragen oft:
Zwei Dinge machen Analytics für traditionelle Datenbank‑Engines anspruchsvoll:
Große Scans sind teuer. Viele Zeilen zu lesen bedeutet viel Festplatten‑ und Speicheraktivität, selbst wenn das Endergebnis winzig ist.
Concurrency ist real. Ein Dashboard ist nicht „eine Abfrage“. Es sind viele Charts, die gleichzeitig laden, multipliziert durch viele Nutzer, plus geplante Reports und explorative Abfragen, die parallel laufen.
Spaltenorientierte Systeme zielen darauf ab, Scans und Aggregationen schnell und vorhersehbar zu machen – oft zu geringeren Kosten pro Abfrage – und gleichzeitig hohe Konkurrenz für Dashboards zu unterstützen.
Frische ist eine separate Dimension. Viele Analytics‑Setups tauschen Sub‑Sekunden‑Aktualität gegen schnellere Berichte, indem sie Daten in Batches laden (alle paar Minuten oder stündlich). Manche Plattformen unterstützen Near‑Real‑Time‑Ingestion, aber Updates und Deletes bleiben oft komplexer als in transaktionalen Systemen.
Spaltenorientierte Datenbanken sind primär für OLAP‑Arten von Aufgaben gebaut.
Die einfachste Vorstellung einer spaltenorientierten Datenbank entsteht, wenn man sich anschaut, wie eine Tabelle auf der Festplatte abgelegt ist.
Stellen Sie sich eine Tabelle orders vor:
| order_id | customer_id | order_date | status | total |
|---|---|---|---|---|
| 1001 | 77 | 2025-01-03 | shipped | 120.50 |
| 1002 | 12 | 2025-01-03 | pending | 35.00 |
| 1003 | 77 | 2025-01-04 | shipped | 89.99 |
In einem Row Store hält die Datenbank die Werte derselben Zeile nebeneinander. Konzeptuell ist das wie:
Das ist perfekt, wenn Ihre Anwendung häufig ganze Datensätze benötigt (z. B. „Bestellung 1002 holen und ihren Status aktualisieren“).
In einem Column Store werden Werte derselben Spalte zusammen gespeichert:
order_id: 1001, 1002, 1003, …status: shipped, pending, shipped, …total: 120.50, 35.00, 89.99, …Analytics‑Abfragen greifen oft nur auf wenige Spalten zu, scannen aber viele Zeilen. Beispiele:
SUM(total) nach TagAVG(total) pro KundeGROUP BY status zum Zählen von BestellungenMit spaltenorientierter Speicherung kann eine Abfrage wie „Gesamtumsatz pro Tag“ nur order_date und total lesen, statt customer_id und status für jede Zeile durch den Speicher zu ziehen. Weniger gelesene Daten bedeuten schnellere Scans – das ist der Kernvorteil von Column Stores.
Spaltenspeicher ist schnell für Analytics, weil die meisten Reports nicht die meisten Ihrer Daten brauchen. Wenn eine Abfrage nur einige Felder nutzt, kann eine spaltenorientierte Datenbank genau diese Spalten von der Platte lesen – statt ganze Zeilen zu laden.
Das Scannen von Daten wird oft durch die Geschwindigkeit begrenzt, mit der Bytes vom Speicher in den Arbeitsspeicher (und dann durch die CPU) bewegt werden. Ein Row Store liest typischerweise komplette Zeilen und lädt damit viele „extra“ Werte, die nie angefragt wurden.
Bei Columnar‑Speicherung liegt jede Spalte in einem zusammenhängenden Bereich. Eine Abfrage wie „Gesamtumsatz pro Tag" liest möglicherweise nur:
Alles andere (Namen, Adressen, Notizen, Dutzende selten genutzter Attribute) bleibt auf der Platte.
Analytics‑Tabellen werden im Laufe der Zeit oft breit: neue Produktattribute, Marketing‑Tags, betriebliche Flags und „nur für den Fall“‑Felder. Reports greifen jedoch meist nur auf eine kleine Untermenge zu – oft 5–20 Spalten von 100+.
Spaltenspeicher passt zu dieser Realität: Er vermeidet, ungenutzte Spalten mitzuziehen, die breite Tabellen teuer zu scannen machen.
„Column Pruning" bedeutet, dass die Datenbank Spalten überspringt, die die Abfrage nicht referenziert. Das reduziert:
Das Ergebnis sind schnellere Scans, besonders bei großen Datensätzen, wo das Lesen unnötiger Daten die Abfragezeit dominiert.
Kompression ist eine stille Superkraft von spaltenorientierten Datenbanken. Wenn Daten spaltenweise gespeichert werden, enthält jede Spalte ähnliche Werte (Datum bei Datum, Länder bei Ländern, Status‑Codes bei Status‑Codes). Solche Muster komprimieren oft deutlich besser als die gleiche Datenmenge zeilenweise.
Denken Sie an eine order_status‑Spalte, die überwiegend „shipped“, „processing“ oder „returned“ enthält, Millionen Mal wiederholt. Oder an eine Zeitstempel‑Spalte mit stetig steigenden Werten. In einem Column Store sind diese wiederholten oder vorhersagbaren Muster gruppiert, sodass sie mit weniger Bits dargestellt werden können.
Die meisten analytischen Engines kombinieren mehrere Techniken, z. B.:
Kleinere Daten bedeuten weniger Bytes, die von der Platte oder dem Objekt‑Storage gezogen werden müssen, und weniger Daten, die durch Speicher‑ und CPU‑Caches bewegt werden. Für Reporting‑Abfragen, die viele Zeilen, aber nur ein paar Spalten scannen, kann Kompression das I/O dramatisch reduzieren – oft der langsamste Teil von Analytics.
Ein zusätzlicher Bonus: Viele Systeme können direkt auf komprimierten Daten arbeiten (oder in großen Batches dekomprimieren), sodass Durchsatz und Aggregationen wie Summen, Counts und Group‑Bys effizient bleiben.
Kompression kostet CPU: Beim Ingest und bei der Abfrage fällt Rechenzeit fürs Komprimieren/Dekomprimieren an. In der Praxis gewinnt die I/O‑Ersparnis oft, aber bei sehr CPU‑gebundenen Abfragen oder extrem frischen Daten kann sich das Verhältnis ändern.
Spaltenspeicher hilft, weniger Bytes zu lesen. Vektorisierte Verarbeitung hilft, schneller zu berechnen, wenn diese Bytes erst einmal im Speicher sind.
Traditionelle Engines evaluieren oft eine Abfrage Zeile für Zeile: Zeile laden, Bedingung prüfen, Aggregat aktualisieren, nächste Zeile. Das erzeugt viele kleine Operationen und ständige Verzweigungen, wodurch die CPU viel Overhead statt echter Arbeit leistet.
Vektorisierte Ausführung kehrt das Modell um: Die Engine verarbeitet Werte in Batches (oft Tausende von Werten einer Spalte auf einmal). Statt dieselbe Logik wiederholt pro Zeile aufzurufen, laufen enge Schleifen über Arrays von Werten.
Batch‑Verarbeitung verbessert die CPU‑Effizienz, weil:
Stellen Sie sich vor: „Gesamtumsatz aus Bestellungen in 2025 für category = 'Books'.”
Eine vektorisierte Engine kann:
category‑Werten laden und eine boolesche Maske erstellen, wo category = "Books" ist.order_date‑Werten laden und die Maske auf 2025 beschränken.revenue‑Werte laden und sie mit der Maske summieren – oft unter Nutzung von SIMD, um mehrere Zahlen pro CPU‑Zyklus zu addieren.Weil sie spalten‑ und batchbasiert arbeitet, vermeidet die Engine das Anfassen von irrelevanten Feldern und per‑Row‑Overhead, was ein Hauptgrund dafür ist, dass Column Stores bei Analytics‑Workloads so gut performen.
Analytics‑Abfragen berühren oft viele Zeilen: „Umsatz pro Monat“, „Events pro Land“, „Top‑100‑Produkte“. In OLTP‑Systemen sind Indizes das Mittel der Wahl, weil Abfragen normalerweise wenige Zeilen abfragen (nach Primärschlüssel, E‑Mail, order_id). Für Analytics ist es jedoch teuer, zahlreiche Indizes zu pflegen, und viele Abfragen müssen trotzdem große Datenbereiche scannen – deshalb konzentrieren sich Column Stores darauf, Scans schlau und schnell zu machen.
Viele spaltenorientierte Datenbanken speichern einfache Metadaten für jeden Datenblock (auch „Stripe“, „Row Group“ oder „Segment“ genannt), etwa das Minimum und Maximum eines Blocks.
Wenn Ihre Abfrage amount > 100 filtert und das Metadatum eines Blocks max(amount) = 80 lautet, kann die Engine dieses ganze Block für die amount‑Spalte überspringen – ohne einen klassischen Index zu konsultieren. Diese "Zone Maps" sind billig zu speichern, schnell zu prüfen und funktionieren besonders gut bei natürlich geordneten Spalten.
Partitionierung teilt eine Tabelle in separate Teile, meist nach Datum. Angenommen, Events sind nach Tag partitioniert und Ihr Report fragt WHERE event_date BETWEEN '2025-10-01' AND '2025-10-31'. Die Datenbank kann jede Partition außerhalb des Oktobers ignorieren und nur die relevanten Partitionen scannen.
Das kann das I/O drastisch reduzieren, weil Sie nicht nur Blöcke überspringen – Sie überspringen Dateien oder große physische Abschnitte der Tabelle.
Wenn Daten nach häufigen Filterkeys sortiert oder „geclustert“ sind – etwa event_date, customer_id oder country – liegen passende Werte oft zusammen. Das verbessert sowohl Partition Pruning als auch die Wirksamkeit von Zone Maps, weil nicht passende Blöcke schnell am Min/Max‑Check scheitern und übersprungen werden.
Spaltenorientierte Datenbanken werden nicht nur dadurch schnell, dass sie pro Abfrage weniger Daten lesen, sondern auch weil sie das Lesen parallel organisieren.
Eine einzelne Analytics‑Abfrage (z. B. „Umsatz pro Monat summieren") muss oft Millionen oder Milliarden von Werten scannen. Column Stores teilen die Arbeit typischerweise auf CPU‑Cores auf: Jeder Kern scannt einen anderen Abschnitt derselben Spalte (oder andere Partitionen). Statt einer langen Kasse öffnen Sie mehrere Kassen.
Weil spaltenorientierte Daten in großen, zusammenhängenden Blöcken gespeichert sind, kann jeder Kern seinen Block effizient durchstreamen und CPU‑Caches und Plattenbandbreite gut nutzen.
Wenn die Daten zu groß für eine Maschine sind, verteilt die Datenbank sie auf mehrere Server. Die Abfrage wird an jeden Knoten mit relevanten Daten geschickt; jeder Knoten macht einen lokalen Scan und eine partielle Berechnung.
Hier ist Datenlokalität wichtig: Computation zum Data zu bringen ist oft schneller als rohe Zeilen über das Netzwerk zu verschieben. Netzwerke sind geteilt, langsamer als RAM und können zum Flaschenhals werden, wenn viele Zwischenresultate bewegt werden müssen.
Viele Aggregationen lassen sich natürlich parallelisieren:
Dashboards lösen oft viele ähnliche Abfragen gleichzeitig aus – vor allem zur vollen Stunde oder in Meetings. Column Stores kombinieren Parallelismus mit smarter Planung (und manchmal Ergebnis‑Caching), um die Latenz vorhersagbar zu halten, wenn Dutzende oder Hunderte Nutzer Charts aktualisieren.
Analytics- und Reporting‑Abfragen sind leseintensive Fragen, die große historische Datenmengen zusammenfassen – zum Beispiel Umsatz pro Monat, Conversion nach Kampagne oder Retention nach Kohorte. Sie scannen typischerweise viele Zeilen, verwenden nur eine Teilmenge der Spalten, berechnen Aggregationen und liefern ein kleines Ergebnisset für Diagramme oder Tabellen.
Sie belasten Datenbanken hauptsächlich, weil:
Zeilenorientierte OLTP‑Engines können das zwar leisten, aber Kosten und Latenz werden in großem Maßstab oft unberechenbar.
In einem Zeilenspeicher liegen die Werte derselben Zeile zusammen auf der Platte – ideal, um einen einzelnen Datensatz zu lesen oder zu aktualisieren. In einem Spaltenspeicher liegen Werte derselben Spalte zusammen – ideal, wenn Abfragen wenige Spalten über viele Zeilen lesen.
Wenn ein Report nur order_date und total benötigt, kann ein Spaltenspeicher vermeiden, nicht benötigte Spalten wie status oder customer_id zu lesen.
Weil die meisten Analytics‑Abfragen nur einen kleinen Ausschnitt der Spalten benötigen. Spaltenspeicher wenden Column Pruning an (verschiedene Bezeichnungen: Spalten‑/Feld‑Elimination), sodass sie weniger Bytes lesen.
Weniger I/O bedeutet in der Regel:
Die spaltenweise Anordnung gruppiert ähnliche Werte (Datum bei Datum, Länder bei Ländern), die sich sehr gut komprimieren lassen.
Gängige Muster sind:
Kompression reduziert Speicherbedarf und beschleunigt Scans, weil weniger I/O nötig ist. Allerdings erfordert Kompression/Decompression CPU‑Zeit.
Vektorisiertes Ausführen verarbeitet Daten in Batches (Arrays von Werten) statt Zeile für Zeile.
Das hilft, weil:
Deshalb sind spaltenorientierte Engines selbst bei großen Scans sehr schnell.
Viele Engines speichern leichte Metadaten pro Datenblock (z. B. Min/Max). Wenn ein Filter keine Treffer in einem Block zulässt (z. B. max(amount) < 100 für amount > 100), kann der Block komplett übersprungen werden.
Das funktioniert besonders gut in Kombination mit:
Parallelismus tritt auf zwei Ebenen auf:
Dieses "Split‑and‑Merge"‑Muster lässt Gruppierungen und Aggregationen gut skalieren, ohne übermäßig viele Rohzeilen über das Netzwerk zu verschicken.
Single‑Row‑Updates sind schwieriger, weil eine „Zeile“ physisch über viele Spaltensegmente verteilt ist und oft komprimiert vorliegt. Eine einzelne Änderung kann das Umschreiben großer Bereiche erzwingen.
Übliche Strategien sind:
Deshalb akzeptieren viele Teams Near‑Real‑Time‑Frische (z. B. 1–5 Minuten) statt sofortiger Sichtbarkeit.
Führe Benchmarks mit produktähnlichen Daten und echten Abfragen durch:
Ein kleiner PoC mit 10–20 realen Abfragen zeigt meist mehr als Hersteller‑Benchmarks.