DynomiteDB

High availability via a shared nothing architecture with no single point of failure (SPOF)

Agenda

• What is DynomiteDB?

• Other Solutions ?

• DynomiteDB concepts

• Dynomite Architecture

• Demo Time

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.

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)

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

DynamoniteDB Architecture

dc_one dc_quorum

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

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

Demo architecture

Replication Test

Solution Resilience/High Availability

Thank you!

Questions?

More information:

Linkedin

https://www.linkedin.com/in/leandro-totino-pereira-06726227

Facebook:

https://www.facebook.com/leandro.totinopereira