Fast Object Database for Java - with JPA/JDO support

TimeSeries and ObjectDB



I am using ObjectDB for storing TimeSeries (large ones) - when I get new points to add to the TimeSerie entity - I currently have to retrieve the whole timerserie since beginning of time, then add the new points, and then commit the whole timeserie again.

I looked at Update queries - but they seem to be handling simple tasks - like multiply one field of the entity by a constant.

More generally:

1- is ObjectDB suitable for large time series?

2/ If so - any example would be helpful - on how to organise the data.






ObjectDB can manage time series efficiently. The optimal way to organize the data depends on the specific application activity. Often the only way to know which structure is better (for a specific application) is to benchmark several options.

According to your question it seems that you store an entire time series in an entity object. This could be efficient it terms of space and retrieval speed but may be more expansive in updates. See a recent forum thread, post #5 regarding Embedded vs. Inverse Collections.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)


so if I understand correctly - it would be better to use conventional inverse (mapped by) collection.

I will get the following benefits:

1/ adding new elements to my timerserie won't require loading the whole TimeSerie.

2/ and it will still be fast to load a specific timeserie (same as before) - there is no overhead of having each TimeSerie point - in a different entity? The reason is because the parent entity (i.e. TimeSerie) will have all the references of all the individual point by time.

The downside is that the number of entities in a given DB will be much larger and requires the unlimited edition of ObjectDB (no 1_000_000 limit) right?

A more general question: if the database is using indexes efficiently - the inverse mapping would not be required as the database would have some index map already (not sure what the right terminology is) - so do i really need a parent object? Is it faster for queries?




Retrieval of data from many entity objects is obviously slower than retrieving one entity object. As noted above, it depends on your specific application (e.g. frequency of retrieval / updates), what is the best model, and often a benchmark is required in order to select the right model.

A parent object is not required, but it could be handy since it also distinguishes elements of one series from another.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Post Reply