5 ms·
There is so much wrong with this post I don’t know where to start Old school sql replication is awful. It’s awful in Postgres (single threaded replay? A single
by jjirsa 9y ago
There is so much wrong with this post I don’t know where to start
Old school sql replication is awful. It’s awful in Postgres (single threaded replay? A single vacuum can make your slaves fall behind). It’s awful in MySQL (go ahead and tell me how you do dual master without rewriting your app).
People use nosql not because it’s eady or flawless, but because doing it with sql is an order of magnitude harder.
Go ahead and describe resharding a sql DB as your company grows 100x
Or how you’ll handle a dc failover and fail back
Or how you’ll shrink your resources after the holidays - without downtime.
These are trivial with Cassandra and god damn near impossible for most MySQL users.
More reliable? Your “big iron” is still a single point of failure. If not a single cpu, a raid card or a top of rack switch or a DC in a hurricane zone.
- elvinyung 9y agoYou 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 agoVoltDB?
- rhencke 9y agoCockroachDB? I'll grant you it's still young, but it pretty solidly hits all your other checkboxes.
- elvinyung 9y agoIMO, 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 agoI 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 agoI 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 agoCould you please elaborate how you define "mature"?
- elvinyung 9y agoIMO, 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 agoThanks for sharing！These criteria seems quite practical. You are probably right. Time will tell.
- 6nf 9y ago> damn near impossible for most MySQL users. MySQL? Nobody, and I mean NOBOBY is saying you should use MySQL. All of the things you mention is trivial using a decent SQL solution like PostgreSQL.
- jjirsa 9y agoExcept the person to whom I replied said to use traditional SQL databases: > Traditional SQL databases end up being many times simpler in practice, and because of their inherent scaling limitations, much easier to manage. And most importantly: their implementations aren't buggy.
- 6nf 9y agoThey mean traditional SQL databases like PostgreSQL, SQL Server, DB2, Oracle etc. Not MySQL. MySQL has almost none of the important features of a real SQL database management system. Nobody should be using MySQL for anything.
- jjirsa 9y agoQuick, tell YouTube and Facebook they’ve been doing it wrong all along
- 6nf 9y agoThey are NOT using stock-standard MySQL and haven't done so for many years. If you are big enough to make your own programming languages the normal rules do not apply. And if you ask the Youtube team for a recommendation for your project, they will not point you to MySQL.
- deleted 9y ago[deleted]
- jaequery 9y agoi haven't touched mysql in years but quite frankly, 99% of websites out there (blog/cms) will run fairly fine on a Mysql database. as for the other 1%, they would be big enough to pick the right db of their choice as the time comes. so there is no need to tell everyone you should be using this or that. this is kind of like telling everyone that they should ALL be using emacs, when vim/nano is still sufficient for the job.
- stephenr 9y agoGalera + HAProxy or ProxySQL should give you a multi-master MySQL with no app rewrites required, no?
- jjirsa 9y agoPrimary key conflicts are still a thing. Especially problematic where you're either not using auto_incrementing PKs, and/or you try to switch writes from one master to the other and app has to be aware of the switch.
- stephenr 9y agoNot using auto incrementing keys is surely a rarity with MySQL projects. Even before galera was a thing regular MySQL replication could use auto_increment_(increment|offset) to make each server generate unique id's.
- jjirsa 9y agoThere exists a LOT of data models that don’t use auto incrementinf primary keys. Rarity or not, it’s a real use case and a real problem for master/master replication Also, even if you do use auto increment with offsets for each server, you’ll have to know how many servers you’ll eventually have, or waste offsets and eventually risk outrunning your data types
- stephenr 9y agoNon auto keys will already need some way to ensure uniqueness that will involve the application expecting conflicts. For those that do use auto inc, galera will manage the offset/increment value based on cluster size automatically.