[deleted]
GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
31–40 of 51 posts
Re: GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
#32Earlier quoted context omitted.
> Android phone, ~5M ops/sec. what are the "ops" in this case?
Sorry, I was trying to reply to both of you but I was not clear - I apologize. The ops are cached reads also, it was the same test across different devices. For people wanting to run them yourself, clone the repo and go to test/ptsd/ptsd.html - we need to make it easier in the future though.
Look not to sound harsh but since you're claiming the "80mm ops/sec" as a technical achievement "not possible with other databases" I found it to be fair to actually review the benchmark you linked. What you're benchmarking for the "read" is this:
benchmark(function(){
gun.val(ok);
});
It appears your benchmark is basically testing how fast you can do a simple javascript function call which has nothing to do with any database operation whatsoever? How is that useful?
The benchmark doesn't reflect the performance of your gun database more than it reflects the performance of _any javascript application_. The only thing that is being benchmarked here is the javascript interpreter. Seriously, this is like somebody claiming their database runs at 4 billions ops/sec because that is how many instructions the CPU can perform.
Given how much effort you (clearly) put into your marketing and the way you worded this as a "cached read" I think you probably know all of this though -- so here's a plea: Please don't pull these kinds of completely dishonest stunts (you even put the BS numbers in the title of this submission). You just make others in the javascript [database] space look bad by association. Cheating on benchmarks will not convince anybody but the most junior web developers.
source (hopefully I'm wrong ;) ): https://github.com/amark/gun/blob/master/test/ptsd/perf.js#L...
Re: GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
#33The title and the first line of the README
> GUN is a realtime, distributed, offline-first, graph database engine. Doing 15M+ ops/sec in just ~12KB gzipped.
But no mention of any guarantees provided by the system. What kind of transactions are supported? are writes consensus-based, best effort, eventual consistent?
The "GUN Survives a Primary Fault" raises more questions than answers. The "primary" appears to be the only server, and the clients are simply caching un-confirmed updates. Unless every client is a full copy of the database (which would seem prohibitive for the types of things this is aimed at?) there wasn't really any fault tolerance showed here.
Also, all clients resolved to the most recent update, the one didn't fail because the row had been updated between the last read. While that's OK for some designs, it just smells fishy. I shouldn't be able to trash someone else's update.
I feel like this is yet another datastore trying to call itself a database, but offering no guarentees of any kind that your data is safe.
Re: GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
#34Earlier quoted context omitted.
What are some appropriate real production use-cases for this? Particularly since you can't trust the user to tell you the 'real' state of a resource, the REST model is to send discrete state changes to resources and having an explicit endpoint to validate that the change is allowed (and logical).
We're currently seeing these use cases: - Autonomous IoT on mission critical hardware. (We rolled out a pilot with a government for this) - Distributed machine learning. ( https://github.com/cstefanache/cstefanache.github.io/blob/ma... ) - Games (built with React! https://github.com/PsychoLlama/connect-four ) and realtime GPS tracking ( https://youtu.be/7ALHtbC9aOM ). - And we're chatting with a bunch of companies do…
> - Autonomous IoT on mission critical hardware. (We rolled out a pilot with a government for this)
What mission critical system are you working with where it's OK to lose data?
Re: GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
#35That collision resolution algorithm looks like a doozie from a "malicious peer" point of view. Updates in the past are "recorded and discarded", updates in the future queue up. First, let's see if we can run our peers out of memory with a few (billion) quick future updates. Funny thing, gzip; it's so easy to compress highly repetitive patterns. Could also just try and spam the historical log too, could we fill the di…
This is a really great comment, thank you - hopefully I can address some of the points you brought up: - LRU/GC hasn't been added (planned for v0.8.x), so you are correct sending in a bunch of updates will crash the peer currently. The "out of bound" updates (for everybody else not sure what the parent is referencing, see this tech talk where I explain what is going on: http://gun.js.org/distributed/matters.html ) ar…
It would be good to see your claims backed up with data and benchmarks. I would love to see you run the Jepsen test suite against GUN also, so it's clear how it behaves in weird circumstances.
Re: GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
#36This looks really cool. I'm no database expert, but a decentralised graph database is an intriguing idea. Has it been tried before? (decentralised databases I mean, not graph databases)
I hope it was a sarcastic comment.
Re: GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
#37Earlier quoted context omitted.
We're currently seeing these use cases: - Autonomous IoT on mission critical hardware. (We rolled out a pilot with a government for this) - Distributed machine learning. ( https://github.com/cstefanache/cstefanache.github.io/blob/ma... ) - Games (built with React! https://github.com/PsychoLlama/connect-four ) and realtime GPS tracking ( https://youtu.be/7ALHtbC9aOM ). - And we're chatting with a bunch of companies do…
> - Autonomous IoT on mission critical hardware. (We rolled out a pilot with a government for this) > You should NOT use gun for any globally/strongly consistent data, like bank account balances and such.
Autonomous IoT data is exactly opposite of needing global consistency. I can't say what it is, but this system isn't even hooked up to the internet. It needs immediate local and autonomous decisions made, part of why they chose gun.
@jimktrains2 it is nearly impossible to lose data with gun because of its master-master replication even into the edge/peers. It is about as fault tolerant as you can get (check out the links to the tests I mention in the other comments).
I understand now how it might have sounded confusing, sorry about that! Mission critical systems often require HA, not master-slave. Master-slave is very important in other use cases.
Re: GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
#38Earlier quoted context omitted.
This is a really great comment, thank you - hopefully I can address some of the points you brought up: - LRU/GC hasn't been added (planned for v0.8.x), so you are correct sending in a bunch of updates will crash the peer currently. The "out of bound" updates (for everybody else not sure what the parent is referencing, see this tech talk where I explain what is going on: http://gun.js.org/distributed/matters.html ) ar…
It would be good to see your claims backed up with data and benchmarks. I would love to see you run the Jepsen test suite against GUN also, so it's clear how it behaves in weird circumstances.
Agreed! I know Kyle, and we're planning on having him review the system, but we're still polishing some things up on our end and he's backlogged. You'll definitely hear about it when it happens.
As for the other claims, most of these links are already scattered throughout the comments, but here they are again:
- Numbers on the performance benchmark: https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2... , also see https://youtu.be/BEqH-oZ4UXI , and run it yourself clone repo/test/ptsd/ptsd.html (we'll make this easier in the future)
- Tests, load/scaling, split brain, and other: see https://youtu.be/x_WqBuEA7s8 , https://youtu.be/-i-11T5ZI9o , https://youtu.be/-FN_J3etdvY , with https://github.com/gundb/panic-server you can run (let me know if you need any help getting it set up) https://github.com/amark/gun/blob/master/test/panic/load.js , https://github.com/amark/gun/blob/master/test/panic/holy-gra... .
Anything else I can provide?
Re: GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
#39For god's sake, man, run a linter on this thing. The mixing of spaces and tabs alone makes the code embarrassingly difficult to read. http://imgur.com/a/XlSQD
Fix your editor and set the tabspace to the correct value ? I'm guessing 2 spaces is the right value in this case.
Or maybe it's the developer who needs to fix his editor. Proper editor should convert tabs into spaces or vise versa and not create complications for everyone else.
Re: GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
#40Earlier quoted context omitted.
Sorry, I was trying to reply to both of you but I was not clear - I apologize. The ops are cached reads also, it was the same test across different devices. For people wanting to run them yourself, clone the repo and go to test/ptsd/ptsd.html - we need to make it easier in the future though.
Look not to sound harsh but since you're claiming the "80mm ops/sec" as a technical achievement "not possible with other databases" I found it to be fair to actually review the benchmark you linked. What you're benchmarking for the "read" is this: benchmark(function(){ gun.val(ok); }); Looking at what the gun.val call does it seems to be more or less an identitiy/noop function (that simply returns its input). It appe…
The nitty gritty details are on this readthesource.io podcast: https://youtu.be/70dn1oZQFCk (watch on 2X speed).
Each process does concurrency control and then has a centralized in-memory cache for the values (like what a lot of other in-memory databases do). So when `gun.val(cb)` is called, prototype context holds its value and is able to do an immediate read - without this, JS is so slow that every function call logarithmically decreases your performance (see the previously linked https://youtu.be/BEqH-oZ4UXI ).
That is the advantage of the realtime/push-based model, you can cache most data before it is even read. Even in memory databases, like Redis and others, do this so there is no BS here, but I appreciate you trying to call it out. Additionally, not all in-memory reads are equal - my previous implementation of gun could only do a thousand or so reads/sec despite being cached. And please compare against other in-memory javascript database benchmarks: https://github.com/techfort/LokiJS/wiki/Indexing-and-Query-P... (Joe's work is very good!)
I sincerely wish it was as easy as leaving it up to the JS interpreter ;) but I've unfortunately found JS to be very slow. :P
Hit me up with any other hard questions or if I missed anything. And please keep on trying hard to call out database vendors - I agree, it is extremely important to keep us open and honest. :) Cheers!