Performance of CouchBase Lite on mobile

[Nathan Mellor]

Excuse the ignorance exposed by my question.

I'm just deciding on database technology for my application. 

Lets suppose that a user has a bunch of datasets (probably documents in couchdb language).
Lets suppose each of these database has a bunch of points and lines and metadata for display on a map on the mobile screen or on a web page.

My default scenario.
A bunch of SQLite databases synchronized as files in a dropbox/google drive manner. Only synchronization is on the file level.
SQlite functions are used to query create update and delete data.
Unless I manage to load spatialite extensions, spatial queries would be somewhat limited, but that's okay as long as I can get a bounding box query.
This means the server backend would also have to have to read SQLite for display on a web page. Probably not as ideal.

Another scenario:
I use CouchBase Mobile.
Use user dataset is a Document.
I hear CouchBase Mobile is super good at synchronizing that stuff. Good.
When it comes to querying points, line, text, for display on the mobile screen, is CouchBase Lite going to have great performance?
How does it compare in that aspect to SQLite?
Will it be able do queries many times a second?

I've tried to find information about this, but I am not doing the right search.
Am I thinking of a valid use case for Couchbase Mobile?

Nathan

[Jens Alfke]

On Sep 6, 2017, at 5:20 PM, Nathan Mellor <nathan....@gmail.com> wrote:

Use user dataset is a Document. 
I hear CouchBase Mobile is super good at synchronizing that stuff. Good. 
When it comes to querying points, line, text, for display on the mobile screen, is CouchBase Lite going to have great performance?
How does it compare in that aspect to SQLite? 

I gather that each of your data sets is a big collection of geo data, like arrays of coordinates?

Putting an entire data set into a single document isn't the way one would normally do it. Any database works best when you keep the documents/records/rows small, because generally these are the units of I/O. Also, in Couchbase Lite documents are the units of replication, so any change to a document causes that entire document to be replicated again.

As for querying, databases generally aren't good at queries within a single document/record; instead they search across records. In Couchbase Lite it is possible, with some creative use of map/reduce, to index and query within a single document; however, I don't recommend this because it's not future-proof: version 2.0 is replacing map/reduce with a more traditional query language based on N1QL, which is a lot more powerful in most ways but doesn't support some of the use cases of map/reduce such as this one.

What I'm saying is that it would be best to store each "item" in a data set (whatever the granularity of an "item" is for your use case) as a document. You can still store multiple data sets in a database by tagging the documents with some property like "dataset" whose value is a unique identifier.

Will it be able do queries many times a second?

That depends on a lot of variables like the size of the data set, how complex the queries are, and the OS and performance of the device you're running on. (For example, current iPhones have much faster SSDs than most current Android devices.)

Also, the iOS/Mac version of Couchbase Lite is the only one that currently supports geo-queries. The good news is we're going to implement geo on all platforms, but the bad news is the feature got pushed back out of 2.0, with the result that 2.0 will not support geo on any platform, while 2.1 [probably] will have it on all. Without geo support, your queries will be more expensive.

—Jens