0

Our project utilizes a static database (no writes). With many users we don't actually have a problem per se reading it. If a database "locks" per read request by any user, then would it not be more efficient (though perhaps unnoticeable) to have multiple databases that each user connects to individually?

We are database noobs. Apologies in advance if this is in the wrong place. We are planning on using BoltDB or LMDB for our project, but personally I was intrigued by this idea.

|improve this question
  • 3
    If the data never changes, why lock on reads? Locks are only necessary because of updates and atomicity. – Kasey Speakman Oct 15 '15 at 17:12
  • We're new to databases. Didn't know we could unlock them. Thought that was just the nature of how they worked. – victoroux Oct 15 '15 at 17:44
  • Depends on the database, but it can be a change-able default setting whether or not reads are locked. Or it can be a per-read setting (e.g. a keyword in SQL SELECT statements). – Kasey Speakman Oct 15 '15 at 17:46
5

Unless your database is measured in Terabytes and your concurrent user count is astronomical, don't bother.

Modern databases are very fast, especially for reading.

You should wait until you actually have the problem then measure to confirm you have the problem before you try to fix anything.

If you run multiple read-only databases in parallel, you now have the maintenance problem of ensuring they are in fact identical. Debugging the situation when they're not can be painful.

|improve this answer
  • Databases will literally never change in this project (silly, I know, but it's not for production or anything). This answer makes sense and we honestly didn't think it'd be noticeable. I was just curious if it were even a viable option had the problem occured. On a similar note, is there anything one could do in a high-bandwidth, low-cpu server set-up to speed things up? Thank you for the answer, I have to wait 5 mins to mark it correct. – victoroux Oct 15 '15 at 16:59
  • 1
    As with all optimization problems, you really have to measure very carefully to see if the bottleneck is where you think it is. It might be how the data is arranged, it might be other processes, it might be lack of memory, and so on. – Dan Pichelman Oct 15 '15 at 17:02
  • Ah, we're very new to database work. We'll look into these measurement tools and see if we can figure out how they work. Thank you so much! – victoroux Oct 15 '15 at 17:04
2

You should read your chosen database's documentation more carefully. In LMDB, readers are entirely lockless and wait-free, so your entire "if a database locks" premise is invalid.

|improve this answer
  • "Please note that Bolt obtains a file lock on the data file so multiple processes cannot open the same database at the same time. Opening an already open Bolt database will cause it to hang until the other process closes it." from github.com/boltdb/bolt – victoroux Oct 19 '15 at 19:46
1

From the database side no locks are held for SELECT statements.

Proposing to have multiple static databases is like proposing to use files like (spreadsheets or plain text) to have the data available to each user.

The whole concept of the database is to have a centralized repository for all users to "share" the same data-base.

If you database is huge and you will have an enormous amount of concurrent users you may have to think about clustering. But in your case, I think that's not an option.

If you read a little about LMDB and BoltDB, you'll see that they behave like mainframes, and the point there is to have a single repository, even more, a single file to hold all of your data.

When thinking about databases, think about centralizing the data and distributing the workload.

Hope this helps you clear out some clouds.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.