I had the same concern with MongoDB and the ability to have a sequential id, as they too do not have an auto-incrementing id field like most RDBMSes have (which is one thing that makes them NOT easily scalable). They said, creating a "counter" field and using the "inc" command would do the trick. The call to do the increment is very fast. It is just something you have to remember to always do in the application, which sort of sucks.
I am actually surprised there is even a sequential number in the RID as such a sequence means centralization of some sort, which goes against the principle of a distributed system. I guess the cluster ID part of the RID is the solution for distribution, but also that causes your concern too. I am still trying to wrap my head around the logic of how to "cluster" larger sets of data. The example of users and counties only goes so far in my mind. Take an IoT scenario where you are ingesting tons of data from some 1000s or even millions of devices. Give each device a class and spread them over multiple databases? I don't think so. Give a range of devices a class? Maybe. Still, there might even be a better solution? If there is, I'd love to hear it. This was a very interesting conversation and I've learned a lot from it. Thanks Alex and sorry I didn't add too much to help with your concern. Scott -- --- 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.
