PageRank algorithm for graph databases

Thank you for your use case! I'll take a look at your thesis! :)

Sounds like EdgeDB [0] might be of interest to you

[0] https://www.edgedb.com

Not sqlite, but kuzu ( https://github.com/kuzudb/kuzu ) is an interesting project in this space. Fairly new, but already quite impressive IMHO.

SimpleGraph might be worth a look. I've found it useful. https://github.com/dpapathanasiou/simple-graph

Common graph databases are network-based for scaling purposes. You do have a database server then you talk to the server somehow for the queries. Sqlite is a single-file database. You do not have a server so you do not need an extra layer in database side.

Instead, Run the graph algorithms on a stringifed json stored as a text in sqlite. They will be running in some process in anyway.

looks like SQLite supports with recursive which allows some graph oriented queries: https://www.sqlite.org/lang_with.html the mandlebrot query looks interesting :D

I haven't used it on SQLite but I have done basic graph queries in postgres with `with recursive` some examples can be found here: https://www.alibabacloud.com/blog/postgresql-graph-search-pr...

It's nearly a decade old at this point and probably not optimal even for the time, so there may be better approaches, but here's a few basic algorithms on SQLite. PageRank is at the bottom.

https://github.com/robmccoll/graphdb-testing/blob/master/tes...

The graph is just an indexed edge list with auxiliary tables to support algorithms as needed.

Don't know about SQLite, https://github.com/apache/age seems very interesting, but it's just a tiny layer on top of Postgres :)

I was building something like this a few years ago - NetworkXum [1]. But now we just use a pure Graph implementation with NetworkX interface - UKV [2].

[1]: https://github.com/unum-cloud/networkxum [2]: https://github.com/unum-cloud/ukv

Cozo (cozodb.org) is a new embedded graph database that has many available storage backends, including SQLite.

It’s not a thin layer, though, if that’s what you’re looking for. Cozo has its own query system and uses a datalog-like query language.

I'm interested in this too. My hunch is that SQLite would be a particularly good fit for a whole bunch of queries thanks to this characteristic: https://www.sqlite.org/np1queryprob.html - "Many Small Queries Are Efficient In SQLite"

An algorithm that traverses a graph by performing hundreds of individual SELECT queries to follow a path should work much better against SQLite than against most other relational databases, due to the lack of network overhead in making each of those queries.

echoing _frkl: yes, kuzu aims to fill exactly this space. an easy to use dbms that gives you the ability to model your records as a graph, do common querying and transformations, and extractions all in a high-level graph-specific query language. we are very new and have quite a lot to go but it still implements many cypher clauses, so many things can still be done.

There are known link structure metrics besides PageRank that both scale better and are harder to game, though I'm not sure how their effectiveness in ranking compares to PageRank in the un-gamed case.

I used to work on Google web search indexing, almost 20 years ago, and (1) it has been public knowledge since around the time I left that PageRank was just one of a plethora of ranking signals going into the Learn To Rank page ranking ML and (2) I strongly suspect that PageRank itself has been replaced by a somewhat similar reverse link weighting algorithm.

I strongly suspect that something roughly PageRank-like is still there deep in the bowels of ranking, and due to the non-linear nature of ML, its importance probably varies greatly page to page.

PageRank was never as important as people thought it was.

Think of it this way: a search engine needs a relevance score that connects a query to a document. If the number of documents is vast (e.g. billions and billions) a search engine also benefits from a document-dependent quality score.

The first is more important than the second. You'd rather get a poor quality document that is relevant to the topic than a high quality document which isn't relevant.

It took several years before papers in the literature came out that found PageRank useful in search results, the key thing is that you need a real excess of documents. With millions of documents you are better off without it (being more effective at finding relevant documents improves performance), you really need 100 million + to reach the point where you have so many relevant documents for typical queries that filtering on quality doesn't get in the way of relevance.

PageRank can be thought of as simulating a Markov process where a user clicks a random link on a page most of the time but with some probability jumps to an entirely random page. PageRank is proportional to the probability that a user visits the page, or alternately how much traffic a page gets.

Google very quickly developed a few ways to sample this directly, such as (1) making Google analytics almost ubiquitous, (2) making Google ads almost ubiquitous, (3) analytics from the Chrome browser.

Google denies using the above for ranking, but they've been known to lie about Google's relevance factors before. Even a small sample from the above 3 could be used to calibrate models based on other info.

There is a repost at dev.to site - https://dev.to/memgraph/pagerank-algorithm-for-graph-databas...

Thank you, I'm glad you liked it! What other graph algorithms would you like to know more about?

The PageRank algorithm can be used for so much more than... well... page ranking :) hence the article :)