eBay Cloud CMS based on NOSQL
Download as PPTX, PDF•3 likes•1,956 views
eBay's Cloud Configuration Management System (CMS) is based on NoSQL databases and manages the state of all resources in eBay's cloud environment. It uses a metadata-driven object model to define relationships for the graph data structure and supports features like multi-row transactions and concurrency control that overcome challenges of using NoSQL databases. The CMS also provides a RESTful query language, role-based access control, and an asynchronous notification system.
eBay Cloud CMS based on NOSQL
- 1. eBay Cloud CMS based on nosql Xu Jiang eBay COE 1
- 2. Agenda What’s eBay Cloud CMS? Why is CMS based on nosql? How does CMS overcome the challenges of nosql?
- 3. What is eBay Cloud CMS? CMS is “Configuration Management System” CMS manages the state of all resources in eBay cloud environment – Metadata: ○ Data Dictionary – Runtime Data ○ Stable State ▪ Current State ▪ Future State ○ Transient State
- 4. Role of CMS in eBay Cloud
- 5. CMS Design Goals High Performance & High Availability & High Scalability Network partition tolerated distributed architecture Flexible data model that support graph model Declarative query language that support filter, join and projection Multi-row transactional data consistency Concurrency control Access control
- 6. Relational DB vs. Nosql DB RDB (i.e. MySQL) Document Store (i.e. MongoDB) Column Family Store (i.e. HBase) DB Schema Relational Model, Hard for graph model Complete schema-less Semi schema-less Performance Too many join for graph model High read performance; Potential write performance bottleneck High write performance Fast key based read & Slow range query Scalability Difficult to scale-out (manual sharding) Auto-sharding on pre-defined shard key Horizontally scalable by tablet Query SQL Limited query language (no join) Key-value access; Pig & Hive based on MapReduce Consistency ACID Transactional Eventual Consistency No multi-row transaction Concurrency Locking or MVCC node-level locking & row-based atomic Control atomic operation Security AuthZ & AuthN Basic security Basic security Notification Mechanism Trigger No build-in notification No build-in notification
- 7. Solution To Nosql Challenge – No Metadata Management Metadata-Driven Object Oriented Model – Use object reference to define relationship in graph model – Support inherit attributes and virtual expression attributes Support metadata extension & versioning Support runtime data migration
- 8. Solution To Nosql Challenge – Limited Query Language RESTful query language – Resource Path – Implicit Join – Expression Filter – Attribute Selection CMS Query Engine Parser Translator & Optimizer Executor AST Exec Plan
- 9. Solution To Nosql Challenge – No Multi-Row Transaction Two Phase Commit – It’s not distributed 2PC – Phase 1 : Pre-Commit ○ Optimistic Concurrency Control: check timestamp of each entity to detect writing conflict – Phase 2 : Commit ○ Write Ahead Log: writing log before writing data Recovery – Records all updates in transaction logs – Background thread checks transaction logs to rollback the pending transaction
- 10. Solution To Nosql Challenge – No Concurrency Control Hierarchy locking for tree model – Resource has hierarchy – Locking one resource will check all ancestors Advisory locking for application-defined meanings – Advisory locking is not mandatory – User can use advisory locking to emulate 'pessimistic locks' Lease locking for distributed environment – In a distributed environment, it is always possible that a process can die and never release a lease – Process must renew the lease before it’s expired.
- 11. Solution To Nosql Challenge – No Access Control Role Based Access Control ACL Based Authorization – Define permission in ACL LDAP Based Authentication – Maintain user/group/role relationships in LDAP
- 12. Solution To Nosql Challenge – No Notification Mechanism We use asynchronous publish/subscribe as notification mechanism that is more scalable and loosely decouple. By introducing change log, we can decouple the change generation and change notification. We can provide some advanced features, e.g. changes collapse and multi-thread processing Persistence Manager Data Store Change Logger Change log Change Poller Change Publisher Registration Change Subscriber 1 Change Subscriber N
- 13. Solution To Nosql Challenge – Potential Writing Bottleneck Document DB may have writing bottleneck. Column DB has limited query language We use document store(e.g. MongoDB) as the storage of stable data, and use column store (e.g. HBase) as the storage of transient data. We use a data access layer to hide the different data storage. Query Engine Data Access Layer MongoDB (stable data) HBase (transient data)
- 14. Solution To Nosql Challenge – Distributed Architecture Isolation domain based distributed architecture Network partition tolerance Runtime data partition • Metadata replication • Message-based data replication