I think I can answer that question. The cluster:offset pair creates a direct address to the record in the database. This is what provides OrientDB an O(1) performance over O(log n) when indexes are used. With indexes you have to do a lookup. It is the lookup that causes the O(log n) performance. I think having the RID is cool but the problem is that the RID is not unique across databases. It is unique within the particular database.
The issue for me is that I want to propagate RID's but not in the form of a RID type but through a UUID instead as most (.NET) programs uses UUID (or GUID) and have a GUID type. I want to conceal RIDs inside of GUID's. This is why I need to know whether the new cluster size is going to be extended to 32-bits (4 bytes) or 64-bits (8 bytes). A "long" in Java is 64-bits. Based on Luigi posts it implies that cluster:offset is going to be 128bits. That means a RID will equate to the exact size of a GUID but I lose the extra bits that makes it possible to add addition info like a checksum to validate the RID. In my case I am hoping that they settle on extending the cluster size being extended to 32-bits. On Sunday, June 14, 2015 at 5:51:07 PM UTC+12, scott molinari wrote: > > Following Chris' line of logic, does the clusters going to long also mean > the 32K limit will also be extended? If yes, to what? 64K? And I am still > wondering about how OrientDB uses them to be more performant than an RDBMS. > Any enlightenment on that would be greatly appreciated. > > 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.
