Sandra,
sorry for the late feedback, and thanks for all details on your setup.
I am thinking of doing nightly updates/rebuilds/reindexing on a separate VM (for big updates), then just pushing the BaseXData/db dir via rsync and stopping/restarting the query basex server with the new database in place of the old.
Yes, that's a realistic scenario – and there are enough other BaseX uses cases with similar challenges, so we've already developed (still vague) plans to do something similar within BaseX. Snapshots of the database could be used for read-only queries, while the updates are performed on the main database – and the snapshot is refreshed afer the updates have been finalized. Still work in progress, though.
Performance is very very good with well written online queries. Within a few weeks our search interface will go public and you can see for yourself -- I will let you know.
…nice.
However, I have encountered rather bad problems with long and complex queries with a lot of output. With basex these jobs would just kind of "hang".
If you come across these ones again, just tell us.
This also aligns with my experience. A complete reload/index build is about 3 mins for us on a 8gb VM on a dell server. I give the JVM ~ 4gb via -Xms and -Mx. Not terribly painful but as I mention above, I will need to pull a few tricks when we are running a public online search -- a 3 minute outage for updating is unnacceptable.
No doubt. A mirror of the database could indeed be the best solution, and as soon as our transactions are based on databases – and not processes, one BaseX instance will suffice to update one db and perform the other via read-only. We'll keep you informed (but it might take some time; the todo list is still long enough to keep us busy).
Best, Christian