DynomiteDB - No spof High-availability Redis cluster solution
- 1. DynomiteDB High availability via a shared nothing architecture with no single point of failure (SPOF)
- 2. Agenda • What is DynomiteDB? • Other Solutions ? • DynomiteDB concepts • Dynomite Architecture • Demo Time
- 3. What is DynomiteDB? • DynomiteDB is a high performance Dynamo layer that adds data replication and sharding to Redis and other single-server storage engines, plus the ability to scale linearly, high availability via a shared nothing architecture with no single point of failure (SPOF), and support for 1000+ node clusters that span multiple data centers. • A high performance, linearly scalable, highly available (HA) and distributed open- source database with support for pluggable persistent and in-memory storage engines. • Redis provides DynomiteDB with a high performance backend and is the primary API supported by Dynomite. You can use any Redis client in your favorite programming language to build high performance, scalable applications with DynomiteDB.
- 4. Other solutions? • Twenproxy - redis api limited, just sharding depends on sentinel (limited,complex) • Codis – Many componentes whick makes a complex solution (complex and depends on sentinel) • Redis Cluster – not a solution! • Redis Sentinel – Active/Passive (No way)
- 5. DynomiteDB • DynomiteDB is a high performance Dynamo layer that adds data replication and sharding to Redis. • Multiple storage engines supported. • Linear Scability • high availability via a shared nothing architecture with no single point of failure (SPOF) • Support for 1000+ node clusters that span multiple data centers. • Persistent storages supported • Sync/Async replication depends on consistency level • Peer-to-peer architecture
- 7. Architecture Considerations • The number of racks per DC defines the replication factor (RF). The RF is the number of replicas per DC. • Each replica is stored on a different node where each replica node is in a different rack • Data token range is defined on each node dynomiteDB configuration file • It´s extremely important planning data token range before deployment • Write and read consistency level must be defined to fit your needs
- 8. Demo requirements • Three servers topology • One DC, three racks with one node each ( testing purposes). • A token range defined by: 0, 1431655765 e 2863311530 • Redis as backend
- 10. Replication Test