Great content. Question though. How does partitioning work on a graph DB? Would'nt all data on a connected graph need to live on the same partition. If so how does a dataset of a company like face book with so many susers and so many relations scale without partitioning?
I try to explain it at the end there a bit in terms of dealing with locking on cross partition queries. Ideally, you can avoid it, but if you can't, basically you need to come up with your own partitioning heuristic. That's something that is subject to a lot of research, but of course in an ideal situation most queries will only have to go to just one node. Perhaps some form of node clustering could accomplish this decently.
6:28 isn't it O(logn) for finding MGK here? And not constant time complexity 8:28 also, how do we store addresses if they are on different databases? How do we know a particular address belong to which database?
There is a problem with your demonstration. Retrieval on a unique b-tree index (balanced tree) is O(1) (no more than 3 reads, independent of index size).
Well I suppose it's tailored for graph data, yeah? I'd think that unnecessarily storing data that could be well represented using a normal table via a graph has lots of overhead in terms of storing many edges.
Great explanation
Thank you for the gold content.
Great content. Question though. How does partitioning work on a graph DB? Would'nt all data on a connected graph need to live on the same partition. If so how does a dataset of a company like face book with so many susers and so many relations scale without partitioning?
I try to explain it at the end there a bit in terms of dealing with locking on cross partition queries. Ideally, you can avoid it, but if you can't, basically you need to come up with your own partitioning heuristic. That's something that is subject to a lot of research, but of course in an ideal situation most queries will only have to go to just one node. Perhaps some form of node clustering could accomplish this decently.
6:28 isn't it O(logn) for finding MGK here? And not constant time complexity
8:28 also, how do we store addresses if they are on different databases? How do we know a particular address belong to which database?
1) "index free adjacency"
2) you'd have to put some sort of value (ID or otherwise) indicating which node the row belongs on
Yo, even I am in Chicago Illinois.
Let's meet up bro
Would love to see the guy responsible for my employment ❤
Hey Ganesan! Would love to hear your story, wanna message me on LinkedIn?
@@jordanhasnolife5163 Yes, I do!
There is a problem with your demonstration. Retrieval on a unique b-tree index (balanced tree) is O(1) (no more than 3 reads, independent of index size).
You do still have to binary search the nodes of the b tree itself fwiw, but sure in reality the b tree is sized appropriately
Good overview. What about disandvantages?
Well I suppose it's tailored for graph data, yeah? I'd think that unnecessarily storing data that could be well represented using a normal table via a graph has lots of overhead in terms of storing many edges.
This, must be cons other than "it's newer and tools are less mature". Examples of how it's also worse would be great.
Can you do a vid on ScyllaDB plz?
From what I know it's just Cassandra written in c++