Hi guys, i am new at dgraph and golang but i noticed that uids were converted to uint64, like here in mutation.go :
// Gets the uid corresponding
func ParseUid(xid string) (uint64, error
Is adding abstraction over string to allow comparing uids on the fly solve a scalability bottleneck in the future ?
a github for the possible fix : https://github.com/potatomasterrace/seemless_id (which is basically a dirty fix for hashing/comparing and generating ids of undertimed sizes to it scale with the number of items to keep track of)
Related post : Xid -> uid hashing function
All our UIDs are uint64s, because that’s a native data type supported by Go. UIDs correspond to the number of entities (nodes) in the graph, and we don’t expect our users to go over this limit (2^64 nodes in one Dgraph cluster). We made a design decision very early on around this, and it’s baked deep into Dgraph.
is the refractoring needed to add abstraction doable by a newcomer ?
an easier way would be to transform uids to uint64 arrays.
does this 64bit constraint cascade to other deep backed decision ?
am i right in assuming from your answer that the latency/memory/cpu/network tradeoffs don’t allow for flexiblity in uid sizes ?
is theoretically unlimited number of nodes per cluster worthwhile?
Sometimes it is worthwhile to see the non-shorthand version of a number. 2^64 is 18 quintillion 446 quadrillion 744 trillion 73 billion 709 million 551 thousand 616 nodes (18,446,744,073,709,551,616).
I think we can safely shelve this for the immediate future.