Scaling to 100M: MySQL Is a Better NoSQL • Hacker News Board

Re: Scaling to 100M: MySQL Is a Better NoSQL

#101

Post by justizin » Tue, May 24, 2016, 10:42 PM UTC

calpaterson wrote: post #66

koolba wrote: post #56

So much to disagree with here ... > Locks limit access to the table, so on a high throughput use case it may limit our performance. Then use a proper database that implements MVCC. > Do not use transactions, which introduce locks. Instead, use applicative transactions. Or just use a database that handle transactions more efficiently. > `site_id` varchar(50) NOT NULL, Why varchar(50)? UUIDs are 16-bytes. The best way…

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.

> 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.

Re: Scaling to 100M: MySQL Is a Better NoSQL

#102

Post by gshulegaard » Tue, May 24, 2016, 10:45 PM UTC

calpaterson wrote: post #70

gshulegaard wrote: post #63

Earlier quoted context omitted.

Just curious, but why use HStore instead of JSONB?

Presumably because HStore predates JSONB

While this is the conventional wisdom, I just wanted to make sure there wasn't some obscure benefit of HStore over JSONB that I wasn't aware of yet.

Re: Scaling to 100M: MySQL Is a Better NoSQL

#103

Post by treve » Tue, May 24, 2016, 10:51 PM UTC

Vendan wrote: post #88

tqwhite wrote: post #37

Earlier quoted context omitted.

They are the same thing. Both should include time as well as the server address, etc.

note there are like 5 versions of UUID, and only v1 and v2 include time and server address. It's also considered bad practice to use them, as it makes your UUID's guessable.

Depends entirely on what you're using them for.

Re: Scaling to 100M: MySQL Is a Better NoSQL

#104

Post by rspeer » Tue, May 24, 2016, 10:52 PM UTC

BinaryIdiot wrote: post #31

> Use client-generated unique keys. We use GUIDs. Minor note but wouldn't UUIDs be better since they're time based? Sure it's really unlikely to hit an already used GUID but an UUID makes it impossible. In fact is there a use case where it's better to use GUIDs over UUIDs? I couldn't think of one but I could be omitting something from my thinking so I'm curious. Edit: apparently GUID and UUID are the same thing and G…

UUIDs of all formats are universally unique, for all practical purposes.

Consider UUID4, the one with 122 random bits. The birthday paradox says that you would need about 2^61 UUIDs before you expect even one duplicate. If this concerns you, you might not recognize how big 2^61 is.

(edited because I was originally talking about 2^64, but there are 6 non-random bits in UUID4)

Re: Scaling to 100M: MySQL Is a Better NoSQL

#105

Post by stevesun21 » Tue, May 24, 2016, 11:02 PM UTC

System design 101: keep business logic into the layer above database layer rather than relying on specific db system to implement them. In this way to design an system, there shouldn't have any different between using MySQL of using NoSQL, their role is just storage engine. So, you don't need to follow the relational database practice, like for example, foreign key, constrains, normalization anymore.

Re: Scaling to 100M: MySQL Is a Better NoSQL

#106

Post by fleaflicker » Tue, May 24, 2016, 11:06 PM UTC

From 7 years ago, by Bret Taylor (who went on to become CTO at Facebook after acquisition):

How FriendFeed uses MySQL to store schema-less data https://backchannel.org/blog/friendfeed-schemaless-mysql

Edit to add the HN discussion at the time: https://news.ycombinator.com/item?id=496946

Re: Scaling to 100M: MySQL Is a Better NoSQL

#107

Post by beachy » Tue, May 24, 2016, 11:16 PM UTC

stevesun21 wrote: post #105

System design 101: keep business logic into the layer above database layer rather than relying on specific db system to implement them. In this way to design an system, there shouldn't have any different between using MySQL of using NoSQL, their role is just storage engine. So, you don't need to follow the relational database practice, like for example, foreign key, constrains, normalization anymore.

Trying to avoid using foreign key constraints in a relational database is not "system design 101", its an instant fail.

When I cast my eye over a table with foreign key constraints, I am 100% certain that every single row conforms to those constraints, and always will.

By contrast, when the same table does not have constraints, but instead relies on some business logic layer to enforce them, then I have to consider whether there might be corrupt rows put in there by:

- bad business logic code

- bad import scripts

- some contractor who used to work for us 5 years ago and briefly uses his php script to push up some data

Re: Scaling to 100M: MySQL Is a Better NoSQL

#108

Post by cmenge » Tue, May 24, 2016, 11:23 PM UTC

So MySQL is great if you use none of its features, but then its really hardly different from all the other databases. So it's not the implementation, but the very promises that databases make which can't be held, but if you know that, you are just fine. Great insight, and pretty much the definition of NoSQL...

Re: Scaling to 100M: MySQL Is a Better NoSQL

#109

Post by odonnellryan » Tue, May 24, 2016, 11:27 PM UTC

TylerE wrote: post #33

danudey wrote: post #26

Earlier quoted context omitted.

Based on my experience: MySQL is significantly easier to set up, and it's much easier to admin. PG still seems to do the thing where it assumes your system user is your database user unless you do a bunch of things, and the weird blurred lines between the operating system and the database can get really confusing at the start. On top of that, MySQL is well-documented and lots of people use it for lots of different th…

By 'a bunch of things' you mean uncomment like 2 lines in the config, right?

Well, he's right about it, kinda. I don't have problems with Postgres, but I do wish it had some defaults that made a bit more sense.

Re: Scaling to 100M: MySQL Is a Better NoSQL

#110

Post by matthewmacleod » Tue, May 24, 2016, 11:32 PM UTC

eulor wrote: post #49

matthewmacleod wrote: post #12

Earlier quoted context omitted.

That's true, and I don't doubt that many developers' opinion of MySQL is tainted by some of the issues in earlier versions. It's still difficult to see what newer versions offer over Postgres though - and Postgres has a lot of bonus features too (like the JSON storage types, which are sublime)

If you knew what newer versions of MySQL offered, you would be aware that it also supports JSON.

Sorry for not having comprehensive knowledge. I see that MySQL added support for a JSON datatype in the past year – I just knew it wasn't in 5.7 last time I looked, and it seems like an unusual feature to add in a 'patch' version.