Letzten Freitag gab uns unser Kollege Edison einen Einblick in die Welt der In-Memory NOSQL Key Value Store Datenbank Redis.

Redis wird hauptsächlich für das Caching, als Message Broker aber auch für die Verarbeitung von Geodaten verwendet und hat u.a. den Vorteil, dass es eine Vielzahl von Clients in fast jeder Programmiersprache gibt (z.B. C, Java, JavaScript, Python, Kotlin, Ruby etc.).

Wie ein Redis-Cluster typischerweise aufgebaut ist, zeigte uns Edison an einem praktischen Beispiel aus seiner eigenen Projektarbeit. Hier zeigt sich aber auch, warum Redis als reine NOSQL-Datenbank-Lösung problematisch sein kann: Ab einer hohen Anzahl von Read/Write Operationen durch Clientenanfragen kann die Performance sinken. Wann und wie also sollte man Redis nutzen? Edison zeigte uns, wie komplexere Datenstrukturen in Redis dargestellt werden können, warum Performance in Redis größer geschrieben wird als Persistenz und wieso die verarbeitete Menge an Daten determinierbar sein sollte.

Brown Bag Session – Redis für Angeber

Weiterführende Infos gibt es hier:

• https://medium.com/opstree-technology/redis-cluster-architecture-replication-sharding-and-failover-86871e783ac0
• https://redis.com/redis-enterprise/data-structures/
• https://logz.io/blog/kafka-vs-redis/
• https://www.instaclustr.com/blog/what-is-redis/