I know the current SQL backend for zay-es it not designed for distributed use (e.g. one database for storage, many systems accessing and updating components). How much effort would it be to change that?
The obvious thing is to change PersistentEntityIdGenerator to use transactions to generate a new EntityId, not sure about the rest.
I would use a different strategy for the id genreator.
One node based prefix, and then a local part based on incrementing counter or similar.
That way no locking is necessary, and no conflicts can happen within a specified entity count.
Yep, I agree with empire. You have 64 bits in the ID… use some of them for a server ID and you should be fine.
Though, I’d also argue that you should carefully consider your whole architecture at that point, too. Are you planning on having multiple databases or one database and multiple machines being the “systems”? The latter is more the ES way… and that’s where a server ID in the entity ID would come in handy.
So we’ve assumed that’s what you meant.
It will be one database for storage and many machines (+threads) computing the game logic, as most work can be done in parallel inside one “game tick”.
I guess the remaining features (like getting and setting components) work without problems if the data is accessed from different machines?
Yes, functionally. Though you need to keep in mind when designing your systems that queries are going to be much more expensive.
When I imagined a federated system as you described, I imagined also some distributed event system working under the covers to pass around the entity change events to dirty caches as needed.
The API, interfaces, and core of Zay-ES were designed for this… but there is no highly-scalable federated implementation yet and I suspect there will be some interesting tech to be explored there to make things really sing. But the key will be taking advantage of the under-the-covers event processing that happens to avoid having to do full queries all the time (which would be a more conventional ES approach… and you’d kind of have to implement a non-caching EntityData implementation in that case.)
Hi,
Interesting question… I think the problem is not really just about Zay-ES, and we can apply existed Java solution as Enteprise In memory data caching like HazelCast for example https://hazelcast.com/ . The interfaces in Zay-ES are pretty agnostic to what ever technology used to store and spread out data.
About distributed enviroment, You should take a look at Actor framework also, (it’s out of original question but you may interesting in it too)