OrientDB Distributed Architecture v2.0
•
17 likes•79,992 views
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.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to OrientDB Distributed Architecture v2.0
Similar to OrientDB Distributed Architecture v2.0 (20)
Recently uploaded
Recently uploaded (20)
OrientDB Distributed Architecture v2.0
- 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 to OrientDB's M/S architecture? This is the old MASTER/SLAVE replication Copyright (c) - Orient Technologies LTD 5
- 6. 2012: new architectural goals 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 the distributed 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 case of 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 on Cluster to store records 1 class -> 1 cluster Class Customer customer By default Cluster Copyright (c) - Orient Technologies LTD 12
- 13. Classes can be split 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 cluster per 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 the hood 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 the hood 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 the hood 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 Elastic scalability 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