On Thu, Mar 10, 2016 at 7:01 PM, Ben Pfaff <[email protected]> wrote: > Database txn ACID consist trk HA OS C Py format > ------------- --- ---- ------- --- --- --- --- --- ------ > ActorDB yes ACID strong NO yes yes yes yes sql > Aerospike yes ACID strong NO yes yes yes yes db/KV > Cassandra NO -C-D tunable NO yes yes NO yes table > Cockroach DB yes ACID strong NO yes yes ? ? sql > Couchbase NO ???? ???? NO yes NO? yes yes JSON > CrateIO NO ???? EVNTUAL NO yes yes NO yes sql > etcd NO ACID strong yes? yes yes yes yes KV > Gigaspaces XAP yes ACID strong yes yes NO NO NO multi > HBase NO ACID strong NO yes yes NO yes table > Hyperdex yes ACID strong NO yes NO yes yes KV > Hypertable NO ???? ???? NO yes yes NO yes table > MariaDB yes ACID strong NO yes yes yes yes sql > MongoDB NO ACID strong ?? yes yes yes yes JSON > PostgreSQL yes ACID strong yes yes yes yes yes sql > RAMCloud yes ???? strong NO yes yes NO yes KV > Redis yes -C?D ???? NO yes yes yes yes KV > Riak NO ---D EVNTUAL NO yes yes yes yes KV > Scalaris yes ACI- strong NO yes yes NO yes KV > ScyllaDB NO -C-D tunable NO yes yes NO yes table > Voldemort NO ???? EVNTUAL NO yes yes NO yes KV > Zookeeper yes ACID strong yes yes yes yes yes KV > > OVSDB yes ACID strong yes NO yes yes yes table >
When talking about this in person last week, another alternative was raised: Database txn ACID consist trk HA OS C Py format ------------- --- ---- ------- --- --- --- --- --- ------ RethinkDB NO ???? strong yes yes yes yes yes json > Recommendation > ============== > > I'm intentionally not offering a recommendation, because I want to start > a discussion. > Here's my take, FWIW. The opening paragraph said: > OVN uses two databases, the "northbound" and "southbound" databases, > in a somewhat idiosyncratic manner. Each client of one of these > databases maintains an in-memory replica of the database (or some > subset of it), and the server sends it updates to this replica as they > are committed. Thus, at any given time, a client has a consistent > snapshot of the database, although it might be old if the database has > changed but the updates have not yet made it from the server to the > client. I've grown very attached to this model. I think it is one of the top strengths of OVN's architecture. It has a beautiful simplicity to it. It also seems to have really nice fault tolerance properties. It's a top priority for me to stick with the model that is serving us so well so far. ovsdb-server performance was always a huge unknown. I had no idea how well it was going to hold up. I thought it might completely fall apart with just 100 clients, much less thousands. The reality so far has been a *very* pleasant surprise. We're seeing tests of OVN simulating 1000-2000 hypervisors with ovsdb-server still not the bottleneck. There is also work in progress to continue to improve it ahead of demand. I'm feeling much more comfortable about this aspect at this point. Lack of HA is a critical feature gap. Ben Pfaff has volunteered to continue work on a RAFT implementation and integration with ovsdb-server. RAFT itself is relatively simple for its purpose and used in other modern distributed systems. This still seems like a bold undertaking not to be taken lightly. However, Ben is someone I trust and believe could make this a success. My preferred approach is to continue on the current path and build on the success we've had with OVSDB so far. We should take regular checkpoints and still remain willing to change course if needed as we continue to learn more. I'm just not sold on the need to switch at this juncture. Thanks, -- Russell Bryant _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
