Scaling to 100M: MySQL Is a Better NoSQL

Re:Scaling to 100M: MySQL Is a Better NoSQL by calpaterson on Tuesday May 24, 2016 @03:52PM (#11764946)

This article is pretty terrible but just in point of fact: it looks like they are using MySQL's InnoDB backend - which does support transactions and MVCC. If they're even talking about avoiding transactions for speed purposes (no matter how stupidly) they must be talking about Inno because in MyISAM BEGIN and COMMIT are no-ops.

[ Parent | on HN ]

Re:Scaling to 100M: MySQL Is a Better NoSQL by nerfhammer on Tuesday May 24, 2016 @06:07PM (#11765922)

The article says "Note that a transaction is using a DB-level lock that prevents concurrent writes—and sometimes reads—from the affected tables."

In innodb locks are row-level; myisam supports table-level locks though that's not and shouldn't be confused with a transaction; I don't know what a "database-level" lock is supposed to mean, are they really saying they're locking all tables to do a write? It doesn't sound like this author understands what a transaction is.

[ Parent | on HN ]

Re:Scaling to 100M: MySQL Is a Better NoSQL by justizin on Tuesday May 24, 2016 @06:42PM (#11766155)

> If they're even talking about avoiding transactions for speed purposes (no matter how stupidly)

As many have pointed out, so much criticism of this article ignores that it is comparing to other key-value stores which are not transactional. Many of what this would compete with are AP, with Consistency not guaranteed.

It really sounds like they should be talking about MySQL cluster, which is protocol compatible but a completely separate implementation and essentially a key-value store with RDBMS attributes atop it. It supports many-master mode like mongo and other distributed systems, which is fairly mandatory for replacing them. It's hard to argue you can replace HDFS with anything that's not distributed, and if you didn't, why wouldn't you just use .. the actual FS? The author may not really understand that HDFS is optimized for storing large-ish files.

[ Parent | on HN ]

Re:Scaling to 100M: MySQL Is a Better NoSQL by justinhj on Wednesday May 25, 2016 @03:55AM (#11768297)

There is nothing terrible or stupid about avoiding joins/transactions for speed. The technique of using blobs of data in MySQL rows in this article is perfectly valid and widespread at this point. As long as you understand the trade offs.

[ Parent | on HN ]

Re:Scaling to 100M: MySQL Is a Better NoSQL by calpaterson on Wednesday May 25, 2016 @06:30AM (#11768801)

In principle that is fine so long as you know what you're doing. In practice most people denormalising "for speed" aren't knowledgeable about the database implementations they are optimising for and that is very obviously the case here.

[ Parent | on HN ]