Partition key from option #229
Conversation
jannyHou
force-pushed
the
partition-key-from-option
branch
from
3ba9e5f to
8aefe67
Compare
package.json
Outdated
| @@ -29,9 +29,10 @@ | |||
| "fs-extra": "^8.1.0", | |||
| "lodash": "^4.17.11", | |||
| "loopback-connector": "^4.0.0", | |||
| "loopback-connector-couchdb2": "^1.5.1", | |||
| "loopback-connector-couchdb2": "github:strongloop/loopback-connector-couchdb2#add-option-for-search", | |||
There was a problem hiding this comment.
Don't forget to switch back to npm released version.
jannyHou
force-pushed
the
partition-key-from-option
branch
from
57762cb to
eef9b60
Compare
jannyHou
force-pushed
the
partition-key-from-option
branch
from
7770c30 to
dffebe8
Compare
| db.automigrate('Product', () => { | ||
| Product.create(SEED_DATA, function(err) { | ||
| if (err) return done(err); | ||
| Product.find({where: {tag: 'food'}}, {partitionKey: 'toronto'}, |
There was a problem hiding this comment.
Just out of curious, I guess the performance of partition + where(#L196) is better than doing where on find() normally?
There was a problem hiding this comment.
@agnes512 Exactly, if you are interested to learn more about this feature, it's explained in https://docs.couchdb.org/en/master/partitioned-dbs/index.html.
An example: you have 200 documents in partition US and 300 documents in partition CA, when you do a global search, you find among 500 documents, but if you specify partitionKey as US and perform a partitioned search, you find among those 200 documents.
| {id: `london: ${uuid()}`, name: 'beer', tag: 'drink'}, | ||
| {id: `london: ${uuid()}`, name: 'salad', tag: 'food'}, | ||
| {id: `london: ${uuid()}`, name: 'salad', tag: 'food'}, | ||
| ]; |
There was a problem hiding this comment.
What if I have a 7th record {id: toronto: ${uuid()}, name: 'dessert', tag: 'food'},, would it be included to the result of the above test case?
There was a problem hiding this comment.
yep, because its partitionKey is toronto(matches your partition key) and is tagged as food(match your query).
There was a problem hiding this comment.
I see, the name partitionKey always makes me think of operations based on index.
There was a problem hiding this comment.
Yep they are related :)
The benefit of partitioned databases is that secondary indices can be significantly more efficient when locating matching documents since their entries are contained within their partition. This means a given secondary index read will only scan a single partition range instead of having to read from a copy of every shard.
My understanding is index is a secondary optimization for search.
* chore: update copyright year (Agnes Lin) * replace couchdb3 docker img with a stable version (Agnes Lin) * docs: add partition document (#232) (Janny) * fixup!: fix the dependency version (#233) (Janny) * feat: query with partition field (#230) (Janny) * chore: improve issue and PR templates (Nora) * feat: add partitioned find (#229) (Janny) * add docker setup script (#227) (Janny) * feat: partitioned index (#225) (Janny) * fix CODEOWNERS file (Diana Lau) * update docker image (#224) (Janny)
Description
Prerequisite PR: loopbackio/loopback-connector-couchdb2#71
connect to #220
To trigger the
partitonedFind, you can include thepartitionKeyfield inoptionslike:Related issues
options#220Checklist
guide