Let's say I have an application that maintains relationships between objects - think of a parent-child relationship tree. The lineage of these objects are critical, so maintaining references from
Object A <-> Object B <-> Object C is very important. I cannot let the GC clean up any of these objects. Access to the data is very time sensitive and this tree can grow very, very large. In order to have immediate access to this data, I've obviously had to do it at the expense of memory and we all know what that inevitably leads to...
Before I explore solutions like Spark, Hadoop, databases, caching, or any other storage / data processing engines, I would like to better understand how Java is managing memory and if there are immediate solutions that might squeeze a little more juice out of my current design.
Lets just say each object represents a
Person. It contains details about that person such as first / middle / last name, date of birth, places they have visited over the last decade, make / model of current vehicle, etc... Basically a variety of
Boolean, data types. And then of course you have your
Children which are references to other
When I've decided a
Person object or any of its children have not been inquired about in X amount of time, I would like to compress these objects down to something much more manageable (in regards to memory) but still keeping context about the person and its relationships for speed.
So before I head down this path (requires quite a bit of refactoring), I am trying to think of the best possible solution - if at all possible.
Would something like taking all fields and storing them in a
Byte array with serialization / deserialization methods to compress & uncompress the data when they need to be read reduce any notable amount memory? I need a way to maintain the relationship of
Object B so that
Object A and
Object C know about one another while keeping the information of
Object B to an absolute minimum but still readily available.
Hopefully I've provided enough context to my question and wasn't too vague. If I have been, I'd be happy to elaborate.