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

61–70 of 77 posts

Re: Evernote blog: WhySQL?

#61

Post by untog »

huggyface wrote: post #56
untog wrote: post #54

Earlier quoted context omitted.

This seems incredible -- that products are chosen on such an irrelevant-in-the-long-term basis I don't think there is anything too incredible in that. If you want to throw together an idea quickly, get it out there and test response then use whatever technology gets the job done quickest. You can always change later. Why waste huge amounts of time setting up a technically perfect database for a product it turns out n…

The difference between getting competent with Postgresql versus MySQL was just a few hours. In the scale of a project such a difference dissolves into complete irrelevance, yet it was enough to sway many to use MySQL when it was severely deficient comparatively (though with its adoption it saw love that brought it up to if not beyond parity). The same is true with many technologies and approaches. Projects that consu…

The difference between getting competent with Postgresql versus MySQL was just a few hours.

Yes and no. There are a vastly more hosting options that provide MySQL vs Postgres. So it's not an issue of getting competent with the DB system, it's an issue of using an existing LAMP stack or having to roll your own.

Re: Evernote blog: WhySQL?

#62

Post by mapgrep »

4ad wrote: post #9

This article is very weak, they insist a lot on ACID, but those are completely orthogonal concepts from SQL. Most NoSQL products are ACID. Also, the example itself is very weak as bitdiffusion below pointed out.

Good point about SQL not having a lock on ACID. CouchDB in particular is very proud of its out-of-the-box ACID compliance.

People sometimes conflate the DB access approach (document vs relational) with the storage approach (transactional vs warehouse). This may be because the NoSQL poster child, MongoDB, at one point defaulted to a non ACID mode of operation. But you can have a relational DB that's not ACID (MySQL 3) and an object DB that is (Couch).

I was surprised so much of the original article focused on ACID as though it were the biggest selling point for an RDBMS. It seems like the biggest win (right now) is the sheer number of things a typical RDMBS does for you -- not just ACID but also data integrity (foreign key constraints), automatic index creation (mostly), and automated schema changes across many records (ALTER TABLE). The cost, of course, is the up-front effort of fitting your data and app to the relational model.

Re: Evernote blog: WhySQL?

#63

Post by ThaddeusQuay2 »

mitchellhislop wrote: post #48
driverdan wrote: post #43

Earlier quoted context omitted.

Why not have a database for each user? Evernote's data is partitioned perfectly for that. Notebooks and notes are accessible to one user or are public. There is no sharing notes between users.

There is sharing notes between users though - I have several shared notebooks, each holding shared notes.

Actually, his idea of a database for each user could still work, even though there is sharing of data between users. Take each database, and turn it into an executable object, which reads/writes its own data, and which communicates with other objects for sharing. It's like taking the actor model of computation, and orienting it for database use. I don't know of any working example of where this has been done, but I don't see why it wouldn't be feasible.

http://en.wikipedia.org/wiki/Actor_model

Re: Evernote blog: WhySQL?

#64

Post by grannyg00se »

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?

Node is very handy for high transaction, short transfer, high connection count applications like chat. That's because of the non blocking single thread architecture, low overhead connections, and little bloat (small footprint).

However, that doesn't mean it isn't well suited for building a website. You'd probably want to include some add-ons for that though (eg: express).

Note that even for realtime chat-like apps you'll probably need some kind of datastore and in fact that example sounds like a great use case for nosql as a datastore.

Re: Evernote blog: WhySQL?

#65

Post by karolist »

grannyg00se wrote: post #64
karolist wrote: post #53

Earlier quoted context omitted.

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?

Node is very handy for high transaction, short transfer, high connection count applications like chat. That's because of the non blocking single thread architecture, low overhead connections, and little bloat (small footprint). However, that doesn't mean it isn't well suited for building a website. You'd probably want to include some add-ons for that though (eg: express). Note that even for realtime chat-like apps yo…

Thank you for mentioning express, I'm now excited to use it in my next project!

Re: Evernote blog: WhySQL?

#66

Post by gizzlon »

geophile wrote: post #57
luigi wrote: post #26

Earlier quoted context omitted.

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.

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 their pros & cons are well known. But they might also be based on legacy models and truths that simply no longer holds.
  - At least for me, using & learning something new is a big motivation booster :)
Use whatever is right for the job. But one should at least have a general knowledge of whats out there: features, pros & cons etc..

Re: Evernote blog: WhySQL?

#67

Post by geophile »

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 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-time programming when doing what could be expressed concisely as, say, a 5-way join with aggregation.

"RDBMS' are battle-tested and their pros & cons are well known. But they might also be based on legacy models and truths that simply no longer holds."

I really think you need to learn something about RDBMS fundamentals. Set theory certainly "holds" to this day, and is certainly not legacy. The relational model is clumsy for some kinds of data ( (e.g. time series), but saying that the foundation is obsolete is just objectively false.

"At least for me, using & learning something new is a big motivation booster"

No argument there. But now take the next step and do an objective comparison between old and new. I have no problem with NoSQL systems. I even built one. But for nearly all applications, when you account for a wide set of requirements, (not just what is needed to get the MVP up and running), I think an RDBMS is the right tool.

Re: Evernote blog: WhySQL?

#68

Post by matc »

jcromartie wrote: post #27
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…

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

Re: Evernote blog: WhySQL?

#69

Post by matc »

zzzeek wrote: post #28
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…

Doing data migrations up front in a NoSQL system means you've changed the fields around in your document types, then you're done. Now 95% of your documents are wrong, missing those changes. Maybe you have linkages between different types of document (akin to a foreign key) - now a lot of those might be pointing to nothing. In this model, it's the application's job to anticipate and work around these inconsistencies.…

> The application can move straight to supporting the new structure and entirely forget that the old one existed.

Not always. Changing the schema can break an application, in particular when the database supports multiple applications.

> It's simple data and some dangling records aren't going to hurt anyone.

It depends on the application. In healthcare people literally die due to some dangling inconsistent records.

The problem in anticipating and working around these inconsistencies is that the workaround is added ad-hoc in code, rather than through a model defining the data change. You need a model http://chronicdb.com/preparing_schema_changes

Re: Evernote blog: WhySQL?

#70

Post by [deleted] »

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…

[deleted]
Post reply on HN