On Jul 8, 2014, at 5:31 PM, Len Kawell <[email protected]> wrote:
> (1) A previous post in this forum suggested that compact runs on the > replicator's thread, but from what I can see it seems to run synchronously on > the thread it's been invoked from (e.g., main thread). Is that the case? Yes, it runs on the thread you invoke it on. > (2) Does compact "lock" the database from other access and threads? Yes. > (3) Is there any benefit or problem with invoking compact on another thread > using either CBLManager -backgroundTellDatabaseNamed:to: or by using a > CBLManager copy to make another CBLDatabase instance in another thread? Well, it will let your main thread do other stuff during the compaction. But if it makes any CBL calls it'll block till the compaction finishes, because the database is locked. > (4) Is compact "safe" to run automatically without the user's involvement? > For example, if the user powers off their device while compact is > in-progress, should the database be OK? Or should I display a warning message > to try to avoid that? Well, you don't want the app to get terminated by the OS in the middle of a compact. The database shouldn't be corrupted by this (it's supposed to be impossible to corrupt a SQLite database these days) but I don't know what state it'll be in afterwards. > (5) Are there any replication issues to be aware of with compact? For > example, does it play nice with the replicator task itself? Will pending, > non-replicated updates get replicated OK after the compact if it's done while > offline? The only effect it'll have on replication is that it will prune some very old revisions. That won't affect anything that hasn't been replicated already. > (6) Are there any built-in database statistics or metadata that I could use > to trigger compact? Or should my app maintain its own document and attachment > update and deletion counts somewhere? Or maybe just do a compaction > periodically? I would just do it periodically. > (7) What sort of performance should we expect from compact? Is there any way > to give the user a progress UI or possibly an estimate of the time it will > take? Not really; most of it is just a small number of SQLite commands that each can take a long time to finish. > For example, I found running it the first time on a 7.5GB test database it > took about 2 minutes on an iPad Air: Yow, that's really big. Compaction is definitely going to take a long time on a database that size -- it should be run more regularly. > 2014-07-08 11:17:47.278 App[6015:60b] Starting database compact... > 11:19:40.907| CBLDatabase: Deleting JSON of old revisions... > 11:19:41.728| Deleting old attachments... > 11:19:42.131| Deleted 75 attachments > 11:19:42.131| Flushing SQLite WAL... > 11:19:42.414| Vacuuming SQLite database... > 11:19:49.736| Closing and re-opening database... > 11:19:49.740| ...Finished database compaction. > 2014-07-08 11:19:49.739 App[6015:60b] Database compact done - error = (null) It looks like pruning old revisions is what's taking most of the time (almost two minutes.) I don't know if that query could be made more efficient. Mostly I'd recommend running the compaction more often so there's less to clean up. (For what it's worth, ForestDB, which we're going to switch to from SQLite in the future, runs compaction automatically in the background and it doesn't block access to the database. It's much more like CouchDB compaction.) --Jens -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/2A6BADD3-B8D6-4E0C-8B92-943BD906BE7A%40couchbase.com. For more options, visit https://groups.google.com/d/optout.
