I'm presently focusing on a task whereby which I have to package a database together with a JAVA API. The database ought to be guaranteed in this way , nobody should have the ability to can get on aside from the API. The thing is the data within the database is intellectual property and cannot be uncovered.This is actually the catch. The database consists of roughly 5 million records(4-5 posts only). I have to query it according to indexed fields with aggregate functions too. I'm quite aware you will find java embedded databases for example derby,hsql as well as their likes. However I seriously doubt their performance.I understand the necessity sounds strange. But atleast its a start.

The API is intended to be utilized at the same time and requires to retrieve research values out of this database.Is a real good design or perhaps is there a problem using the approach.Any architectureal suggestions are welcome

NewInfo: If the embeded database appears not promising, what about an embeded file to become put together with the API. Would this be achievable ?

If you are disbursing the database, you are not likely to prevent people from being able to access it directly. That's just DRM, and as you may know from lengthy experience, DRM does not work.

The easiest method to keep your data private would be to ensure that it stays on the server you control, and supply a network API. Which enables you to employ the database of your liking.

Should you choose ensure that it stays around the client, I think you will discover the embedded databases perform much better than you anticipate. One other good choice is SQLite.

I am unsure precisely what type of concurrency you'll need. Would you picture multiple programs on the given client being able to access the database concurrently?

I'd use H2 database with pure JDBC api. H2 is ultra fast and supports encryption. For security reasons, you can keep answer to your encoded database elsewhere (on some auth server?). And also you most likely will not have the ability to find something faster then pure JDBC.

To be sure with Matthew that you just cannot avoid the user from arriving at the into it. Additionally you allow it to be pretty easy if you work with a typical DB engine. You'll virtually be restricted to encrypting the information after which decrypting it into memory to ensure that you are able to query it.

SQLite is a great embedded database, but does poorly with concurrency. HSQL, Derby or other things should work pretty much if you're able to ensure that it stays in memory.