NeoDatis Benchmark on Android

After doing a lot of different testing and trying a lot of different settings I finally decided to do some testing. I had some heap size memory when doing the complete TestIndex test with all of the 10000 records, NeoDatis like to store all of entries in it's internal cache, so I settled with 1000 for now, until I can figure out a way to get around the memory related issues.

Here are the result table:

	Perst	SQLite	DB4O	BerkeleyDB	NeoDatis
Insert	1159	6892	4168	4619	25022
Search	599	9481	18261	3405	18325
Iterate	120	290	4392	2889	11126
Delete	1659	6315	7084	5565	10156

It should be noted that the NeoDatis team releases new versions often, so if you have some problem, it might be fixed in a new version.

NeoDatis on Android intro

I've been playing around with NeoDatis a little while now so I thought I'd write a little intro post on it before I did the testing.
NeoDatis ODB like a lot of the other database management system (DBMS)'s that I've tested lately can be used as both an an embedded database engine or in client/server mode.
Size
The makers of NeoDatis say that ODB runtime is less than 550k, witch would make it quite suitable for use on android. In the some time soon I'll do some heap usage tests to see how much heap the different DBMS's use while running, just need a tool to do it, worst case I'll write it myself.
Features
It supports ACID transactions to insure data integrity,  it also has a automatic transaction recovery that runs in the startup sequence that will commit the records in case of a "fatal" shutdown due to an unexpected event such as a hardware failure.

Storage
NeoDatis ODB uses a single file to store all it's data:

• The Meta-model
• The objects
• The indexes

NB: How ever you should be aware of a few things before starting using the NeoDatis.

The file that you are going to use for the database, must not be a new empty file. If you give NeoDatis a empty file, it will crash and give you an exception looking something like this:

Version=1.9.17 , Build=632, Date=03-10-2009-05-38-18, Thread=Thread-8
NeoDatisError:276:End Of File reached - position = 0 : Length = 0
StackTrace: org.neodatis.odb.impl.core.layers.layer3.buffer.MultiBufferedIO.manageBufferForNewPosition(MultiBufferedIO.java:151)
org.neodatis.odb.impl.core.layers.layer3.buffer.MultiBufferedIO.setCurrentReadPosition(MultiBufferedIO.java:271)
org.neodatis.odb.core.layers.layer3.engine.FileSystemInterface.setReadPosition(FileSystemInterface.java:202)
org.neodatis.odb.impl.core.layers.layer3.engine.ObjectReader.readEncryptionFlag(ObjectReader.java:180)
org.neodatis.odb.impl.core.layers.layer3.engine.ObjectReader.readDatabaseHeader(ObjectReader.java:244)
org.neodatis.odb.core.layers.layer3.engine.AbstractStorageEngine.init(AbstractStorageEngine.java:206)
org.neodatis.odb.core.layers.layer3.engine.AbstractStorageEngine.(AbstractStorageEngine.java:171)
org.neodatis.odb.impl.core.layers.layer3.engine.LocalStorageEngine.(LocalStorageEngine.java:18)
org.neodatis.odb.impl.DefaultCoreProvider.getClientStorageEngine(DefaultCoreProvider.java:140)
org.neodatis.odb.impl.main.LocalODB.(LocalODB.java:49)
org.neodatis.odb.impl.main.LocalODB.getInstance(LocalODB.java:35)
org.neodatis.odb.ODBFactory.open(ODBFactory.java:72)

I've submitted it as a bug, and got a reply pretty fast so It will probably be fixed or documented soon. 

Thread safety
NeoDatis ODB supports usage in a multi-threaded environment.

Import/Export
ODB lets you export & import all data to XML.

Refactoring

An interesting feature that I haven't seen before. You can add and remove fields without problems, it allso support additional refactoring through through it's Object Explorer(Extra app) where you can rename classes and fields.

Licence
ODB is distributed under the LGPL license.

So this was a quick introduction, at the moment I'm working on a TestIndex for it which should be done soon. If you want to know more about NeoDatis I suggest their homepage which has pretty good documentation.

JODB (Java Objects Database) for Android (3) with reduced TestIndex benchmark

While creating and running the TestIndex for JODB I've discovered a few things.

• Search operations are slow, and scale with the amount of records that is present in the database, so if it tok 2 seconds to get 10 distinct records with 100 records it will take 200 seconds with 10000, which are the number of records currently used in the TestIndex test. So large record-sets are not a good idea.
• It seems to use a very little amount of memory, but when searching goes as it goes, that doesn't really help that much when things take as much time as it does.
• As mentioned before it only supports primitives as indexes, so one really can't do a full TestIndex test.

As search operations was so costly I though I run a very reduced test with 100 records just to see how all of the other database management systems (DBMS).

As we see search operations are costly, my guess to why they are so costly is the way that JODB interacts with files on the system. I think that it do a lot of input/output (IO) operations when it does it's search operations. From what I gathered from looking in the source code it uses a FileChannel object to access its database files, which just reads or writes on a specific part of a file. So when doing a search operation it will read through the file until it finds the "part" (Record) that we are interested in. This would also explain why it use so little memory when it is running.

	Perst	SQLite	DB4O	BerkeleyDB	JODB
Insert	106	586	278	354	2183
Search	48	889	989	334	31021
Iterate	14	36	238	192	718
Delete	115	498	415	465	1011

JODB (Java Objects Database) for Android (2)

After my previous post on JODB and after using it for a while I discovered a couple of things about JODB. JODB is picky of what it allows you to use as an Index. It will only allow you to use primitives as an index, so if you try to use something that is not a primitive, such as a string:

db.configureIndex(Record.class, "strKey", true); won't work.

You will get an exception looking something like this:

com.mobixess.jodb.core.JodbIOException: can't find description for primitive java.lang.String
com.mobixess.jodb.util.PrimitiveJavaTypesUtil.getEnumeratedType(PrimitiveJavaTypesUtil.java:141)
com.mobixess.jodb.core.index.JODBIndexingAgent.(JODBIndexingAgent.java:73)
com.mobixess.jodb.core.index.JODBIndexingRootAgent.addAgent(JODBIndexingRootAgent.java:148)
com.mobixess.jodb.core.index.JODBIndexingRootAgent.enableIndex(JODBIndexingRootAgent.java:72)
com.mobixess.jodb.core.JODBSessionContainer.configureIndex(JODBSessionContainer.java:130)
com.mobixess.jodb.core.JODBSessionContainer.configureIndex(JODBSessionContainer.java:102)

Another thing you must watch out for is when you are deleting your object from the database, you should(must at least when they contain other stuff than primitives) deactivate them, before, deleting them.

Record r = set.next();
db.deactivate(r, 1);
db.delete(r);

If you do not do this you will get an exception from deep within the Apache harmoney classes, in mmap method.

java.io.IOException
org.apache.harmony.luni.platform.OSMemory.mmap(OSMemory.java:617)
org.apache.harmony.luni.platform.PlatformAddressFactory.allocMapPlatformAddressFactory.java:107)
org.apache.harmony.nio.internal.FileChannelImpl.mapImpl(FileChannelImpl.java:201)
org.apache.harmony.nio.internal.ReadWriteFileChannel.map(ReadWriteFileChannel.java:53)
org.apache.harmony.nio.internal.FileChannelImpl.transferFrom(FileChannelImpl.java:422)
com.mobixess.jodb.core.io.buffers.RandomAccessFileTransactionBuffer.transferFrom(RandomAccessFileTransactionBuffer.java:156)
com.mobixess.jodb.core.io.JODBIOBase.applyTransaction0(JODBIOBase.java:501)
com.mobixess.jodb.core.io.JODBIOBase.applyTransaction0(JODBIOBase.java:433)
com.mobixess.jodb.core.io.JODBIOBase.applyTransaction(JODBIOBase.java:336)
com.mobixess.jodb.core.JODBSessionContainer.commit(JODBSessionContainer.java:202
com.mobixess.jodb.core.JODBSessionContainer.commit(JODBSessionContainer.java:191)

So now I got a working TestIndex for JODB, so soon I'll hopefully have some results on the emulator and on the ADP1. The biggest problem I found with using JODB is the lack of documentation, so if you're considering using it you should be aware that it's not that much help to get.

TestIndex with DB4O(part one) on Android Emulator

When I did my last benchmark on the Android I got a question if I had tried out DB4O on Android, something I had not. So I had to try it out, to see how it was to use on the Android platform and compare it to SQLite and Perst. Using object oriented databases makes it alot easyer to develop applications as you can think "objects" all though out the development process, where you don't have to think about converting the results back into obejcts again. Using DB4O on android worked completely painless, and after some searching I found a compatible version of the TestIndex application for DB4O that I could integrate in the android. Below are the results for the emulator, I hope that i can test it on the ADP1 later today. How did I test ? I ran the test index application several times until I got some stable / reliable results.

Here is a graph of the results on the emulator. 

	Perst-Emulator	SQLite-Emulator	DB4O-Emulator
insert	11465	67420	36980
search	9601	90328	226624
iterate	6578	4504	39405
delete	18408	59998	71463

If we look at the results we see that the only thing that is really standing out is the search on the DB4O, I have no good explanation for this.