That's how OrientDB handles all that in v2.0+ - it automatically creates a new cluster for EACH distributed node/instance. Need a million devices, then scale up more OrientDB instances where node in the group has its own cluster as part of a base class (ie. Class Devices is contained in Devices_Node1, Devices_Node2, ...) As such, each of those clusters are managed by a single node at a time, which will move to another node if the primary node goes down. If you are on Node 2, and you try to access a record from the Devices class that sits on node 1, SQL selects and updates will be directed to node 1. And within that context, each new cluster/record will have it's own Rid counter, which is NOT distributed - it is always being generated by the node that currently owns and manages that particular cluster. If you're just tracking data from a million devices, you really don't need a global counter so it's fine. If you need to know every device that connects and disconnects in the precise order it happens, then you would, and that's where the solutions I mentioned would possibly come in.
BTW, I believe MongoDB is probably handling the counter in a similar way. It's not really distributed. It is handled by one machine, and if that instance goes down, the counter object's ownership will be redirected to another server in the group. Otherwise, how would any node know that its increment has not already been updated by another instance. -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
