Download as PDF, PPTX
Uploaded byOrient Technologies
OrientDB Distributed Architecture v2.0
The document describes the evolution of OrientDB's database architecture from a master-slave model to a distributed, multi-master architecture. In the master-slave model, the single master node was a bottleneck for write operations. OrientDB's new architecture allows all nodes to accept writes, uses sharding to partition data across multiple nodes, and employs auto-discovery and replication techniques to improve scalability, availability, and failover. Hazelcast is used for distributed coordination and metadata storage.
In this document
Powered by AI
Introduction to the concept of Distributed DBMS, which allows managing data across multiple nodes.
Discusses the history of Master/Slave replication, including its scalability issues and performance limitations.
Introduces updates for OrientDB's architecture focusing on Multi-Master setup, sharding, failover, and auto-discovery.
Explains the auto-discovery feature for nodes, broadcasting configurations, and client reconnections upon failures.
Details auto-deployment of databases and organizational structure of classes and clusters within the database.
Explains the use of RAID concepts in databases to ensure redundancy and resilience in data management.
Outlines how replication works within the system, including request queues and response handling.
Highlights the significance of linear and elastic scalability in a distributed DBMS, accommodating both read and write operations.
Describes Hazelcast's contributions, including auto-discovery, request handling, and management of distributed maps.
Preview of OrientDB 2.0 with performance improvements and enhanced features like conflict resolution and client auto-discovery.
OrientDB Distributed Architecture v2.0
- 1.
- 2. Short history ! In 2012, we had a Master/Slave replication ! While it scaled up well on reads, users complained of a single Master node bottleneck It’s quite easy to scale up reads, the hard part is to scale up both reads and writes Copyright (c) - Orient Technologies LTD 2
- 3. How Master/Slave works Copyright (c) - Orient Technologies LTD 3 C C C Master Node Slave Node Slave Node Writes Master node is the bottleneck
- 4. Master/Slave ! PROS: - Relatively easy to develop ! CONS: - The master is the bottleneck for writes - No matter how many servers you have, the throughput is limited by the Master node Copyright (c) - Orient Technologies LTD 4
- 5. What happened toOrientDB's M/S architecture? This is the old MASTER/SLAVE replication Copyright (c) - Orient Technologies LTD 5
- 6. 2012: new architecturalgoals Multi-Master: all the nodes must accept writes Sharding: split data in multiple partitions Better Fail-Over Simplified configuration with Auto-Discovery Copyright (c) - Orient Technologies LTD 6
- 7. Auto-Discovery C Master Node I’m the only one! Copyright (c) - Orient Technologies LTD 7
- 8. Auto-Discovery Connected! C Master Node Master Node Copyright (c) - Orient Technologies LTD 8
- 9. Clients see thedistributed configuration C Master Node updated distributed configuration is broadcasted to all the connected clients Master Node Copyright (c) - Orient Technologies LTD 9
- 10. Auto-reconnect in caseof failure In case of failure, the clients auto-reconnect to C C the available nodes Master Node Master Node Copyright (c) - Orient Technologies LTD 10
- 11. Auto-deploy of databases automatically deployed C to the new joining Master Node C Master Node DB are nodes C C DB DB Copyright (c) - Orient Technologies LTD 11
- 12. Classes rely onCluster to store records 1 class -> 1 cluster Class Customer customer By default Cluster Copyright (c) - Orient Technologies LTD 12
- 13. Classes can besplit into more clusters Customer customer_usa Class multiple clusters and assign them to customer_china Define each node Cluster Cluster customer_europe Cluster Copyright (c) - Orient Technologies LTD 13
- 14. Assign 1 clusterper Node Master Node Customer Master Node Master Node customer_usa customer_europe customer_china Copyright (c) - Orient Technologies LTD 14
- 15. Copyright (c) -Orient Technologies LTD What about sharing + replication? ! We used a solution similar to RAID for HardDrives 15
- 16. RAID for databases Replica factor = 2 Master Node Customer Master Node Master Node customer_usa customer_europe customer_china customer_china customer_usa customer_europe Copyright (c) - Orient Technologies LTD 16
- 17. RAID for databases Replica factor = 3 Master Node Master Node Each node owns all customers Master Node customer_usa customer_europe customer_china customer_customer_china usa customer_europe customer_europe customer_china customer_usa Copyright (c) - Orient Technologies LTD 17
- 18. Replication: under thehood Client sends an INSERT request HZ Queue Requests Master Node HZ Queue Master Node HZ Queue Master Node C INSERT Copyright (c) - Orient Technologies LTD 18
- 19. Replication: under thehood HZ Queue Response handling Requests Master Node HZ Queue Master Node HZ Queue WriteQuorum = 2 Sends OK Master Node C HZ Queue HZ Queue HZ Queue OK Responses Copyright (c) - Orient Technologies LTD 19
- 20. Replication: under thehood Fix the unaligned node HZ Queue Requests Master Node HZ Queue Master Node HZ Queue Master Node HZ Queue HZ Queue HZ Queue Responses Fix Copyright (c) - Orient Technologies LTD 20
- 21. Linear and Elasticscalability C Master Node C on both read & writes! Master Node C C Master Node C C C C Master Node C C C C Master Node C C C Master Node C C C Master Node C C Copyright (c) - Orient Technologies LTD 21
- 22. Hazelcast’s role Auto-Discovering(Multicast/TCP-IP/Amazon) Queues for requests and responses Store metadata in distributed Maps Distributed Locks Copyright (c) - Orient Technologies LTD 22
- 23. OrientDB’s Future Roadmap OrientDB 2.0 (Sept 2014) has even better performance: +300% improvement on all the distributed operations Pluggable conflict resolution strategy Auto-discovery also by Clients Copyright (c) - Orient Technologies LTD 23