News for hackers. Stuff that matters.
Re:Apache Age: A Graph Extension for PostgreSQL by jeiklo on Thursday March 04, 2021 @05:55PM (#26349679)
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.
Re:Apache Age: A Graph Extension for PostgreSQL by jnwatson on Thursday March 04, 2021 @08:51PM (#26351445)
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.

Re:Apache Age: A Graph Extension for PostgreSQL by kendallgclark on Thursday March 04, 2021 @10:04PM (#26352052)
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.
Re:Apache Age: A Graph Extension for PostgreSQL by rambojazz on Friday March 05, 2021 @05:02AM (#26355047)
What does it mean that "tables with multiple columns aren't strictly necessary"? Do you use tables with 1 column?
Re:Apache Age: A Graph Extension for PostgreSQL by nkozyra on Friday March 05, 2021 @08:52AM (#26356843)
"One sequential primary key field is all the columns anyone will ever need in a database"

- Bill Gates

Re:Apache Age: A Graph Extension for PostgreSQL by ethbr0 on Friday March 05, 2021 @12:49PM (#26359662)
128 bits are enough for enumerating everything.

- 2017

Re:Apache Age: A Graph Extension for PostgreSQL by d110af5ccf on Saturday March 06, 2021 @08:38PM (#26372310)
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.)

Re:Apache Age: A Graph Extension for PostgreSQL by ethbr0 on Sunday March 07, 2021 @01:01PM (#26378051)
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.

Re:Apache Age: A Graph Extension for PostgreSQL by d110af5ccf on Monday March 08, 2021 @12:40AM (#26382607)
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.

Re:Apache Age: A Graph Extension for PostgreSQL by d110af5ccf on Saturday March 06, 2021 @07:58PM (#26372080)
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.

Re:Apache Age: A Graph Extension for PostgreSQL by dragonwriter on Sunday March 07, 2021 @10:28PM (#26382052)
> 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.

Re:Apache Age: A Graph Extension for PostgreSQL by coolgeek on Friday March 05, 2021 @12:46PM (#26359630)
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
Re:Apache Age: A Graph Extension for PostgreSQL by jpfr on Friday March 05, 2021 @09:21AM (#26357135)
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...

Re:Apache Age: A Graph Extension for PostgreSQL by tannhaeuser on Friday March 05, 2021 @03:42AM (#26354440)
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.

Re:Apache Age: A Graph Extension for PostgreSQL by kendallgclark on Friday March 05, 2021 @08:29AM (#26356622)
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.
Re:Apache Age: A Graph Extension for PostgreSQL by rambojazz on Friday March 05, 2021 @04:58AM (#26355009)
Do you know Fuseki?
Re:Apache Age: A Graph Extension for PostgreSQL by kendallgclark on Friday March 05, 2021 @08:30AM (#26356628)
That’s a bit of a toy from the perspective of enterprise requirements. Good starter system if you adhere to open source religion.
Re:Apache Age: A Graph Extension for PostgreSQL by rambojazz on Sunday March 07, 2021 @10:21PM (#26382024)
What enterprise requirements does it lack?