11–20 of 44 posts
How does this perform compared to a “native” graph database like Neo4J?
Why not add that functionality directly to SQLite via stored procs* https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Managem... * https://github.com/wolfch/sqlite-3.7.3.p1
How does this perform compared to a “native” graph database like Neo4J?
I would benchmark the tasks "traversal", "aggregation" and "shortest past" for a 10k to 10M node graph. Anything under 10k would be good enough with most techs and over 10M need to consider more tasks (writes, backup, the precise fields queried can become their particular problems at larger scale).
The Github link implements "traversal "in Python instead of pure SQLite. I suspect it will be around x10 slower than it could be with the same tech stack, because it queries once per node from Python to SQLite. Shortest path is not implemented and would be too slow to be useful in an interactive environment. "Aggregation" is also not implemented, but it would perform admirably, because SQL is good at that.
Traditional relational OLTP databases such as Postgres are already faster than dedicated graph databases for certain graph related tasks, according to this benchmark: https://www.arangodb.com/2018/02/nosql-performance-benchmark...
How does this perform compared to a “native” graph database like Neo4J?
It depends on how the graph is stored in the database. In this project the nodes ids are TEXT so it will likely not scale very well. I know because I use a similar implementation with GUID as string in Sqlite in a project since a couple of years and while it works fine for the graph I have (<1 million nodes, few edges per nodes) it won’t perform too well past that.
How does this perform compared to a “native” graph database like Neo4J?
Neo4j has failed queries I have written, with "out of memory" errors. I have never, ever, ever gotten that from SQLite.
I wonder if there are ways, in SQLite, to build indices for s,p,o/s,p/p,o/ and maybe more subtle ones... That would be uber nice, given the fact that most graph databases have their own indexing strategies, and you cannot craft your own.
How does this perform compared to a “native” graph database like Neo4J?
It really depends on what you want to do with it. I would benchmark the tasks "traversal", "aggregation" and "shortest past" for a 10k to 10M node graph. Anything under 10k would be good enough with most techs and over 10M need to consider more tasks (writes, backup, the precise fields queried can become their particular problems at larger scale). The Github link implements "traversal "in Python instead of pure SQLit…
shortest path typo, right?
Earlier quoted context omitted.
It really depends on what you want to do with it. I would benchmark the tasks "traversal", "aggregation" and "shortest past" for a 10k to 10M node graph. Anything under 10k would be good enough with most techs and over 10M need to consider more tasks (writes, backup, the precise fields queried can become their particular problems at larger scale). The Github link implements "traversal "in Python instead of pure SQLit…
> "shortest past" shortest path typo, right?