Hacker News Reader

Comment by jeiklo | Hacker News Reader

Though i appreciate all the hard work people put into this and offer it so generously for free, it kind of saddens me to see yet another property graph database that supports some non-standardized (not really anyway) query language. I would really like to see a free and rdf based triple-store with good SPARQL support and that can be used for serious production workloads. But all the open source activity seems to be in the property-graph camp, with a new product every couple of month, while the high-quality triple stores are all quite pricy.

View on HN

Really, the market has spoken. In relational databases, tables with multiple columns aren't strictly necessary, but practically quite useful. In the same way, property graphs are more useful than triple stores, since common usage patterns want a collection of related properties a lot of the time.

Another way to put it is: it is straightforward to map a property graph to a triple store. In most cases, the property graph will have fewer nodes and edges and will operate faster and be easier to maintain.

Benchmarks consistently fail to show this perf advantage. Fair ones anyway. Which makes sense because property graphs and RDF are very similar and mostly differ in terms of syntax, i.e., stuff that good query planners and indexing schemes compile away.

What does it mean that "tables with multiple columns aren't strictly necessary"? Do you use tables with 1 column?

"One sequential primary key field is all the columns anyone will ever need in a database"

- Bill Gates

128 bits are enough for enumerating everything.

- 2017

2^128 is ~10^38. For frame of reference, there are ~10^22 atoms in a penny and ~10^50 atoms in the entire planet.

Alternatively, 585 years is "only" ~2^64 nanoseconds. 2^128 nanoseconds is on the order of 10^22 years, while the estimated current age of the universe comes in at a mere 10^10 years.

What sort of enumeration could you possibly do in practice on such a scale? (Allocation, on the other hand, is an entirely separate problem.)

I can't think of any. But I think the historical lesson is that what I (nay, people much smarter than me) can think of today is insufficient for the greater tomorrow.

The ridiculous historical quotes for computer counts, disk size, RAM were all predicated on people not computing differently. As it turns out, technology progressed, and people began doing entirely new, unexpected things with computing.

For the record, most (not all) of those quotes are taken somewhat out of context. Even in 1950, it was trivial to come up with examples of sets with more than (for example) 2^32 elements.

When it comes to address space allocation (ie IPv6) I agree; I'm skeptical that 128 bits will prove to be sufficient. But as far as simple enumeration goes, 2^128 is unimaginably large and I don't see how changes in computing could possibly affect that assessment.

An example. Partition a 2^128 address space evenly between 2^64 individual computers (it's difficult to imagine humanity ever possessing anywhere near this many devices). Each computer does nothing more than visit each value in its segment of the address space sequentially. No additional computations, nothing, just visits it. At 1 value per nanosecond (ie 1 GHz) this otherwise pointless exercise requires approximately 585 years to complete.

I believe that they are referring to the EAV data model, which is maximally flexible, in terms of schema modification. But performance, especially in terms of queries (but also in terms of DML) is atrocious

It means that everything a relational database is capable of (from CS theory) can be done with a single column of values per table. Note that each such table also has a "column" of primary keys; in other words, it's a simple K -> V mapping.

Also note that just because you can do something doesn't mean that it will be efficient, or that it will be enjoyable to work with.

> It means that everything a relational database is capable of (from CS theory) can be done with a single column of values per table. Note that each such table also has a "column" of primary keys

So, in other words, it's a two column table (“primary key” aren't some kind of virtual column, either in concrete databases or in relational theory.)

Calling a database with two columns one of which is the primary key a one-column table is...just wrong.

This uses openCypher for queries, which is about to become an ISO Standard. In the mid-term the query language will be on equal footing with SQL.

http://www.opencypher.org/articles/2019/09/12/SQL-and-now-GQ...

I don't find SPARQL terrible, and have used it in commercial projects.

But RDF can't claim the "standardization" argument in good faith when RDF/SemWeb overshadowed Datalog/Prolog (based on a true ISO and community standard) for such a long time. SemWeb, like XHTML, SOAP/WS-* and other W3C stuff, failed on the web to become an enterprise-y thing instead, W3C being a pay-as-you-go org.

I don’t understand this argument. Several overlapping specs max exist. ISO specs weren’t built to take advantage of Web specs. W3C specs were. Like it or not, the W3C didn’t do any disservice to the ISO or fight unfairly.

Do you know Fuseki?

That’s a bit of a toy from the perspective of enterprise requirements. Good starter system if you adhere to open source religion.

What enterprise requirements does it lack?

Reply on news.ycombinator.com