Live data from Hacker News

Noms – A versioned, forkable, syncable database

github.com

101–107 of 107 posts

Re: Noms – A versioned, forkable, syncable database

#101
post #73
post #62

Earlier quoted context omitted.

Good devs use all three platforms. Or at least two.

Use, because they have to. This being said they usually develop more in one than the others. I have not met until now anyone who was equally proficient in developping software across all platforms/environments.

> Use, because they have to.

...in your very uninformed opinion...

Re: Noms – A versioned, forkable, syncable database

#102

Hi Hacker News. I'm one of the founders of the Noms project and Attic Labs, the company behind it. Happy to answer any questions. In the meantime, as long as I've got your attention, here's a few new stuffs we've been working on since last time Noms was discussed here in August: - A prototype query language, and a demo of how to create indexes in Noms: https://www.youtube.com/watch?v=fv6_T5yaWns - Support for merging…

Looks really interesting! This may sound like a stupid question, but do you have any publication I can cite by any chance?

[deleted]

Re: Noms – A versioned, forkable, syncable database

#103

Weird choice for the uri: http://localhost:8000::dbname Why not http://localhost:8000/dbname ?

Wow, I missed that. That violates the URI spec, assuming the author(s) were intending to use a URI. https://tools.ietf.org/html/rfc3986 (see "3.3. Path").

Right, it intentionally violates the URI spec by appending something to the end of it. The data structure they're storing has a natural pair-of-structures at its top level:

    data Database = InMemory | LevelDB Path | ViaHTTP URL

    newtype DataSet = DS Text
    newtype Hash = Hash Text 
    data Accessor = AccessDS DataSet | AccessValue (Either DataSet Hash) Path
    
    type DBAccessor = (Database, Accessor)
They elected to basically encode a DBAccessor above as a string which you can split on "::", with the URL above being stored on the left in the case of the ViaHTTP databases.

Re: Noms – A versioned, forkable, syncable database

#104
post #2

Very interesting, I think we need a git for data. What is the performance of diffs and merges? What data size does it become too slow?

I definitely agree here. As a data scientist, sometimes it seems like we are in the wild west as far as reproducibility and versioning of our analyses.

This seems like an interesting project that tackles some of the data versioning stuff. However, I believe that, at least in data science, we need data versioning closely tied to the analyses themselves for complete reproducibility.

That is, we need the versioning tied to the inputs/outputs of data pipeline stages, such that we can reproduce pipeline runs at any time and incrementally improve and run pipelines based on diffs in data.

As mentioned elsewhere in the comments, Pachyderm (http://pachyderm.io/) does exactly this. Working both as git for data, but also enabling data pipelining and analyses with the data versioning.

Re: Noms – A versioned, forkable, syncable database

#105

I really like this, I've always thought that git needed to support diff modes different from textline-based because even if this is fit for most programming languages what you really what is to see differences between ASTs (take into account those absurd change counts when just changing the indentation or imagine a normal diff of LISP source). Maybe there's some way of replacing git with noms to get there(even if it…

For what it is worth, in my experiments most ASTs (the rare exception being something like Roslyn's C#/VB ASTs) don't do well in "degenerate states" such as a partially finished files. (A good source control system should let you commit unfinished work.) I did have great success using a syntax highlighting tokenizers. I was able to create really nice-looking character-based diffs that were relatively semantic, quite quickly. I've not tried to use that as the basis diffs for something like git, though I've suggested trying it before.

Python code, if interested: https://github.com/WorldMaker/tokdiff

Re: Noms – A versioned, forkable, syncable database

#106

Earlier quoted context omitted.

Wow, I missed that. That violates the URI spec, assuming the author(s) were intending to use a URI. https://tools.ietf.org/html/rfc3986 (see "3.3. Path").

Right, it intentionally violates the URI spec by appending something to the end of it. The data structure they're storing has a natural pair-of-structures at its top level: data Database = InMemory | LevelDB Path | ViaHTTP URL newtype DataSet = DS Text newtype Hash = Hash Text data Accessor = AccessDS DataSet | AccessValue (Either DataSet Hash) Path type DBAccessor = (Database, Accessor) They elected to basically enc…

The string wasn't originally intended to be a URI, but I've been subsequently convinced that it would be useful for it to be one. We'll change it eventually.

Re: Noms – A versioned, forkable, syncable database

#107
post #14

Earlier quoted context omitted.

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 situ…

(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.

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.

Post reply on HN