Live data from Hacker News

MySQL is a Better NoSQL

engineering.wix.com

51–60 of 91 posts

Re: MySQL is a Better NoSQL

#51

Earlier quoted context omitted.

When and how did you evaluate PostgreSQL? Can you comment on PostgreSQL's horizontal scale?

There are benchmarks out there doing hundreds of thousands of queries per second with Pg. I've had it do about 200k myself. Do you need more?

Do I still get that query rate when I have hundreds of millions of rows in a table and database sizes in the Tens of TBs -> PBs.

Do you need more ? For pretty much all of the Fortune 500 who are doing Big Data Analytics. Yes.

There is a reason Hadoop and the related NoSQL databases are so popular today.

Re: MySQL is a Better NoSQL

#52
post #46

Earlier quoted context omitted.

Care to share an overview of what requirements swayed you?

For this project I wanted to be able to throw arbitrary JSON structures into a database, optionally index on specific fields if I wanted. Strong nice to have was for the database to intelligently read the JSON to prevent junk being dumped into a text field used as a json store field. I wanted to run purely from RAM, no hard disk, and a strong nice to have was to have an HTTP interface. Postgres doesn't have an HTTP i…

Sure. But you can do that with MySQL and MongoDB as well.

These support JSON data types, access via Nginx (with Lua) and caching data into RAM. Also for small data sets you can run data directorties on RAM disks.

Re: MySQL is a Better NoSQL

#53
post #41

Earlier quoted context omitted.

I cannot comment on its horizontal scaling. I can say however that Postgres, from what I understand, has nearly linear SMP vertical scaling up to 64 cores. There's an awful lot of headroom there. I read a long while back Jeff Atwood saying that StackOverflow ran on a single vertically scaled database server with MSSQL for a long time. If I needed to go beyond vertical then I'd maybe horizontally scale in a custom man…

Thank you for your response. I was asking the questions because when I was evaluating MySQL and PostgreSQL 3 years ago I ended up choosing MySQL due to its community and the rumor about difficulties in horizontal scaling of PostgreSQL even though I really liked PostgreSQL JSON support. I hear PostgreSQL is getting better at scaling horizontally although I do not know how good it is now.

Horizontal scaling comes with a who range of tradeoffs that you need to make and exactly how you horizontally scale I think has alot to do with how your application stores, reads and writes data.

Re: MySQL is a Better NoSQL

#54
As this title demonstrates, NoSQL is no longer a useful term. (It was useful for a period of time when SQL-based RDBMs systems were quite predominant, so it could be used as a gross differentiator).

Now the best way to think about it is that there are database platforms with varying features, one of which is support for SQL. When you evaluate which platform to use, you should have a list of business-derived criteria, such as SQL support, support for various relational integrity constructs (i.e. foreign keys), latency for typical queries (e.g. Hive), fault tolerance, ACID compliance, partitioning schemes, read or write optimization, etc. and act accordingly.

"NoSQL" used to be shorthand for a vague subset of database features that usually involved relaxing data protection in favor of multi-server scalability, but now it just muddies the waters, especially as many NoSQL platforms now support SQL or a subset thereof.

Re: MySQL is a Better NoSQL

#56
post #20

Earlier quoted context omitted.

Does anyone have a real, globally accepted NoSQL definition yet?

Well, it used to be databases that do not do SQL. But now, that Cassandra has SQL like query language, hadoop has SQL like hive and other NoSQLs implement semi-SQL interfaces, I believe a good definition is a database that is not one of 1. ACID 2. Strongly typed table schema.

Cassandra actually has a strongly typed table schema for the most part if you are predominately using CQL. Also Hive requires a schema for querying data off HDFS.

There really isn't any such thing as SQL/NoSQL any more.

Re: MySQL is a Better NoSQL

#57
What about ease of setup? I'd take the NoSql setup any day. If in need of a super light, super quick db that is for a "non-enterprise" application, it's tough to beat NoSql...

Re: MySQL is a Better NoSQL

#58

Earlier quoted context omitted.

There are benchmarks out there doing hundreds of thousands of queries per second with Pg. I've had it do about 200k myself. Do you need more?

Do I still get that query rate when I have hundreds of millions of rows in a table and database sizes in the Tens of TBs -> PBs. Do you need more ? For pretty much all of the Fortune 500 who are doing Big Data Analytics. Yes. There is a reason Hadoop and the related NoSQL databases are so popular today.

The question you need to ask and I'll state it more clearly: do YOU need more?

Those companies probably aren't you, and can afford to experiment with commercial and open source options that may or may not fit their scale.

People who reject PostgreSQL based on scaling are 99.9% of the time wrong about how much they will end up scaling.

Re: MySQL is a Better NoSQL

#59
This use case seems to be highly read oriented, which is fine, but really diminishes the value of distributed 'nosql' stores. The really hard thing to scale is massive writes. Cassandra's big differentiator, for instance, is it's ability to horizontally scale massively when it comes to writes. a million client writes per second, replicated over zones, type of performance.

Oh and by the way, 'vertical' scaling is kind of a silly concept. That just means, "i wasn't an idiot".

Re: MySQL is a Better NoSQL

#60

MySQL may work well for this small data set (200GB). Start working with 10s of TBs of data and you will start to understand why NoSQL stores were built.

Did you look at vitess [0] ? It handles sharding/replication of MySQL up to PBs of storage and 10s of thousands of connections. Also, it implements caching at the proxy level so you don't need to use memcached. If multiple requests for the same resource are sent to a vttablet (shard proxy) at the same time, only one is forwarded to the database and all of them receive the same result.

[0] http://youtu.be/midJ6b1LkA0

Post reply on HN