I am trying to understand how one designs an object graph such that related objects will be placed in the correct shard.

I looked through the test code that came with Shards and am confused as to how objects get distributed.

Simplifying the object graph a lot, lets assume buildings have floors, floors have offices, and offices have furniture reflected in the following objects:

public class Building {
private Serializable buildingId;
private String name;
private List<Floor> floors = Lists.newArrayList();
}

public class Floor {
private Serializable floorId;
private int number;
private BigDecimal squareFeet;
private List<Office> offices = Lists.newArrayList();
}

public class Office {
private Serializable officeId;
private String label;
private Floor floor;
private List<Furniture> furniture = Lists.newArrayList();
}

public class Furniture {
private Serializable furnitureId;
private String description;
private Office office;
}

I also know that I might try to look up office id: XYZ in build 123 however I know I will never want to be able to look up a piece of furniture directly, I would only want to find out what furniture is in a given office.

Since everything is a child or descendant of a building I assume I want to shard based on building ID. If this is true are the following statements true?:

a) The ID of the floor and office would have to have the Buildings ID in it or at least have enough info in the ID to determine what the shard id of the building the floor and office belonged to? What about furniture?

b) I would need to write a ShardSelectionStrategy such that if the object passed in was a Building, it would assign it a shard (perhaps based on the modulo of the number of shards and building id?) and if something was a floor, office, or furniture, it would navigate the object map back to get the building ID and assign the object to the appropriate shard for the building they belong to.

c) In order for the ShardResolutionStrategy to not have to query every shard looking for an office or floor I assume I would have to make the building part of the compound key for the furniture, office, and floor? It would then do the mod operation on the building ID and determine what shard they lived in?

d) I assume if I wanted to get the list of 10 largest floors in a given building ordered by square feet I would get the ShardedSession for the shard that the building lived in and would then execute the Criteria as though it were standard hibernate since I know all the relevant floors are in that shard?

I guess my main question is, if I have an object graph that consists of a bunch of unique trees, how do I make sure all the items for a given tree are in one shard and then how is it recommended I determine which tree goes in which shard?

Are there any more elaborate examples than the documentation on the hibernate site and the google podcast?


Thanks,
Eric

Hibernate Shards will make sure that the whole tree is always saved to the same shard. If you somehow manage to associate parts of your tree with different shards, you will get an exception - please file a bug if you don't :)

a,b,c) Its probably best if every object ID can be resolved to specific shard (either through ShardResolutionStrategy, or ShardEncodingIdentifierGenerator), otherwise you will have to search on all shards for every load.
However, if you know you will always load only, for example, Building objects, then you need to do this only for Building objects, and as long as you navigate object graph to get to other objects instead of using Hibernate's get(), load() etc. you will be fine.

d) Yeah, that would work.

- Tomislav

Hi Tomislav,

Thanks for your answer. Three follow up questions.

a) What is considered best practice to make sure that all the related components of a particular object tree end up in the same shard? Using the example above, should I use the hilo generator to generate an ID on building and then make all the other items that are related to a building have a compound key where the compound key consists of the the building id and a surrogate ID generated with the hilo generator unique to that object? If this is correct, to implement it, I would assume in the ShardSelectionStrategy I would need to get the building id associated with the object and then determine what shard it is associated with and return that shard id. How do I find the ID for a given id? I guess the other approach would be to use a Long for both the building ID and the floor Id, however I am unsure how to generate IDs such that for a given building, all its floors end up in the same shard. Are there any best practices or is this already magically taken care of in the sharding system and I am just overly complicating thing?

b) Based on your comments, it sounds like if I only ever needed to access objects by navigating from a building object, then When I call Building.getFloors, and Building.setFloors, all those floors would get saved to the same shard as the building. Is this true even if I just use the ShardedTableHiLoGenerator to generate ids for each of the objects? If so, how does this work?

c) To do a criteria or a query based search where I know that all of the desired objects will live in the same shard (let's say I know the building and I am looking for the 5 biggest floors) then I would get the ShardedSession, then call getSessionForObject(Object obj) where object was something with a known shard, in this case a building?

Thanks for your help and this great product!
-Eric

a) When you fire save(), ShardSelectionStrategy will only be invoked for the object you fired save() on, and all saves that cascade will end up on the same shard. Also, if you try to save an object that is associated with object thats already persisted, the newly saved object should end up on the same shard.
So in above example, you could just use hilo generator for everything, and forget about compound keys. Just make sure that if you are saving floor, it is associated with appropriate building; the most likely way you could screw up is if you save building, save floor (they end up on separate shards), and only then create an association between them.

b) Yes. This works because Building would get loaded in Session (regular Hibernate Session) thats associated with one particular shard, so navigating object graph or adding stuff to it works as if you only had that one shard.

c) Yup.

-Tomislav