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.

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

6. DynamoniteDB Architecture
dc_one dc_quorum

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

9. Demo architecture

10. Replication Test

11. Solution Resilience/High Availability

12. Thank you!
Questions?
More information:
Linkedin
https://www.linkedin.com/in/leandro-totino-pereira-06726227
Facebook:
https://www.facebook.com/leandro.totinopereira