3 ms·

You got downvoted, but I agree with you. Traditional RDBMS is inherently single-node and a pain to scale. The actual sad thing here is that there's no mature/re

You got downvoted, but I agree with you. Traditional RDBMS is inherently single-node and a pain to scale. The actual sad thing here is that there's no mature/reliable commodity (i.e. open source) distributed RDBMS for transaction processing yet.

yenwel 9y ago
VoltDB?
rhencke 9y ago
CockroachDB? I'll grant you it's still young, but it pretty solidly hits all your other checkboxes.
- elvinyung 9y ago
  IMO, it's very promising but still extremely immature. I still believe in Curt Monash's cardinal rule of RDBMS development: http://www.dbms2.com/2013/03/18/dbms-development-marklogic-hadoop/ http://www.dbms2.com/2013/03/18/dbms-development-marklogic-h...
jinqueeny 9y ago
I have to bring this up again: NewSQL. There are quite a few new choices out there, Google Spanner, Cockroachdb(https://github.com/cockroachdb/cockroach https://github.com/cockroachdb/cockroach), TiDB (https://github.com/pingcap/tidb https://github.com/pingcap/tidb). All of them are very easy to scale while maintaining the ACID transactions.
- elvinyung 9y ago
  I said open source and mature :) IMO really the best option for distributed OLTP RDBMS/NewSQL right now is basically either Citus or Vitess, only because they are built on the backs of extremely mature databases. It really feels like all other options are not mature enough (except maybe VoltDB).
  - jinqueeny 9y ago
    Could you please elaborate how you define "mature"?
    - elvinyung 9y ago
      IMO, in descending order of importance to me: * Dependability. I can be completely certain that standard usage of the database won't lose my data or leave it in a bad state, at the very least. * Community. There's an active IRC channel (or the like) where I can ask questions. When an error show up, I can Google it and easily find an applicable solution most of the time. * Performance. Not just with synthetic (i.e. TPC-C, TPC-H, YCSB, etc.) workloads, but proven to have reasonably satisfactory QPS in many/most real production settings. * Ecosystem. There's a good collection of first-party (and also ideally third-party) tools, constantly being improved. (Mere wire-compatibility with MySQL or Postgres might be good, but probably isn't enough, since 100% wire compatibility seems rare.)
      - jinqueeny 9y ago
        Thanks for sharing！These criteria seems quite practical. You are probably right. Time will tell.

yenwel 9y ago

VoltDB?

rhencke 9y ago

CockroachDB? I'll grant you it's still young, but it pretty solidly hits all your other checkboxes.

elvinyung 9y ago
IMO, it's very promising but still extremely immature. I still believe in Curt Monash's cardinal rule of RDBMS development: http://www.dbms2.com/2013/03/18/dbms-development-marklogic-hadoop/ http://www.dbms2.com/2013/03/18/dbms-development-marklogic-h...

jinqueeny 9y ago

I have to bring this up again: NewSQL. There are quite a few new choices out there, Google Spanner, Cockroachdb(https://github.com/cockroachdb/cockroach https://github.com/cockroachdb/cockroach), TiDB (https://github.com/pingcap/tidb https://github.com/pingcap/tidb). All of them are very easy to scale while maintaining the ACID transactions.

elvinyung 9y ago
I said open source and mature :) IMO really the best option for distributed OLTP RDBMS/NewSQL right now is basically either Citus or Vitess, only because they are built on the backs of extremely mature databases. It really feels like all other options are not mature enough (except maybe VoltDB).
- jinqueeny 9y ago
  Could you please elaborate how you define "mature"?
  - elvinyung 9y ago
    IMO, in descending order of importance to me: * Dependability. I can be completely certain that standard usage of the database won't lose my data or leave it in a bad state, at the very least. * Community. There's an active IRC channel (or the like) where I can ask questions. When an error show up, I can Google it and easily find an applicable solution most of the time. * Performance. Not just with synthetic (i.e. TPC-C, TPC-H, YCSB, etc.) workloads, but proven to have reasonably satisfactory QPS in many/most real production settings. * Ecosystem. There's a good collection of first-party (and also ideally third-party) tools, constantly being improved. (Mere wire-compatibility with MySQL or Postgres might be good, but probably isn't enough, since 100% wire compatibility seems rare.)
    - jinqueeny 9y ago
      Thanks for sharing！These criteria seems quite practical. You are probably right. Time will tell.