Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Another 10 Common Misconceptions about Apache C...

Joan Touzet
September 27, 2018

Another 10 Common Misconceptions about Apache CouchDB

New: Audio recording here: https://feathercast.apache.org/2018/09/29/another-10-common-misconceptions-about-apache-couchdb-joan-touzet/ (sorry, no video!)

Much has changed for Apache CouchDB since 2013, when the previous talk of this title was given. With clustering, advanced querying, overhauled replication, search/geo addons and more, CouchDB is a lot more capable than ever -- which means it's also a lot more misunderstood. Come to this talk to learn more about the ways people tend to misuse CouchDB, and intelligent ways to work better with it.

Appropriate for all levels of experience - from those who haven't even heard of CouchDB, to those who use it daily.

Joan Touzet

September 27, 2018
Tweet

More Decks by Joan Touzet

Other Decks in Technology

Transcript

  1. Just like last time… This presentation is a bit dry.

    But these problems keep coming up on mailing lists, IRC, and in discussion with developers & operators. Today, I’d rather inform than entertain. 2
  2. 1. CouchDB = MongoDB • The “original” NoSQL (…but we

    were provably first!) • Document-oriented structure • Map-Reduce • Streaming changes feeds 4
  3. CouchDB ≠ MongoDB “My party line on Mongo vs. Couch

    is that on the surface they might look similar (database, documents, JSON-ish), but when you look at implementation, at every of the 100,000 decisions you have to make when building such a thing, Mongo went one way, and we went another.” – Jan Lehnardt, VP Apache CouchDB 5
  4. CouchDB ≠ MongoDB MongoDB • Binary protocol • BSON (binary)

    • Speed • Features CouchDB • HTTP API • JSON • Durability (append only) • Scalability 6
  5. CouchDB ≠ Couchbase Couchbase • No longer compatible with CouchDB

    or PouchDB! • Frankenproduct of Membase + CouchDB fork • Commercial product CouchDB • Replication is our killer feature! • Does one thing well. Plays great with Redis, Apache Spark, etc. • Apache-licensed OSS 7
  6. Installing CouchDB! Packages from Apache repositories now available! (See docs.couchdb.org)

    – apt install couchdb – yum install couchdb 64-bit Windows installer also available (for development) – Please don't run CouchDB on Windows in production! macOS installer available (for development) FreeBSD ports tree now has CouchDB 2.2.0, too. Docker image available as apache/couchdb or couchdb 9
  7. 3. Scaling via replication Yes … but not in the

    way you think! 11 CouchDB 1.x CouchDB 2.x HTTP 1 2 3 Erlang
  8. What does this mean? CouchDB 2.x has native clustering functionality

    “Internal replication” is optimized for this process CouchDB 2.x shards the database for optimization CouchDB has no leader election or “global coordinator”! 12
  9. Database / View Sharding 13 q = # of shards

    (default: 8) (4 here for a small picture) n = number of replicas (default: 3)
  10. Deployment Recommendations 1. Keep all nodes in the same AZ

    / data centre / rack 2. Stick with the defaults (q=8, n=3) unless you’re really small (1 node) or really big (>50GB JSON DB) 3. Use HAProxy for your load balancer, it’s the best! 14
  11. 4. MapReduce is (still) hard. Now, you have three easier,

    fantastic options! 1. Mango 2. Full-text Search† (Apache Lucene powered) 3. Geospatial Search† †Provided by 3rd-party add-ons, requires recompile. 17
  12. What is Mango? Declarative, JSON-based query language Designed to meet

    ≥75% of all your querying needs Inspired by a well-known NoSQL competitor's query… Actually the same Map-Reduce implementation underneath! 18
  13. Introduction to Mango A. Prototype your query. B. Make an

    index to speed it up. C. Check & use your index in your query. 19
  14. Mango selectors are powerful. { "zagat.rating": { "$gt": 18 }

    } { "michelin.stars": { "$exists": true } } {"cuisine": { "$all": ["Malaysian","Singaporean"] }} …and everything is specified in the selector at query time! 20
  15. In JavaScript… { "zagat.rating": { "$gt": 18 } } if

    (doc.zagat && doc.zagat.rating && doc.zagat.rating === int(doc.zagat.rating)) { if (doc.zagat.rating > 18) { return(doc._id, null); } } 21
  16. A. Prototype your query. $ curl –H "Content-type: application/json" –X

    POST \ http://localhost:5984/mydb/_find \ -d '{"selector": { "food": "chili" }}' | jq . { "docs": [ { "_id": "b", "_rev": "1-0f07c7dbc9a29f0d0c2729f9c61f5411", "name": "Chris", "food": "chili" } ], "bookmark": "g1AAAAAyeJzLYWBgYMpgSmHgKy5JLCrJTq2MT8lPzkzJBYozJoEkOGASEKEsAE8ZDXs", "warning": "no matching index found, create an index to optimize query time" } 22
  17. B. Make an index. $ curl –H "Content-type: application/json" \

    –X POST \ http://localhost:5984/mydb/_index \ -d '{"index": { "fields": ["food"] }, "ddoc": "food", "type": "json"}' { "result": "created", "id": "_design/food", "name": "f9aed20d8e363a7066bfd32ee016b6280163b99a" } 23
  18. C. Check & use your index. $ curl –H "Content-type:

    application/json" –X POST \ http://localhost:5984/mydb/_explain \ -d '{"selector": { "food": "chili" }, "use_index": "food"}' | jq . { "dbname": "abc", "index": { "ddoc": "_design/food", ... }, "selector": { "food": { "$eq": "chili" } }, "opts": { "use_index": [ "food" ], ... }, "limit": 25, "skip": 0, "fields": "all_fields", ... } } 24
  19. C. Check & use your index. $ curl –H "Content-type:

    application/json" –X POST \ http://localhost:5984/mydb/_find \ -d '{"selector": { "food": "chili" }, "use_index": "food"}' | jq . { "docs": [ { "_id": "b", "_rev": "1-0f07c7dbc9a29f0d0c2729f9c61f5411", "name": "Chris", "food": "chili" } ], "bookmark": "..." } 25
  20. Mango Pro Tips 1. Index on all the fields you

    use in your selector. 2. Index use is automatic, but double-check /{db}/_explain before going into production! 3. Avoid $in and $regex unless absolutely necessary. – These operators are always a full db/index scan! That means they're slow! – If you really need this, look into the Lucene-powered full-text search add-on. 4. Mango indexes still use design documents. – check out _design/food after trying this example! 5. Use selectors for replication instead of JavaScript filters - way faster! 26
  21. 5. “Cool, attachments!” Large attachments can create performance issues, especially

    for replication. – Replication of entire database will be held up by big attachments • This is also true for node-to-node internal cluster replication! – Large files can rapidly eat available disk space – >1GB attachments are not a first-order design scenario. Attachments are not available to views or Mango. You wouldn’t store video files as BLOBs in Oracle, would you? 28 Repeat!
  22. New Recommendations • Use Couch doc _id or GUIDs to

    tag large assets • Stash them in S3, B2, Dropbox, NextCloud, etc. • If you must use them: ≤16 MB total per Couch doc. • Upgrade to CouchDB ≥2.2.0 (see bug #745) 29
  23. 6. (Ab)using the primary index CouchDB 1.x: “I put my

    document type in the document's _id. “Then I just use sub-range queries on /{db}/_all_docs…” GET /{db}/_all_docs?startkey=type_###&endkey=type_### 31
  24. New Recommendation 2.x: Use Mango partial indexes! • Index only

    contains matching docs • Can further narrow scope at query time meaningfully • You must add the use_index parameter at query time Example /{db}/_index : { "index": { "partial_filter_selector": { "type": "account", "status": { "$ne": "archived" } } }, "fields": [ … ] } 32
  25. 7. Deleting Documents “I upload sensor data, process it, then

    delete it.” In other words, CouchDB as ersatz message queue 33 mydoc
  26. Doc Deletion Options 1. Rolling Databases: – Write/read only from

    the database you need – When done, archive or delete as necessary – Pick your own appropriate time interval 34 June 2018 July 2018 August 2018
  27. Doc Deletion Options 2. Replicate-to-remove: – Filter out deleted documents

    during replication – Swap DB when done. Opportunity to re-shard if desired! – Do this with a single command using: https://github.com/neighbourhoodie/couchdb-continuum 35 Original DB Cleaned DB Filtered Replication
  28. Doc Deletion Options 3. Maybe CouchDB isn't right for you…

    – Consider a time-series database (like OpenTSDB) – Consider a true message queue (like RabbitMQ) 4. Clustered purge (CouchDB ≥2.3.0) may help (but is not a panacea, read the docs on release) 36
  29. 8. “Conflicts? What are those?” “I write a document. I

    never check for conflicts.” “I write a document, if I get a conflict, I just write it again.” 37 mydoc _rev 7
  30. How conflicts happen 38 bob v1 bob v1 bob v1

    bob v1 bob v2a bob v2a bob v2b bob v2b bob v2a v2b bob v2a v2b bob v2a v2b bob v2a v2b
  31. How conflicts also happen 41 bob v2a bob bob bob

    bob v2b v2b v2b v2b bob v2b 00:01.001
  32. How conflicts also happen 42 bob v2a bob bob bob

    bob v2b v2b v2b v2b bob v2b ✕ 00:01.002
  33. How conflicts also happen 43 bob v2a bob bob bob

    bob v2b v2b v2b v2b bob v2b ✕ ✕ 00:01.003
  34. How conflicts also happen 44 bob v2a bob bob bob

    bob v2b v2b v2b v2b bob v2b copies = 2 n = 3 Quorum OK copies = 1 n = 3 Quorum NG 00:01.004 Quorum: ൒ ௡ାଵ ଶ copies
  35. How conflicts also happen 45 bob v2a bob bob bob

    bob v2b v2b v2b v2b bob v2b copies = 2 n = 3 Quorum OK copies = 1 n = 3 Quorum NG 201 Created 00:01.009 202 Accepted
  36. How conflicts also happen 46 bob v2a bob v2b bob

    v2a bob v2b bob v2a bob v2b 00:01.010 bob v2a “arbitrarily” wins!
  37. How to detect & resolve conflicts #1 Best option: •

    Listen for 201 Created vs. 202 Accepted – Check your library code: many libraries don't differentiate!! • Whoever receives a 202 must decide what to do! • Best if automatic winner selection is NOT OK. 47
  38. How to detect & resolve conflicts Second best option: •

    Look for conflicts in a system cleanup script – Use Mango with selector {"conflicts": true} (CouchDB ≥2.2.0) • Cleanup script must decide what to do! • Best if merging the documents can be done later. 48
  39. How to detect & resolve conflicts Third best option: •

    Look for conflicts in a system cleanup script – Use Mango with selector {"conflicts": true} (CouchDB ≥2.2.0) • Cleanup script just deletes losing document • Best if automatic winner selection is OK. 49
  40. 10. Counting with _rev / seq CouchDB 1.x: “_rev always

    increments by 1, right?” “DB sequence numbers give me absolute document ordering!” 50 w3resource.com (CC BY-NC-SA 3.0)
  41. 9. Counting with _rev / seq CouchDB 2.x clustering means

    developers must think more about the implications of distributed systems. _rev / seq now include information about the cluster state at the time of generation. 52 w3resource.com (CC BY-NC-SA 3.0)
  42. 9. Counting with _rev / seq 53 GET /db/_changes [{node1,

    00-79, 0}, {node2, 80-FF, 1}] [{node1, 80-FF, 1}, {node2, 00-79, 0}] bob v2 zim v1 bob v1 zim v2 00:07.00 Decoded for explanation q = 2 Either response is OK – and intuitive!
  43. 9. Counting with _rev / seq 54 bob v2 zim

    v2 bob v2 zim v2 00:07.20
  44. 9. Counting with _rev / seq 55 GET /db/_changes [{node1,

    00-79, 1}, {node1, 80-FF, 1}] [{node1, 00-79, 1}, {node2, 80-FF, 1}] [{node2, 00-79, 1}, {node1, 80-FF, 1}] [{node2, 00-79, 1}, {node2, 80-FF, 1}] bob v2 zim v2 bob v2 zim v2 00:07.30 Any one of these 4 responses is possible & correct!
  45. 9. Responsibly using seq values 1. GET /{db}/_changes one line

    at a time 2. Process each row idempotently. – That means apply the change independent of other rows, or their ordering 3. Periodically store the seq/last_seq value of the last row you processed 4. If you crash, restart: GET /{db}/_changes?seq={value} 56
  46. 9. Responsibly using _rev values CouchDB is eventually consistent. Absolute

    document ordering is not a guarantee. Remember: Compaction, and internal or external replication, can and will remove intermediate document revs! Last ditch option: q=1, n=1 (no clustering, not scaleable) 57
  47. What about SQL SEQUENCE? Again, CouchDB is eventually consistent. CouchDB

    does not provide a guaranteed, globally unique, monotonically increasing sequence number. Use UUIDs instead. GET /_uuids is convenient! 58
  48. 10. “Monitoring? CouchDB?” “I monitor the host, but not CouchDB

    itself. “It is self-healing, right?” 60
  49. Easy option: NetData Per-node web service, fixed RAM & CPU

    usage Can feed into most back-ends 61 http://my-netdata.io/
  50. Monitoring CouchDB Per-node endpoints you should track & graph: GET

    /_node/_local/_stats – CouchDB specific data GET /_node/_local/_system – Erlang and OS-level data 64