"An ArangoDB cluster chooses the traditional CP tradeoff, sacrificing availability in the presence of network partitions." Thanks for clarification. This seems to be backed up also by recent post: https://www.arangodb.com/2017/01/reaching-harnessing-consensus-arangodb/ I personally find CP combined with the huge model flexibility provided by ArangoDB interesting.
It would be very helpful to have this product orientation clearly stated in the home page and intro documentation, and backed-up by some test cases oriented to demonstrated CP support for example. Or in case also reference how to switch from AP to CP according to configuration (asynch replication or not), as stated in your first comment. ArangoDB home page currently states: "Production ready highly available Multi-Model NoSQL database" and "Deployment, scaling and high availability made simple". Although it is clear that ArangoDB performs well also in terms of availability, it would be worth making a statement about what is the architectural orientation of ArangoDB in term of CAP theorem, or anyhow an explanation about what you mean with availability, to help disambiguate. Thanks! On Tuesday, March 8, 2016 at 9:55:31 AM UTC+1, [email protected] wrote: > > Hello! > > 1. If you use https://github.com/arangodb/arangodb-dcos for deployment to > an Apache Mesos cluster, you can configure automatic asynchronous > replication in the ArangoDB cluster with automatic failover. If you use our > "old" deployment method described in the manual, there is no replication in > the cluster and thus no failover. > 2. An ArangoDB cluster chooses the traditional CP tradeoff, sacrificing > availability in the presence of network partitions. > 3. There is no fundamental limit capacity but your mileage will vary > depending on your use case. For example in > https://mesosphere.com/blog/2015/11/30/arangodb-benchmark-dcos/ we have > demonstrated very good scalability for single document operations. For > graph queries or complicated joins the situation will be more limited. > 4. In the above mentioned blog post we have demonstrated a throughput of > > 1000000 documents of size 1k each per second on 80 machines. Again for > single document operations there is no fundamental throughput limit. > > All this will dramatically improve with our upcoming 3.0 release, which is > due in 2 months. It will offer synchronous replication in the cluster, > automatic failover, easy up- and downscaling and a whole lot of other > improvements. > > Max > -- You received this message because you are subscribed to the Google Groups "ArangoDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
