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

I Can't Wait for NoSQL to Die

teddziuba.com

Post reply on HN
Print view View original

51–60 of 80 posts

Re: I Can't Wait for NoSQL to Die

#51

Post by rbanffy »

paulgb wrote: post #38
simonw wrote: post #17

Earlier quoted context omitted.

I dunno... I find the combination of the Django ORM and South (in particular the --auto flag for auto-creating migrations) is incredibly productive. With the ORM, I can conjure up a query that answers pretty much any question I might have of my data. I've experimented with MongoDB (and a bunch with Redis) and I find I'm much more likely to end up with a query that I can't resolve without having to do a bunch of extra…

I've found that relational ORMs force me to write convoluted and weird code for all but the simplest of joins. Maybe django's ORM is better; I've mostly used SQLAlchemy and a few others.

You know that you can use SQL with Django, if you have an insanely convoluted join.

Re: I Can't Wait for NoSQL to Die

#52

Post by rbanffy »

duncanwilcox wrote: post #24

NoSQL might be hype. Let's get specific. Cassandra eliminates the SQL database single point of failure and hard to replace masters via a lose sync, "eventually consistent" protocol. Is there some startup offering a web service that doesn't need that? And have you ever tried to deploy an SQL database capable of thousands of miles apart syncing? Eventually consistent is quite a different model than ACID. If you accept…

I wonder how long will it take for the simple "if you need ACID, go SQL, if you don't, you'll be fine with NoSQL" truth to sink in.

NoSQL databases have been in use since before I was born. Is anybody doing airline reservations on DB2?

Re: I Can't Wait for NoSQL to Die

#53

Post by rbanffy »

shin_lao wrote: post #3

The author makes some very valid points, but I will retort that RDBMS are overused as well. Sometimes you just want to store data on the disk in a safe and language agnostic way. You don't care about relations. In that case, many "NoSQL" engines are really great.

> but I will retort that RDBMS are overused as well.

Oh boy... How many times I had to explain my clients their sites would be just fine using ZODB instead of MySQL...

Never thought it that way. Hey! I am using NoSQL databases since 2001!

Actually, I wrote a lot of Dataflex 2 code, so make it 1987 or so.

Re: I Can't Wait for NoSQL to Die

#54

Post by mpk »

paulgb wrote: post #8
aheilbut wrote: post #5

Earlier quoted context omitted.

"Sometimes you just want to store data on the disk in a safe and language agnostic way." You mean, kind of like a file?

Well, since you need a safe way, you'll need a locking mechanism, too. And since it needs to be language agnostic, you can't just dump the internal representation of your object to disk, so you need some sort of serialization. At that point, it's probably easier to go with an already existent object or document store.

Ladies and gentlemen, we have a winner!

If you start using the filesystem as a datastore that requires concurrent access you open up a whole new can of worms. You need a locking mechanism - which you'll probably implement using (wrapped) native syscalls. Not only does that break cross-platform operation, you'll also have to work on and fix (but find first, of course) bugs in the locking implementation. As you spend more and more time on this and your app starts growing, you'll find yourself spending more and more time working with the limitations of the filesystem you're using (file size limits, directory size limits, access times for files in large directories). You can hack your way around all that but then you have to face other critical tasks. Say .. backup and restore procedures. Can you do partial backup/restore operations? No? Well, get ready to write code for that too. And you preferably want to be able to do those live. Remember those locking issues you solved when you started down this road to hell? Yeah, they're back with a vengeance now.

How about a full restore? Maybe you should have implemented a replay-able log system to get that full restore up to speed with the state of the db since the time of the last backup.

Or maybe this isn't exactly the right point at which to re-invent the wheel :)

Re: I Can't Wait for NoSQL to Die

#55

Post by pradocchia »

It occurs to me that MySQL started off as a thin SQL wrapper on a NoSQL database: here, have a SELECT and WHERE, but you'd best not JOIN, and forget about transactions or referential integrity.

Then, over time, they tacked on a few more relational features, but they had yet to solve the hard problems of relational databases.

Meanwhile, the people who were originally drawn to MySQL as a dumb-and-quick datastore got frustrated with this line of development and christened the NoSQL movement. It's not so much a departure from relational databases (they were never really there), but a return to MySQL basics, w/out the SQL.

Re: I Can't Wait for NoSQL to Die

#56

Post by derefr »

strlen wrote: post #29

AdWords implemented on top of MySQL? Perhaps the CRM portion of AdWords (i.e., where the advertisers submit their ads and publishers view their balances) is -- it's fairly easy to partition by functionality and doesn't have extremely tight latency bounds. This isn't where real time auctions (what really distinguishes AdWords from what came before) happen. You can be sure , however that the data used for real time ad…

> a highly customized data store (likely, a pure in memory one)

That's when we stop calling it a data store, and start calling it a data structure. Data stores are where data goes when it's not part of the working set. With that definition, it's perfectly sensible for AdWords to use MySQL as its data store.

Re: I Can't Wait for NoSQL to Die

#57

Post by derefr »

paulgb wrote: post #8
aheilbut wrote: post #5

Earlier quoted context omitted.

"Sometimes you just want to store data on the disk in a safe and language agnostic way." You mean, kind of like a file?

Well, since you need a safe way, you'll need a locking mechanism, too. And since it needs to be language agnostic, you can't just dump the internal representation of your object to disk, so you need some sort of serialization. At that point, it's probably easier to go with an already existent object or document store.

Perhaps developers wouldn't be going nearly as crazy for NoSQL if Apple's CoreData had a platform-agnostic FOSS equivalent.

Re: I Can't Wait for NoSQL to Die

#58

Post by derefr »

No one has ever explained this to me: why are we partitioning this space? Why can't a single database management system:

* have individual tables, indeces and views that are either relational or document-oriented, or graph- or object-based while we're at it, on a case-by-case basis,

* manage them all in a single, well-known distributed pool,

* and present a unified API to access all of them (e.g. a Structured Query Language of some sort)

* that allows tables of disjoint types to be joined in queries, with appropriate warnings when it creates non-optimized query plans?

In other words, why can't I say that my reports table should use the "relation" backend, while my messages table should use the "document" backend, and be done with it?

It's as if, when you went to a car dealership, they asked you whether you wanted to see the "cars with cigarette lighters" or "cars with automatic windows" section. Why can't my car do both?

Re: I Can't Wait for NoSQL to Die

#60

Post by vog »

derefr wrote: post #58

No one has ever explained this to me: why are we partitioning this space? Why can't a single database management system: * have individual tables, indeces and views that are either relational or document-oriented, or graph- or object-based while we're at it, on a case-by-case basis, * manage them all in a single, well-known distributed pool, * and present a unified API to access all of them (e.g. a Structured Query L…

have individual tables, indeces and views that are either relational or document-oriented, or graph- or object-based while we're at it, on a case-by-case basis

This is already the case. Nowadays, almost all relational databases (except, of course, MySQL) support XML columns. PostgreSQL supports them rudimentary, and DB2 and MSSQL have even special storage strategies and index structures for XML, i.e. for generic tree structures, data-oriented as well as document-oriented ones.

Also, abstract data types ("encapsulation", the base of OO) are implemented in these databases, too (except, of course, in MySQL), as well as other OO features such as table inheritation and some kinds of polymorphism.

Post reply on HN