CODEWITHSUNDEEP
sqlperformancecouchdb
Marek Kowalski
Marek Kowalski

Reputation: 1792

What is a best way to organise the complex couchdb view (sql-like query)?

In my application I need a SQL-like query of the documents. The big picture is that there is a page with a paginated table showing the couchdb documents of a certain "type". I have about 15 searchable columns like timestamp, customer name, the us state, different numeric fields, etc. All of these columns are orderable, also there is a filter form allowing the user to filter by each of the fields.

For a more concrete below is a typical query which is a result by a customer setting some of the filter options and following to the second page. Its written in a pseodo-sql code, just to explain the problem:

timestamp > last_weeks_monday_epoch AND timestamp < this_weeks_monday_epoch AND marked_as_test = False AND dataspace="production" AND fico > 650 SORT BY timestamp DESC LIMIT 15 SKIP 15

This would be a trivial problem if I were using any sql-like database, but couchdb is way more fun ;) To solve this I've created a view with the following structure of the emitted rows:

key: [field, value], id: doc._id, value: null

Now, to resolve the example query above I need to perform a bunch of queries:

Once I have the results of the queries above I calculate intersection of the sets of document IDs and apply the sorting using the result of timestamp query. Than finally I can apply the slice resolving the document IDs of the rows 15-30 and download their content using bulk get operation.

Needless to say, its not the fastest operation. Currently the dataset I'm working with is roughly 10K documents big. I can already see that the part when I'm calculating the intersection of the sets can take like 4 seconds, obviously I need to optimize it further. I'm afraid to think, how slow its going to get in a few months when my dataset doubles, triples, etc.

Ok, so having explained the situation I'm at, let me ask the actual questions.

  1. Is there a better, more natural way to reach my goal without loosing the flexibility of the tool?

  2. Is the view structure I've used optimal ? At some point I was considering using a separate map() function generating the value of each field. This would result in a smaller b-trees but more work of the view server to generate the index. Can I benefit this way ?

  3. The part of algorithm where I have to calculate intersections of the big sets just to later get the slice of the result bothers me. Its not a scalable approach. Does anyone know a better algorithm for this ?

Upvotes: 2

Views: 376

Answers (2)

djc
djc

Reputation: 11711

I don't think CouchDB is a good fit for the general solution to your problem. However, there are two basic ways you can mitigate the ways CouchDB fits the problem.

  1. Write/generate a bunch of map() functions that use each separate column as the key (for even better read/query performance, you can even do combinatoric approaches). That way you can do smart filtering and sorting, making use of a bunch of different indices over the data. On the other hand, this will cost extra disk space and index caching performance.

  2. Try to find out which of the filters/sort orders your users actually use, and optimize for those. It seems unlikely that each combination of filters/sort orders is used equally, so you should be able to find some of the most-used patterns and write view functions that are optimal for those patterns.

I like the second option better, but it really depends on your use case. This is one of those things SQL engines have been pretty good at traditionally.

Upvotes: 1

Kxepal
Kxepal

Reputation: 4679

Having map function:

function(doc){
    if(doc.marked_as_test) return;
    emit([doc.dataspace, doc.timestamp, doc.fico], null):
}

You can made similar request:

 http://localhost:5984/db/_design/ddoc/_view/view?startkey=["production", :this_weeks_monday_epoch]&endkey=["production", :last_weeks_monday_epoch, 650]&descending=true&limit=15&skip=15

However, you should pass :this_weeks_monday_epoch and :last_weeks_monday_epoch values from the client side (I believe they are some calculable variables on database side, right?)

If you don't care about dataspace field (e.g. it's always constant), you may move it into the map function code instead of having it in query parameters.

Upvotes: 1

Related Questions