> The only requirement is that if F is the number of unreachable nodes you wish to be able to tolerate, then your minimum cluster size is 2*F + 1.
> Currently no other data store that I'm aware of offers this flexibility.<p>It isn't true. There're plenty of storages with same strong consistency model (tolerates F failures of 2F+1 nodes), among them are Cassandra with lightweight transactions, Riak with consistent buckets, CockroachDB and ZooKeeper.<p>> However, GoshawkDB has a radically different architecture to most databases and its object-store design means that contention on objects can be dramatically reduced, allowing the performance impact of strong-serializability to be minimised.<p>Can you please describe the algorithm that you use for implementing distributed transactions?<p>> just three network delays occur (and one fsync) before the outcome of the transaction is known to that node<p>3 round trips for per transaction is the result which is very similar to the Yabandeh-style transaction, see the Cockroach's blog for details - <a href="http://www.cockroachlabs.com/blog/how-cockroachdb-distributes-atomic-transactions/" rel="nofollow">http://www.cockroachlabs.com/blog/how-cockroachdb-distribute...</a><p>Do you use the same approach?
This is really cool! I guess the main competition in terms of similar purpose and guarantees is <a href="http://hyperdex.org/" rel="nofollow">http://hyperdex.org/</a>, although the add-on that enables transactions (quite critical...) is commercial.
<i>GoshawkDB is unique as it allows you to configure the tolerance to failure independently of the size of the GoshawkDB cluster. For example, you could have a cluster of 5 nodes and require that it continues to operate unless more than 2 nodes become unreachable. Or you could have a cluster of 20 nodes and require that it continues to operate unless more than 3 nodes become unreachable. The only requirement is that if F is the number of unreachable nodes you wish to be able to tolerate, then your minimum cluster size is 2</i>F + 1. You may of course choose to have a cluster size larger than this. Currently no other data store that I'm aware of offers this flexibility.<p>I fail to see the point of making your cluster unavailable before you've lost so many nodes that you no longer have a quorum. It seems odd to have a cluster that can handle e.g. 4 node failures, and take it offline after only 2. Why would anyone want a feature like that?
Why should I choose this over Ceph RADOS? [0][1]<p>0: Reliable Autonomic Distributed Object Store<p>1: <a href="http://docs.ceph.com/docs/master/rados/api/librados-intro/" rel="nofollow">http://docs.ceph.com/docs/master/rados/api/librados-intro/</a>
> The trade-off is that in the case of failure (node failure or network partitions), operations may block until the failures have been resolved.<p>Curious how this works at scale. For example if a node is down and N requests start blocking, is there an upper bound to N? What happens when this is reached? Does N map to a goroutine? A file descriptor? Is there timeouts?<p>Seems like possibly a node going down essentially means the entire show going down if requests are filling up and not being resolved, you would think there may be a tipping point in which other requests may not be able to be served as all resources are blocked.<p>Possibly there is just a sane timeout and these requests also just fail, leaving the client to know something is amiss?
Paxos from the ground-up to offer strong transactional guarantees, similar to CockroachDB: <a href="http://www.cockroachlabs.com/blog/" rel="nofollow">http://www.cockroachlabs.com/blog/</a>
CockroachDB is a KV store (that will be released with a SQL layer on top of it) whereas GoshawkDB is a Graph store. GoshawkDB puts data into client caches (much like Datomic) and even attempts transactions there.
For those interested in a bit more detail how GoshawkDB actually works, I've added a (slightly rushed) blog post on the topic, which covers transaction lifecycle. <a href="https://goshawkdb.io/blog.html#20151224" rel="nofollow">https://goshawkdb.io/blog.html#20151224</a>
On the site it is written that GoshawkDB doesn't support membership change. Since you system is based on single decree paxos then you can take Raft's joint consensus and apply to plain paxos. Probably it's the simplest and easiest to change membership in paxos cluster.
I don't see how it's possible to manage transactions fully client-side while adhering to the consistency model that's being claimed.<p>The best you'd be able to do seems like read-committed isolation.
Anyone bothered with author using term "object store", when in fact it's
no match for ZODB or Db4o and only stores serialized documents, more similar
to CouchDB or MongoDB?
Hey msackman,<p>Pretty cool looking stuff. Where'd you get the design for object/graph structure? It is what we are using for our database, <a href="http://gunDB.io/" rel="nofollow">http://gunDB.io/</a> . Although we take the opposite approach to CAP than you, and have no support for serializability (I don't think this belongs in the protocol but instead in the data, like git).<p>What's you're take on concurrency? How do you handle conflicts (I assume this is easy for you with a master)?<p>Would love to jump on a chat too, being DB guys. Shoot me an email mark@gunDB.io welcome arounds!