Bundle a database in an API

I am currently working on a project where in which I need to package a database along with a JAVA API. The database should be secured in a sense , no one should be able to access it apart from the API. The point is that the data in the database is intellectual property and should not be exposed.Here is the catch. The database contains approximately 5 million records(4-5 columns only). I need to query it based on indexed fields with aggregate functions as well. I am quite aware there are java embedded databases such as derby,hsql and their likes. But I seriously doubt their performance.I know the requirement sounds weird. But atleast its a start.

The API is meant to be accessed concurrently and needs to retrieve lookup values from this database.Is this really a good design or is there something wrong with the approach.Any architectureal suggestions are welcome

NewInfo: If an 开发者_StackOverflow中文版embeded database seems not promising, how about an embeded file to be put along with the API. Would this be feasible ?

---

If you're distributing the database, you're not going to prevent people from accessing it directly. That's just DRM, and as we know from long experience, DRM doesn't work.

The simplest way to keep the data private is to keep it on a server you control, and provide a network API. That also allows you to use the database of your choice.

If you do keep it on the client, I think you'll find the embedded databases perform better than you expect. Another good option is SQLite.

I'm not sure exactly what kind of concurrency you need. Do you envision multiple programs on a given client accessing the database simultaneously?

---

I would use H2 database with pure JDBC api. H2 is ultra fast and supports encryption. For security reasons, you could store the key to your encrypted database somewhere else (on some auth server?). And you probably won't be able to find something faster then pure JDBC.

---

I agree with Matthew that you simply cannot prevent the user from getting access to it. You also make it pretty easy if you are using a standard DB engine. You'll pretty much be limited to encrypting the data and then decrypting it into memory so that you can query it.

SQLite is a good embedded database, but does poorly with concurrency. HSQL, Derby or anything else should work pretty well if you can keep it in memory.