Sortledton: A Universal, Transactional Graph Data Structure [pdf]
1–10 of 17 posts
Re: Sortledton: A Universal, Transactional Graph Data Structure [pdf]
#2One thing I marvel at is despite the apparent usefulness of graph databases no major cloud provider offers a hosted graph db solution, with the possible exception of CosmoDB and marketplace Neo4j. It makes me wonder whether there is more operational complexity than value, or if your average developer/architect isn’t finding enough use cases that can’t be done with more traditional RDBMS.
Re: Sortledton: A Universal, Transactional Graph Data Structure [pdf]
#3it seems like if you do incremental query evaluation, then this problem, including the locking, just kinda vanishes (?)
Re: Sortledton: A Universal, Transactional Graph Data Structure [pdf]
#4One thing I marvel at is despite the apparent usefulness of graph databases no major cloud provider offers a hosted graph db solution, with the possible exception of CosmoDB and marketplace Neo4j. It makes me wonder whether there is more operational complexity than value, or if your average developer/architect isn’t finding enough use cases that can’t be done with more traditional RDBMS.
Does Amazon Neptune not count?
Re: Sortledton: A Universal, Transactional Graph Data Structure [pdf]
#5One thing I marvel at is despite the apparent usefulness of graph databases no major cloud provider offers a hosted graph db solution, with the possible exception of CosmoDB and marketplace Neo4j. It makes me wonder whether there is more operational complexity than value, or if your average developer/architect isn’t finding enough use cases that can’t be done with more traditional RDBMS.
Neptune, from AWS is one, right?
Re: Sortledton: A Universal, Transactional Graph Data Structure [pdf]
#6One thing I marvel at is despite the apparent usefulness of graph databases no major cloud provider offers a hosted graph db solution, with the possible exception of CosmoDB and marketplace Neo4j. It makes me wonder whether there is more operational complexity than value, or if your average developer/architect isn’t finding enough use cases that can’t be done with more traditional RDBMS.
AWS Neptune is really two different graph DBs, one a property graph model with Cypher queries and one a triple store with SPARQL queries.
Re: Sortledton: A Universal, Transactional Graph Data Structure [pdf]
#7One thing I marvel at is despite the apparent usefulness of graph databases no major cloud provider offers a hosted graph db solution, with the possible exception of CosmoDB and marketplace Neo4j. It makes me wonder whether there is more operational complexity than value, or if your average developer/architect isn’t finding enough use cases that can’t be done with more traditional RDBMS.
> more operational complexity than value
Graph databases are somewhat notoriously hard to optimize at scale.
Re: Sortledton: A Universal, Transactional Graph Data Structure [pdf]
#8One thing I marvel at is despite the apparent usefulness of graph databases no major cloud provider offers a hosted graph db solution, with the possible exception of CosmoDB and marketplace Neo4j. It makes me wonder whether there is more operational complexity than value, or if your average developer/architect isn’t finding enough use cases that can’t be done with more traditional RDBMS.
A lot of the Sr. system architects I’ve talked to complained how time consuming/complex (lack of a better word) it is while managing both relational and graph databases. Every CRUD operation leads to more dusting/cleaning your latent factors/connections in your graph databases.
There is ongoing research that the complexity arises due to the independent nature of your data across multiple databases, but the latent factors by definition are data-about-your-data. So the task is to make your latent factors dependent to their pertaining relational data, which enables easier house cleaning.
Re: Sortledton: A Universal, Transactional Graph Data Structure [pdf]
#9One thing I marvel at is despite the apparent usefulness of graph databases no major cloud provider offers a hosted graph db solution, with the possible exception of CosmoDB and marketplace Neo4j. It makes me wonder whether there is more operational complexity than value, or if your average developer/architect isn’t finding enough use cases that can’t be done with more traditional RDBMS.
> or if your average developer/architect isn’t finding enough use cases that can’t be done with more traditional RDBMS
Graph DBs are not magic. If you drill down into their query/execution plans it becomes very obvious that there isn't really a technical distinction between a traditional RDBMs and a Graph DB.
If you need graph traversal you can just as well use a table with edge-like indexing and recursive CTEs, and in the future with implementations of SQL/PGQ you can also do that in a "nice" Cypher-like syntax.
Re: Sortledton: A Universal, Transactional Graph Data Structure [pdf]
#10One thing I marvel at is despite the apparent usefulness of graph databases no major cloud provider offers a hosted graph db solution, with the possible exception of CosmoDB and marketplace Neo4j. It makes me wonder whether there is more operational complexity than value, or if your average developer/architect isn’t finding enough use cases that can’t be done with more traditional RDBMS.
One of the major uses of graph databases is to sell companies on the need to use graph databases.