Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Evernote blog: WhySQL?

blog.evernote.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Evernote blog: WhySQL?

#71

Post by kfool »

opendomain wrote: post #18

There are other reasons to choose NoSQL For example, when Craigslist was using mySql and they had to change their schema, it took MONTHS to facilitate the change across all their slaves. You can also have a mixed strategy of using both RDBMS and NoSQL to achieve consistency while being able to be flexible to architecture changes. Lastly- have you looked at total overal cost? Setting up a large cluster with mySql will…

NoSQL does not support flexibility of schema change.

http://chronicdb.com/blogs/nosql_is_technologically_inferior....

Flexibility of schema definition and flexibility of schema change are two different things. Defining schemas only involves data. But changing schemas involves not just data, but code too.

Re: Evernote blog: WhySQL?

#72

Post by gizzlon »

geophile wrote: post #67
gizzlon wrote: post #66

Earlier quoted context omitted.

"Why would you give these up for scalability problems you won't have, with 99.999999% probability?" I'm not saying people shouldn't use RDBMS', but there are many reasons for using something else: - The new databases/stores have different features and use cases. Many include features RDBMS' do not have. - Having to use table/column's for everything can be quite unnatural and tiresome. - RDBMS' are battle-tested and t…

"The new databases/stores have different features and use cases. Many include features RDBMS' do not have." True. My view is that the tradeoff comes out overwhelmingly on the RDBMS side most of the time. "Having to use table/column's for everything can be quite unnatural and tiresome." Unnatural in the sense that it is different from the first language you learn, yes. What I find tiresome is low-level, record-at-a-ti…

"What I find tiresome is low-level, record-at-a-time programming when doing what could be expressed concisely as, say, a 5-way join with aggregation"

Again, that depends on what you are doing. Converting back and forth between rows/tables and, say, data stored in hashes, is tiresome. It's also unnatural when the data doesn't "fit" in the relational model. Of course it works, but writing all this banal sql is not fun.

"I really think you need to learn something about RDBMS fundamentals...."

Right.. I was talking about the software. Maybe "models" is the wrong word.

"But now take the next step and do an objective comparison between old and new"

Believe it's pretty objective already.

Re: Evernote blog: WhySQL?

#73

Post by gaius »

luigi wrote: post #26
shingen wrote: post #19

It's amazing how when you focus on proven (but supposedly boring or old) technology that just works, and works very well, you can devote a lot of other resources to the actual product and usability. Maybe it's the 30 year old in me showing, but I'm sticking with the 'it just works' crowd. Until some other approach provides a staggeringly overwhelming reason to switch. I find scaling up with MySQL to be ridiculously e…

It's amazing how when you use recent technology that has been designed and engineered from the ground up for the demands of modern web apps, you can devote a lot of other resources to the actual product and usability.

the demands of modern web apps

Hmm, let's see. What does a "modern web app" do? Well there is a screen with fields for users to enter something, and there is another screen where things that (other) users have previously entered formatted nicely for display. Behind the scenes, this data is exchanged between machines that do some other processing on it.

They were doing this in the '60s.

Re: Evernote blog: WhySQL?

#74

Post by gaius »

gizzlon wrote: post #66
geophile wrote: post #57

Earlier quoted context omitted.

Modern web apps are applications. Applications, over time, run into many problems that SQL database systems were designed to address: * The occasional join. * Complex queries. * Reporting. * Schema changes. * Transactions, with options for trading off strictness and performance. * Performance problems that are easily addressed using stored procedures. * Performance tuning with minimal code changes (e.g. adding an ind…

"Why would you give these up for scalability problems you won't have, with 99.999999% probability?" I'm not saying people shouldn't use RDBMS', but there are many reasons for using something else: - The new databases/stores have different features and use cases. Many include features RDBMS' do not have. - Having to use table/column's for everything can be quite unnatural and tiresome. - RDBMS' are battle-tested and t…

The funny thing is hierarchical databases were all the rage in the 1960s (IBM's IMS for example) and the world moved on to the RDBMS.

I chuckle to myself when kids who wouldn't know a "legacy" app if it jumped up and bit them on the nose, go through the same thought process over and over again.

Re: Evernote blog: WhySQL?

#75

Post by robinwarren »

karolist wrote: post #53
robinwarren wrote: post #21

Earlier quoted context omitted.

I must admit that I picked mongodb (+ node) for my latest project for fun. But I then discovered that being able to dump json straight into a datastore without having to create tables etc. first was a great benefit in quickly building something out. So something I did for fun turned out to be the simplest thing which worked. Only I didn't know that when I did it. I think developers who don't occasionally pick somethi…

I'd actually like to do that too but have a hard time wrapping my head around the notion of building a website with node + nosql alone. My understanding is that node is best for realtime chat-like apps.. Is your project web related might I ask?

Hi, sorry for the slow reply. As mentioned express is a good way to go for getting a website up with node.

Since you asked, my project is over here http://jobstractor.com if you want to take a look. My email is on the site so feel free to drop me a line if you have any questions. I'm planning on writing up my experience and a bit about how I've structured things so some questions might help me think through that.

Re: Evernote blog: WhySQL?

#76

Post by jeltz »

gizzlon wrote: post #33
huggyface wrote: post #29

Earlier quoted context omitted.

MySQL had some historic issues with schema changes -- adding a column to a table with a few million records could take hours. While it does have a lot of work to do -- it is restructuring every page of the database -- in competitive products such a change takes a minute fraction of the time (limited only by IO performance).

But altering a table would still block it? And possible even other tables as well? And take a long time? Only ever done this in MySQL, where you really can't alter big, live, tables. Well, facebook made an utility for it: http://www.facebook.com/notes/mysql-at-facebook/online-schem...

Most changes would still block, yes, but at least in PostgreSQL many changes will only block a short time (since they do not require a full table rewrite, only altering the table descirption) and in my experience rewriting a table is generally quick for a decent sized database (tables with a handful of millions of rows).

Re: Evernote blog: WhySQL?

#77

Post by jeltz »

matc wrote: post #68
jcromartie wrote: post #27

Earlier quoted context omitted.

I don't want to presume that I'm smarter than Craigslist's engineers, but why is this so hard? Schema changes should be captured in migrations, which are programs, and could be coordinated to run in parallel on thousands of machines in a moment with a shell script over SSH.

The fact that ALTER TABLE locks on most databases is not the primary reason changing a schema is hard. The primary reason is that a schema change breaks the application [1]. Migrations are programs, but your existing live application is also a program. Changing the schema breaks your live application to prepare for the new version of the application. [1] - http://chronicdb.com/blogs/change_is_not_the_enemy

This is true for NoSQL too. If you change the format of your documents you applications might need to be modified to support both the old and the new format at the same time.
Post reply on HN