News for hackers. Stuff that matters.
Re:Noms – A versioned, forkable, syncable database by aeharding on Saturday October 15, 2016 @08:48PM (#12716309)
If by "Git for data" you mean accumulate-only (or append-only), immutable data stores... There are already many existing solutions. It's always good to see alternatives, though!
Re:Noms – A versioned, forkable, syncable database by rspeer on Saturday October 15, 2016 @10:14PM (#12716505)
Can you point me at some? Because I've tried a few immutable data stores and been disappointed every time. Given about 10 GB of JSON structures, I keep finding things that can't outperform the boring combo of:

* Convert the versioned data to tab-separated values

* COPY it into Postgres every time

* Hope Postgres can act immutable enough even though it wasn't designed to be

The closest I've come to improving this situation was Kyoto Cabinet (unusable license) and rolling my own damn hashtable (it worked okay but adding new kinds of indexes was just unmaintainable, there's a reason databases should be made by experts).

Re:Noms – A versioned, forkable, syncable database by sjezewski on Sunday October 16, 2016 @12:39AM (#12716962)
(Disclaimer - I work at pachyderm)

http://pachyderm.io

Pachyderm is git for data. We work hard to make sure we can store data of different types (binary, text, json) efficiently. We also work hard to give you good mechanisms to read the data in a distributed way. I'd be curious how this suits your purposes.

Re:Noms – A versioned, forkable, syncable database by rspeer on Wednesday October 19, 2016 @07:54PM (#12748769)
Just started looking at Pachyderm.

While I can see how a git-based filesystem can help with some use cases, does it do any kind of indexing at all? I see that the FAQ recommends exporting the data from Pachyderm into PostgreSQL, which leaves me where I am now.

Re:Noms – A versioned, forkable, syncable database by ykler on Saturday October 15, 2016 @10:30PM (#12716558)
I was curious about Camlistore and Tahoe-LAFS at one point. I didn't investigate them very thoroughly, however. How do they compare?
Re:Noms – A versioned, forkable, syncable database by chubot on Saturday October 15, 2016 @09:05PM (#12716340)
Which ones are you thinking of?

The nice thing about git is that it doesn't really require much of the server. I run my own "git hosting" with linode, apt-get, and ssh.

Most of the solutions for immutable big data don't have that level of convenience, as far as I know. Anything which requires a lot of sysadmin and ops work will eventually become a commercial cloud service... git on the other hand is useful by itself, and good companies can obviously be built on top of it as well.

Re:Noms – A versioned, forkable, syncable database by TylerE on Saturday October 15, 2016 @10:00PM (#12716458)
Most binary formats don't diff well.
Re:Noms – A versioned, forkable, syncable database by rpedela on Saturday October 15, 2016 @09:34PM (#12716401)
No not really. CVS and git are basically the same thing but git is a lot better in many ways. I don't know if noms is really the git for data but those other tools are more like CVS in this analogy: clunky and slow.
Re:Noms – A versioned, forkable, syncable database by emmelaich on Saturday October 15, 2016 @09:53PM (#12716437)
They are so different it's hard to know what you mean by "basically the same thing"
Re:Noms – A versioned, forkable, syncable database by rpedela on Saturday October 15, 2016 @11:05PM (#12716666)
Yes there are significant differences in terms of feature, implementation, etc but they have the same goal: manage source code versions.
Re:Noms – A versioned, forkable, syncable database by emmelaich on Sunday October 16, 2016 @09:23PM (#12722106)
That's how Git is used but I think that by design, it is foremost a userlevel append-only content-addressable file system.

The difference between this and a version control system is a major part of why the UI is so awful.