
Show HN: Gun database – 100k ops/sec in IE6 on 2GB Atom CPU - marknadal
https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2GB-Atom-CPU
======
reitzensteinm
"If you plan to compare Redis to something else, then it is important to
evaluate the functional and technical differences, and take them in account.

\- Redis is a server: all commands involve network or IPC round trips. It is
meaningless to compare it to embedded data stores such as SQLite, Berkeley DB,
Tokyo/Kyoto Cabinet, etc ... because the cost of most operations is primarily
in network/protocol management."

[https://redis.io/topics/benchmarks](https://redis.io/topics/benchmarks)

~~~
brudgers
It's not meaningless to compare X to Redis for a particular app in terms of
performance. The choice is an architectural decision and often architectural
decisions are made by non-architects based on defaults.

That's not to say that the comparison here is bad or good. But it is valid
given the diversity of use cases, the complexities of the technical
differences you mention, and the pressure that blogs and other media place to
adopt large scale solutions for small scale applications.

~~~
reitzensteinm
The old title claimed it was 50x faster than Redis with no analysis or
discussion of tradeoffs. You had to read the fine print to even see the
comparison was apples to oranges.

If the comparison were well handled, delving into the architecture tradeoffs,
it could be fascinating. But this was just a cheap ploy to get clicks. Now the
title has changed, my acidic tone is no longer justified.

~~~
brudgers
The former title was in place when I wrote my comment.

For what it's worth, according to the guidelines for 'Show HN' an acidic tone
is inappropriate. People expose themselves to significant psychological/social
risk when posting their own work online as their own work. Show HN is intended
to provide a safe productive space. In general, an acidic tone is a bit at
odds with HN's general guideline of civility.

~~~
frozenport

        expose themselves to significant psychological/social risk
    

Sounds too extreme. Criticism like "you are comparing apples to oranges",
isn't the same being a political dissident or losing a loved one.

------
mark242
Here's the important piece of information, from the conflict resolution page:

"Compare their string values with JSON.stringify, choosing the greater of the
two."

In other words -- don't ever use this database in production.

on edit: Here's why. CouchDB, which is also an AP database, puts conflict
resolution into the hands of the user, but each document contains a revision,
including information for the user to determine which is the correct revision.
Many times, it's just "the correct one is the most recent one", but that's
done in the user's code.

Making this kind of assumption (stringify and string comparison) for conflict
resolution is dangerous because there will be scenarios when you will lose
data no matter how many times you post to the database, guaranteed. Yes you
can't be consistent, but you need to tell the user that there's a data
conflict and have them deal with the logic.

~~~
marknadal
Lexical comparison is only used when 2 writes happen at the exact same time.

Yes, it is a very basic hybrid vector/lexical/timestamp CRDT. The naive-ness
of it is also its power, because it has strong eventually consistent
guarantees.

However, it is intended to be the base case. You can build your own custom
CRDTs on top to handle more specific business logic. For instance adding a
DAG, a ledger, a simple linked list, etc. gun's default algorithm is not a
silver bullet but it does "just work" out of the box for many web cases. See
more here: [https://github.com/amark/gun/wiki/Conflict-Resolution-
with-G...](https://github.com/amark/gun/wiki/Conflict-Resolution-with-Guns) .

Please especially read about our CAP tradeoffs (see the sidebar on the wiki).

Finally, it should be noted that because gun uses a graph data structure,
JSON.stringify only ever applies to atomic primitive values (not
complex/compound objects). So it is safe to apply (it is NOT safe to apply to
complex objects).

~~~
sagichmal
> Lexical comparison is only used when 2 writes happen at the exact same time.

But you take time from the system. Your writes may converge, but to an
nondeterministic state.

~~~
marknadal
No, because we then offset it with a vector relative to the machine, even the
great Kyle Kingsbury (Aphyr of Call Me Maybe Jepsen tests) tweeted about us
about this fact (that we assume/treat time as being loose/unsafe):
[https://twitter.com/aphyr/status/646302398575587332](https://twitter.com/aphyr/status/646302398575587332)
.

------
barakm
For context, this has been on Show HN before. This is the first, I believe:
[https://news.ycombinator.com/item?id=9076558](https://news.ycombinator.com/item?id=9076558)

....I'll let everyone draw their own conclusions.

------
blowski
That's an awfully big claim. Under what conditions does it do well? What does
it do badly? Where would I consider using this instead of Redis?

~~~
nordsieck
"Do work only once, then use centralized caching and cache updating to skip
ever doing work again."

It looks like their benchmarks are particularly friendly to their cache size.

------
naoru
Developing for IE6 by itself leads to PTSD.

------
yellowapple
All the CP v. AP and algorithmic discussion aside, I'd be really interested in
some actual concrete documentation on the actual peer-to-peer protocol
involved (preferably without having to resort to testing my cursory
understanding of Javascript by reading the source code). I'd be very
interested in trying my hand at some alternate implementations (this sort of
thing looks perfect for an Erlang/Elixir project), but if my only hope is to
reverse-engineer the reference implementation, I'd be far more inclined to
just stick to CouchDB or Barrel.

~~~
marknadal
Great comment!

The P2P protocol's base case is an ad-hoc mesh network (how the messaging
between peers works is explained here:
[https://github.com/amark/gun/wiki/Mesh-Network-Messaging-
Alg...](https://github.com/amark/gun/wiki/Mesh-Network-Messaging-Algorithm) ).

Initial connections are handled statelessly, both peers exchange blobs of the
requested/subscribed data to make sure they are in sync (not out of date / old
/ stale). On the wire, this is a GET command.

Then the connection becomes stateful, and only the changes/deltas/diff of data
are pushed over the network, thus allowing for realtime updates. Over ther
wire, this is a PUT command.

All data is represented as a graph (whether key/value, table, relational,
document, or graph itself).

And that is about it! Other than, of course, the AP aspects and the hybrid
vector/lexical/timestamp CRDT for conflict resolution. The architecture is
genuinely quite simple, intended to be the foundation for more complex data
structures to be built on top (other CRDTs, or DAGs, simple linked lists,
etc.).

There is a half baked "How to port GUN" guide here:
[https://github.com/amark/gun/wiki/porting-
gun](https://github.com/amark/gun/wiki/porting-gun) .

------
ddorian43
Honestly, I cringe everytime I read about gundb.

Db made in nodejs? Check.

No mention of multiprocess? Check.

No mention of persistence? Check.(lol @ s3 persistence)

All tests failing ? Check.

Optimizing if/else? Check.

Faster than redis? Check.

Store non-optimized json in disk(not sure but looks liek it)? Check.

I cringe at every page on their docs(like sharding). It just feels like the
templeos situation. Upvoted for discussion though.

~~~
yellowapple
"It just feels like the templeos situation."

Huh? TempleOS is explicitly not meant to be one's primary OS or even really
anything besides an educational environment. Gun appears to actually be trying
to target production use.

If anything, this is closer to a "MongoDB is web scale" situation.

~~~
ddorian43
I was talking about the "mental issues" angle. But he is charging 500/hour for
consultancy so he is doing something right. This thread has more juice:
[https://www.reddit.com/r/programming/comments/5k3367/50x_fas...](https://www.reddit.com/r/programming/comments/5k3367/50x_faster_than_redis_open_source_p2p_firebase/)

------
mariogintili
then I'd change the title - comes across as a direct comparison to redis.

Can we please let HN be free of click bait? :(

~~~
reitzensteinm
I suggest just flagging it, as I did, it'll be off the front page soon enough.

~~~
mariogintili
How can I do that? Rarely comment/moderate stuff in hacker news

~~~
ddorian43
You need more upvotes in your account probably. And then it will show up.

------
marknadal
Sorry all - celebrating Christmas early with family. I'll be back to respond
to any/all questions/concerns. Really appreciate everybody joining in and
giving feedback.

------
JshWright
> Use PTSD (Performance Testing Speed Development) to micro-optimize your code
> without getting lost in micro-optimizations. More on PTSD to come in the
> future.

I've lost friends to suicide secondary to PTSD... Maybe we don't overload that
particular initialism...

~~~
brudgers
Perhaps talking about PTSD without stigmatizing it is an alternative. PTSD is
as much an ordinary human health condition as a torn ACL. Just less diagnosed
and less treated.

~~~
JshWright
Absolutely. That doesn't mean it's something that we should make light of
though...

This past fall a friend and colleague suffering from PTSD took his own life
with a gun... You can see why I feel the joke is in poor taste.

~~~
ellyagg
We're all going to die. The inability to make light of death seems like a
refusal to acknowledge this fact. One perfectly valid perspective is that,
when facing the impermanence of everything, nothing is off the table for
poking fun at. Most of us have experienced tragedy and some of us can still
laugh at it.

That doesn't mean we shouldn't ever be serious, but I'm not convinced that our
collective sense of humor should be modulated down to the least tolerant and
most sensitive among us.

~~~
dang
You're right in general, of course, but you're talking to someone who just
told us he recently lost a loved one in a traumatic manner. Responding to a
specific pain with a general argument doesn't help, and being right makes it
worse.

