Upload
leandro-totino-pereira
View
186
Download
7
Embed Size (px)
Citation preview
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:
https://www.linkedin.com/in/leandro-totino-pereira-06726227
Facebook:
https://www.facebook.com/leandro.totinopereira