Live data from Hacker News

RedisGraph: a fast, queryable property graph database for Redis

oss.redislabs.com

1–10 of 34 posts

Re: RedisGraph: a fast, queryable property graph database for Redis

#3
I'm pretty uninformed on the subject, but I am interested to hear why an adjacency matrix is chosen over an adjacency list when it is sparse. My basic data structures and algorithms class would lead me to believe that an adjacency list would be better. Is this due to the nature of how the database is constructed?

Re: RedisGraph: a fast, queryable property graph database for Redis

#4
post #3

I'm pretty uninformed on the subject, but I am interested to hear why an adjacency matrix is chosen over an adjacency list when it is sparse. My basic data structures and algorithms class would lead me to believe that an adjacency list would be better. Is this due to the nature of how the database is constructed?

If I had to guess: redis is in general extremely predictable on both performance and memory use. A matrix is way more consistent in this.

Re: RedisGraph: a fast, queryable property graph database for Redis

#5
post #3

I'm pretty uninformed on the subject, but I am interested to hear why an adjacency matrix is chosen over an adjacency list when it is sparse. My basic data structures and algorithms class would lead me to believe that an adjacency list would be better. Is this due to the nature of how the database is constructed?

I found this [1] comment useful, from a thread last month. It has some background and links to the state of the art of GraphBLAS, which applies linear algebra to graphs. This [2] page has a good summary:

> ... “But if we can view graphs as linear algebra problems—which have been central to science and engineering applications in high performance computing for decades—then we can immediately apply everything that we’ve learned from parallel supercomputing over the last 35 years to graphs.”

[1] https://news.ycombinator.com/item?id=18099520

[2] https://crd.lbl.gov/news-and-publications/news/2017/graphbla...

Re: RedisGraph: a fast, queryable property graph database for Redis

#6
post #3

I'm pretty uninformed on the subject, but I am interested to hear why an adjacency matrix is chosen over an adjacency list when it is sparse. My basic data structures and algorithms class would lead me to believe that an adjacency list would be better. Is this due to the nature of how the database is constructed?

The underlying representation is a sparse adjacency matrix. The graph that it is representing is not necessarily sparse.

Re: RedisGraph: a fast, queryable property graph database for Redis

#8
post #2

Just a warning that this is one of the modules that's licensed under the controversial "Apache 2.0 with Commons Clause" license.

More information about the Commons Clause can be found here [1].

TL;DR: May I create, distribute, offer as SaaS, and/or “sell” my products using Commons Clause licensed components? Yes. Is it open source? No.

[1] https://commonsclause.com

Re: RedisGraph: a fast, queryable property graph database for Redis

#9
post #3

I'm pretty uninformed on the subject, but I am interested to hear why an adjacency matrix is chosen over an adjacency list when it is sparse. My basic data structures and algorithms class would lead me to believe that an adjacency list would be better. Is this due to the nature of how the database is constructed?

The main feature of the module is querying speed, which is achieved via matrix operations. You can't do the same with lists.

Re: RedisGraph: a fast, queryable property graph database for Redis

#10
post #2

Just a warning that this is one of the modules that's licensed under the controversial "Apache 2.0 with Commons Clause" license.

This motivated me to reread the commons clause again. I remain so disappointed in the naming and positioning of it. If you want to sell commercial modules that is totaly fine, but Apache 2 with commons doesn’t jump off the page as an unfree license (which prima facia it is). Should be called the ‘free for personal use’ email us for pricing clause instead.
Post reply on HN