introduction to bigcouch
play

INTRODUCTION TO BIGCOUCH robert newson couchdb conf berlin - PowerPoint PPT Presentation

INTRODUCTION TO BIGCOUCH robert newson couchdb conf berlin january 2013 1 Friday, 25 January 13 INTRODUCTIONS robert newson BigCouch CouchDB pmc member Putting the C back in CouchDB irc menace Contact rnewson@apache.org rnewson


  1. INTRODUCTION TO BIGCOUCH robert newson couchdb conf berlin january 2013 1 Friday, 25 January 13

  2. INTRODUCTIONS robert newson BigCouch CouchDB pmc member Putting the “C” back in CouchDB irc menace Contact rnewson@apache.org rnewson in #cloudant or #couchdb @rnewson 2 Friday, 25 January 13

  3. WHAT WE TALK ABOUT WHEN WE TALK ABOUT SCALING • Horizontal scaling: more servers creates more capacity • Transparent to the application: adding more capacity should not a ff ect the business logic of the application. • No single point of failure. Pseudo Scalars http://adam.heroku.com/past/2009/7/6/sql_databases_dont_scale/ 3 Friday, 25 January 13

  4. BIGCOUCH = COUCH+SCALING • Horizontal Scalability Easily add storage capacity by adding more servers Computing power (views, compaction, etc.) scales with more servers • No single point of failure (SPOF) Any node can handle any request With quorum, individual nodes can come and go • Transparent to the Application All clustering operations take place “behind the curtain” ‘looks’ like a single server instance of Couch, just with more awesome asterisks and caveats discussed later 4 Friday, 25 January 13

  5. GRAPHICAL REPRESENTATION • Clustering in a ring (a la Dynamo) PUT http://rnewson.cloudant.com/dbname/blah?w=2 • Any node can handle a request • O(1) lookup Load Balancer • Quorum system (N, R, W) • Views distributed like documents Node 1 Node 24 N o • Distributed Erlang d e A B C D 2 A B Z C • Masterless Y D hash(blah) = E X E Node 3 C D N=3 E F W=2 R=2 D Node 4 E F G 5 Friday, 25 January 13

  6. BUILDING YOUR FIRST CLUSTER • Shopping List Dependencies brew install erlang icu4c spidermonkey brew ln icu4c • Erlang (R13B03+) • ICU • Spidermonkey • LibCurl git clone https://github.com/cloudant/bigcouch.git • OpenSSL cd bigcouch ./configure • make make dev • Python 6 Friday, 25 January 13

  7. BUILDING YOUR FIRST CLUSTER rel/dev1/bin/bigcouch rel/dev2/bin/bigcouch rel/dev3/bin/bigcouch dev1 dev2 dev3 Join the cluster curl localhost:15986/nodes/dev2@127.0.0.1 -X PUT -d '{}' curl localhost:15986/nodes/dev3@127.0.0.1 -X PUT -d '{}' ... and verify curl http://localhost:15984/_membership 7 Friday, 25 January 13

  8. QUORUM: IT’S YOUR FRIEND • BigCouch Clusters are governed by 4 parameters Q: Number of shards per DB N: Number of redundant copies of each document R: Read quorum constant W: Write quorum constant (NB: Also consider the number of nodes in a cluster) 1 For the next few 5 2 examples, consider a 5 node cluster 4 3 8 Friday, 25 January 13

  9. Q • Q: The number of shards over which a DB will be spread consistent hashing space divided into Q pieces Specified at DB creation time possible for more than one shard to live on a node Documents deterministically mapped to a shard More shards = faster view builds Less shards = better memory management 1 5 2 4 3 Q=1 Q=4 9 Friday, 25 January 13

  10. N • N: The number of redundant copies of each document Choose N>1 for fault-tolerant cluster Default specified at DB creation Each shard is copied N times Recommend N>2 1 5 2 N=3 4 3 10 Friday, 25 January 13

  11. W • W: The number of document copies that must be saved before a document is “written” W must be less than or equal to N W=1, maximise throughput W=N, maximise consistency Allow for “202” created response Can be specified at write time 1 5 2 ‘201 ok’ 4 3 W=2 11 Friday, 25 January 13

  12. R • R: The number of identical document copies that must be read before a read request is ok R must be less than or equal to N R=1, minimise latency R=N, maximise consistency Can be specified at query time 1 5 2 4 3 R=2 12 Friday, 25 January 13

  13. Views • So far, so good, but what about secondary indexes? Views are built locally on each node, for each DB shard Merge sort at query time using exactly one copy of each shard Run a final re-reduce on each row if the view has a reduce • _changes feed works similarly, but has no global ordering 1 Sequence numbers converted to JSON to encode more information 5 2 4 3 14 13 Friday, 25 January 13

  14. API AND CAVEATS • Clustered API By default listens on port 5984 All single-doc operations and most view operations • What’s Di ff erent? update_seq value is now opaque JSON rereduce=true always called on reduce views no temporary views no all_or_nothing: true • ‘Backdoor’ Access Able to reach a single node (i.e. at the shard level) By default listens on port 5986 Allows you to trigger local view updates, compactions, etc. 14 Friday, 25 January 13

  15. Hacker Portion The BigCouch Stack CHTTPD Fabric Rexi Mem3 Embedded CouchDB Mochiweb, Spidermonkey, etc. 15 Friday, 25 January 13

  16. chttpd / fabric • Chttpd Cut-n-paste of couch_httpd, but using fabric for all data access • Fabric OTP library application (no processes) responsible for clustered versions of CouchDB core API calls CHTTPD Quorum logic, view merging, etc. Provides a clean Erlang interface to Fabric BigCouch Rexi Mem3 Embedded CouchDB Mochiweb, Spidermonkey, etc. 16 Friday, 25 January 13

  17. Mem3 • Maintains the shard mapping for each clustered database in a node-local CouchDB database • Changes in the node registration and shard mapping databases are automatically replicated to all cluster nodes CHTTPD Fabric Rexi Mem3 Embedded CouchDB Mochiweb, Spidermonkey, etc. 17 Friday, 25 January 13

  18. Rexi • BigCouch makes a large number of parallel RPCs • Erlang RPC library not designed for heavy parallelism promiscuous spawning of processes responses directed back through single process on remote node requests block until remote ‘rex’ process is monitored • Rexi removes some of the safeguards CHTTPD in exchange for lower latencies no middlemen on the local node Fabric remote process responds directly to client remote process monitoring occurs out-of-band Rexi Mem3 Embedded CouchDB Mochiweb, Spidermonkey, etc. 18 Friday, 25 January 13

  19. FUTURE 19 Friday, 25 January 13

  20. BIGCOUCH HAS NO FUTURE 20 Friday, 25 January 13

  21. THE FUTURE IS COUCHDB 21 Friday, 25 January 13

  22. WE’RE MERGING 22 Friday, 25 January 13

  23. THE MERGE • Release BigCouch 0.5.0 • Release Apache CouchDB 1.3.0 • Merge them • Release Apache CouchDB 2.0.0 (couchdb strikes back) 23 Friday, 25 January 13

  24. SUMMARY • BigCouch: putting the ‘C’ back in CouchDB • Consistent hashing for database sharding (a la Dynamo) • True horizontal scalability with CouchDB • Download now and get started https://github.com/cloudant/bigcouch.git 24 Friday, 25 January 13

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend