Redis Bitmaps fuer effiziente Flag-Speicherung

1. Warum Bitmaps fuer boolesche Flags im grossen Massstab

Ein Bitmap ist in Redis kein eigener Datentyp, sondern eine Sichtweise auf den bereits bekannten String-Typ: Ein String wird als eine Folge einzeln adressierbarer Bits interpretiert statt als Zeichenkette. Diese Umdeutung ist der Schluessel zu einer der speichereffizientesten Techniken in Redis, denn ein einzelnes Bit belegt buchstaeblich ein Achtel eines Bytes, waehrend ein Eintrag in einem Set mehrere Dutzend Byte an Overhead fuer Hashtabellen-Verwaltung und Zeiger mit sich bringt.

Die Staerke von Bitmaps zeigt sich bei Problemen, die sich als "Ist Flag X fuer Nutzer Y gesetzt?" formulieren lassen, angewendet auf Millionen Nutzer. Klassische Beispiele sind Daily-Active-User-Tracking, das Speichern, welche Nutzer eine bestimmte Feature-Flag aktiviert haben, oder das Markieren, welche von Millionen IDs bereits verarbeitet wurden. Fuer all diese Faelle gilt: Ein Bit pro Nutzer reicht aus, und Redis bietet mit SETBIT, GETBIT, BITCOUNT und BITOP ein kompaktes Set an Commands, um genau das effizient umzusetzen.

Dieser Beitrag geht die Bitmap-Commands im Detail durch, zeigt den konkreten Speichervergleich gegenueber einem aequivalenten Set, und arbeitet ein vollstaendiges Praxisbeispiel fuer Daily-Active-User-Tracking aus, inklusive der typischen Fallstricke, die beim produktiven Einsatz von Bitmaps auftreten.

Wichtig fuer das Verstaendnis ist, dass Bitmaps und Bitmap-Commands in Redis keine Ausnahme oder Erweiterung sind, sondern seit den fruehesten Versionen fester Bestandteil des Strings sind. Wer bereits SET und GET kennt, muss fuer Bitmaps kein neues mentales Modell aufbauen, sondern lediglich lernen, denselben String ueber eine zusaetzliche Befehlsfamilie bit-genau zu adressieren.

2. SETBIT und GETBIT: die Basis-Operationen

SETBIT key offset value setzt das Bit an Position offset auf 0 oder 1. Der Offset ist nullbasiert und kann sehr gross werden, Redis erlaubt Bitmaps bis zu einer maximalen Groesse von 512 Megabyte, was 4,3 Milliarden einzelnen Bits entspricht. Setzt man ein Bit an einem hohen Offset, verlaengert Redis den zugrunde liegenden String automatisch und fuellt die Luecke mit Nullbits auf, ohne dass die Anwendung sich darum kuemmern muss.

GETBIT key offset liefert den Wert eines einzelnen Bits, 0 oder 1, in konstanter Zeit O(1). Diese Konstantzeit-Eigenschaft ist entscheidend: Egal ob die Bitmap tausend oder eine Milliarde Bits umfasst, das Auslesen eines einzelnen Bits kostet immer denselben, minimalen Aufwand. Fuer die Praxis bedeutet das: Eine Nutzer-ID wird als Offset interpretiert, etwa die numerische User-ID direkt als Bit-Position, und SETBIT dau:2026-07-23 42 1 markiert Nutzer 42 als aktiv am 23. Juli 2026.

Ein Detail, das in der Praxis leicht uebersehen wird: SETBIT gibt als Rueckgabewert den vorherigen Wert des Bits zurueck, nicht den neuen. Das erlaubt zu erkennen, ob ein Flag zuvor bereits gesetzt war, etwa um zu unterscheiden, ob ein Nutzer heute zum ersten Mal aktiv wurde oder bereits zuvor markiert war, ohne einen zusaetzlichen GETBIT-Aufruf vor dem Setzen zu benoetigen.

# Bitmaps: setting and reading individual bits
redis-cli SETBIT dau:2026-07-23 42 1
redis-cli SETBIT dau:2026-07-23 1007 1
redis-cli GETBIT dau:2026-07-23 42
redis-cli GETBIT dau:2026-07-23 99
redis-cli STRLEN dau:2026-07-23
redis-cli SETBIT feature:dark-mode 42 1
redis-cli GETBIT feature:dark-mode 42

3. BITCOUNT: gesetzte Bits effizient zaehlen

BITCOUNT key zaehlt alle gesetzten Bits, also alle Bits mit dem Wert 1, in einer Bitmap und liefert damit direkt die Anzahl der Nutzer, fuer die ein Flag aktiv ist, ohne dass die Anwendung selbst iterieren muss. Diese Zaehlung laeuft in O(n) relativ zur Groesse der Bitmap in Bytes, ist aber durch eine hochoptimierte Popcount-Implementierung in Redis extrem schnell, selbst bei Bitmaps mit mehreren Millionen Bits.

Mit der optionalen Byte-Bereichs-Angabe BITCOUNT key start end laesst sich die Zaehlung auf einen Ausschnitt der Bitmap begrenzen, was fuer Sharding-Szenarien relevant ist, bei denen unterschiedliche Nutzer-ID-Bereiche unterschiedlichen Anwendungslogiken zugeordnet sind. Seit Redis 7.0 kann der Bereich zusaetzlich mit dem BIT-Modifikator direkt in Bit-Einheiten statt in Byte-Einheiten angegeben werden, was praezisere Teilabfragen ohne manuelle Umrechnung ermoeglicht.

# Counting set bits: total, byte range, and bit range
redis-cli BITCOUNT dau:2026-07-23
redis-cli BITCOUNT dau:2026-07-23 0 127
redis-cli BITCOUNT dau:2026-07-23 0 999 BIT
redis-cli BITPOS dau:2026-07-23 1
redis-cli BITPOS dau:2026-07-23 0

4. BITOP: Bitmaps kombinieren mit AND, OR, XOR

BITOP fuehrt bitweise Operationen zwischen mehreren Bitmaps aus und speichert das Ergebnis in einem neuen Schluessel. BITOP AND result key1 key2 liefert eine Bitmap, in der nur die Bits gesetzt sind, die in beiden Quell-Bitmaps gesetzt waren, praktisch fuer die Frage "Welche Nutzer waren sowohl gestern als auch heute aktiv?". BITOP OR liefert die Vereinigung, praktisch fuer "Welche Nutzer waren an mindestens einem der letzten sieben Tage aktiv?". BITOP XOR liefert die Bits, die in genau einer der beiden Quellen gesetzt waren, nuetzlich um Unterschiede zwischen zwei Zustaenden zu erkennen.

Der entscheidende Vorteil dieser Operationen gegenueber einer aequivalenten Berechnung mit Sets ist die Geschwindigkeit: Eine bitweise AND-Operation auf zwei Bitmaps mit jeweils zehn Millionen Bits laeuft in wenigen Millisekunden, weil die CPU mehrere Bits gleichzeitig in einem einzigen Maschinenwort verarbeiten kann. Eine aequivalente SINTER-Operation auf zwei Sets mit zehn Millionen Elementen waere um Groessenordnungen langsamer, weil sie Hash-Vergleiche fuer jedes einzelne Element durchfuehren muss.

Kombiniert man BITOP mit BITCOUNT auf dem Ergebnis, lassen sich komplexe Kohortenfragen in zwei Befehlen beantworten: Erst BITOP AND zur Berechnung der Schnittmenge mehrerer taeglicher Bitmaps, dann BITCOUNT auf dem Ergebnis fuer die konkrete Zahl. Diese Kombination ist die Grundlage fuer viele Retention- und Engagement-Analysen in Produktanalytics-Systemen.

# BITOP: combine bitmaps to answer cohort questions
redis-cli SETBIT dau:2026-07-22 42 1
redis-cli SETBIT dau:2026-07-22 55 1
redis-cli SETBIT dau:2026-07-23 42 1
redis-cli SETBIT dau:2026-07-23 88 1
redis-cli BITOP AND retained:22-23 dau:2026-07-22 dau:2026-07-23
redis-cli BITCOUNT retained:22-23
redis-cli BITOP OR active:22-23 dau:2026-07-22 dau:2026-07-23
redis-cli BITCOUNT active:22-23

5. Praxisbeispiel: Daily Active Users mit Bitmaps

Der Klassiker unter den Bitmap-Anwendungsfaellen ist das Tracking taeglich aktiver Nutzer. Bei jedem Login oder relevanten Ereignis wird SETBIT dau: 1 aufgerufen, wobei die numerische Nutzer-ID direkt als Bit-Offset dient. Am Ende des Tages liefert BITCOUNT dau: sofort die Anzahl aktiver Nutzer, ohne dass jemals eine Liste einzelner IDs materialisiert werden musste.

Fuer wiederkehrende Nutzer ueber mehrere Tage, ein zentraler Retention-Indikator, kombiniert man mehrere taegliche Bitmaps mit BITOP AND: Nutzer, die sowohl am Montag als auch am Dienstag als auch am Mittwoch aktiv waren, ergeben sich aus der AND-Verknuepfung aller drei taeglichen Bitmaps. Dieses Muster skaliert auf beliebig viele Tage und liefert exakte, nicht naeherungsweise Ergebnisse, im Gegensatz zu einer HyperLogLog-basierten Loesung.

Ein wichtiger Vorteil gegenueber HyperLogLog fuer diesen Anwendungsfall: Bitmaps erlauben nicht nur die Zaehlung, sondern auch die Identifikation einzelner Nutzer ueber GETBIT und das Iterieren gesetzter Bit-Positionen. Wer wissen muss, welche konkreten Nutzer-IDs an einem Retention-Kohorten-Filter teilnehmen, um sie etwa gezielt anzuschreiben, kommt mit Bitmaps zum Ziel, waehrend HyperLogLog dafuer prinzipbedingt ungeeignet ist.

Fuer die Aufbewahrung empfiehlt sich, jede taegliche Bitmap mit EXPIRE auf ein sinnvolles Retentionsfenster zu begrenzen, damit alte Tage automatisch verschwinden. Da die Bitmap-Groesse von der hoechsten gesetzten Bit-Position abhaengt und nicht automatisch schrumpft, wenn Bits wieder auf 0 gesetzt werden, ist eine feste Aufbewahrungsdauer der zuverlaessigste Weg, den Speicherbedarf ueber viele Tage hinweg planbar zu halten.

# Multi-day retention: users active on all three consecutive days
redis-cli SETBIT dau:2026-07-21 42 1
redis-cli SETBIT dau:2026-07-22 42 1
redis-cli SETBIT dau:2026-07-23 42 1
redis-cli BITOP AND retained:3day dau:2026-07-21 dau:2026-07-22 dau:2026-07-23
redis-cli BITCOUNT retained:3day
redis-cli GETBIT retained:3day 42
redis-cli EXPIRE dau:2026-07-21 7776000

6. BITFIELD: mehrere Werte in einem String kodieren

Waehrend SETBIT und GETBIT sich auf einzelne Bits beschraenken, erlaubt BITFIELD das Lesen und Schreiben mehrerer Bit-Felder mit definierter Breite in einem einzigen String, in einer einzigen atomaren Operation. Damit lassen sich etwa mehrere kleine Zaehler, jeder mit 8 Bit Breite und damit einem Wertebereich von 0 bis 255, dicht gepackt in einem einzigen Redis-Key unterbringen, statt fuer jeden Zaehler einen eigenen String anzulegen.

Ein praktisches Beispiel: Ein Punktestand-System mit mehreren Kategorien, etwa Ausdauer, Staerke und Geschicklichkeit, jede als 8-Bit-Wert, laesst sich in einem einzigen 3-Byte-String unterbringen. BITFIELD unterstuetzt zudem INCRBY fuer atomare Erhoehung einzelner Felder sowie OVERFLOW WRAP, SAT oder FAIL, um das Verhalten bei Ueberlauf eines Feldes zu steuern, was fuer Spiele-Mechaniken oder Rate-Limiting-Zaehler mit festen Obergrenzen nuetzlich ist.

# BITFIELD: multiple packed counters in a single key
redis-cli BITFIELD player:501 SET u8 0 10 SET u8 8 25 SET u8 16 5
redis-cli BITFIELD player:501 GET u8 0 GET u8 8 GET u8 16
redis-cli BITFIELD player:501 INCRBY u8 0 5 OVERFLOW SAT INCRBY u8 8 250
redis-cli STRLEN player:501

7. Speichereffizienz: Bitmap vs. Set im Detail

Der Speichervorteil einer Bitmap gegenueber einem Set laesst sich konkret durchrechnen. Fuer zehn Millionen Nutzer, bei denen fuer jeden ein einzelnes Flag gespeichert werden soll, braucht eine Bitmap genau 10.000.000 Bits, also 1.250.000 Byte oder rund 1,25 Megabyte. Ein aequivalentes Set mit zehn Millionen numerischen IDs als Mitglieder braucht dagegen, je nach interner Repraesentation und ID-Laenge, typischerweise 80 bis 150 Megabyte, weil jeder Set-Eintrag Zeiger, Hash-Bucket-Verwaltung und den eigentlichen Wert mit sich bringt.

Dieser Faktor von grob 60 bis 100 zwischen Bitmap und Set skaliert linear mit der Anzahl der Nutzer, macht Bitmaps also besonders attraktiv bei sehr grossen Nutzerbasen. Der Nachteil zeigt sich allerdings bei duennen ID-Raeumen: Hat eine Anwendung nur wenige tausend aktive Nutzer, aber IDs, die theoretisch bis in den Milliardenbereich reichen, waere eine Bitmap, die bis zur hoechsten ID reicht, ineffizienter als ein Set mit den wenigen tatsaechlich aktiven IDs. Bitmaps lohnen sich vor allem dann, wenn der ID-Raum dicht und die Aktivierungsrate hoch ist.

Auch bei der CPU-Effizienz spielt die Bitmap ihre Staerke aus: Popcount-Operationen fuer BITCOUNT nutzen in modernen Prozessoren dedizierte Maschinenbefehle, die mehrere Bytes in einem einzigen Taktzyklus verarbeiten koennen. Eine aequivalente Zaehlung ueber ein Set wuerde dagegen Hash-Bucket-Traversierung fuer jedes einzelne Element erfordern, was bei Millionen Eintraegen einen deutlich hoeheren CPU-Aufwand verursacht.

8. Grenzen und Stolperfallen im Praxisbetrieb

Ein haeufiger Fehler beim Einsatz von Bitmaps ist die direkte Verwendung sehr grosser, nicht-numerischer oder sehr weit auseinanderliegender IDs als Bit-Offset. Eine UUID direkt als Offset zu interpretieren ist unmoeglich, und eine sehr grosse numerische ID, etwa in Milliardenhoehe, ohne dichte Belegung fuehrt zu einer Bitmap, die zwar theoretisch nur wenige gesetzte Bits enthaelt, aber trotzdem den vollen Speicherbereich bis zur hoechsten ID alloziert. Fuer solche Faelle empfiehlt sich, eine kompakte, fortlaufende interne ID als Offset zu verwenden statt der externen ID direkt.

Ein zweiter Stolperstein betrifft die maximale Bitmap-Groesse von 512 Megabyte, entsprechend rund 4,3 Milliarden Bit-Positionen. Fuer Anwendungen mit noch groesseren ID-Raeumen ist Sharding auf mehrere Bitmap-Schluessel noetig, etwa nach ID-Bereich oder Hash-Modulo, kombiniert mit BITCOUNT ueber alle Shards und Summierung im Client. Ein dritter Punkt: Bitmaps liefern keine natuerliche Iteration ueber gesetzte Positionen, BITPOS findet nur die erste gesetzte oder ungesetzte Position, fuer eine vollstaendige Liste muss die Anwendung wiederholt mit fortlaufendem Start-Offset abfragen.

Ein vierter, oft unterschaetzter Punkt betrifft Replikation und Netzwerk-Traffic bei sehr grossen Bitmaps: Eine einzelne SETBIT-Operation auf einer 500-Megabyte-Bitmap repliziert im Standardfall den vollstaendigen geaenderten String an alle Replikas, nicht nur das geaenderte Bit. Bei sehr hoher Schreibfrequenz auf riesigen Bitmaps kann das zu spuerbarer Replikations-Last fuehren, was bei der Kapazitaetsplanung fuer Replika-Verbindungen beruecksichtigt werden sollte.

9. Bitmap im Vergleich zu Set und HyperLogLog

Die folgende Tabelle stellt Bitmap den beiden Alternativen Set und HyperLogLog fuer flag-aehnliche Zaehl- und Mitgliedschaftsprobleme gegenueber.

Bitmaps gewinnen immer dann, wenn Flags fuer dicht gepackte numerische IDs gespeichert werden sollen und sowohl Einzelabfragen als auch schnelle Mengenverknuepfungen benoetigt werden. Bei sehr duennen ID-Raeumen oder wenn nur eine Naeherung noetig ist, sind Set beziehungsweise HyperLogLog haeufig die bessere Wahl.

10. Zusammenfassung

Redis Bitmaps loesen ein sehr konkretes Speicherproblem: boolesche Flags fuer Millionen dicht gepackter numerischer IDs mit minimalem Speicherbedarf verwalten. SETBIT und GETBIT setzen und lesen einzelne Bits in konstanter Zeit, BITCOUNT zaehlt gesetzte Bits effizient, und BITOP kombiniert mehrere Bitmaps mit AND, OR und XOR fuer Kohorten- und Retention-Analysen. BITFIELD erweitert das Konzept um dicht gepackte Mehrbit-Zaehler in einem einzigen String.

Der Speichervorteil gegenueber einem aequivalenten Set liegt typischerweise beim Faktor 60 bis 100, was Bitmaps zur ersten Wahl fuer Daily-Active-User-Tracking, Feature-Flags und aehnliche Anwendungsfaelle mit dichten ID-Raeumen macht. Fuer duenne ID-Raeume oder wenn nur eine Naeherung noetig ist, bleiben Set beziehungsweise HyperLogLog die geeigneteren Alternativen.

11. FAQ: Redis Bitmaps