Re: No to SQL? Anti-database movement gains steam
Date: Fri, 3 Jul 2009 08:54:08 +0100
Message-ID: <7765c8970907030054h21ce1d3cibc138be7d69577a5_at_mail.gmail.com>
On Thu, Jul 2, 2009 at 9:00 PM, Goulet, Richard <Richard.Goulet_at_parexel.com> wrote:
>
> I'm also rather puzzled by their comparison between their nosql alternatives and MySql's write capability. If you look on MySql's web site they plainly tell you that their not the worlds fastest database at writes, only reads. Kinda like comparing the abilities of a car and a motorcycle to back up a hill.
Well, the factors behind that appear to be that
1) the article is a rehash of PR with little analysis.
2) the I/O performance comparison comes from a slide where mysql's
writes to disk, which are slow on those figures, are compared to
acknowledgement of 'writes' to memory from an 'eventual consistency'
solution.
3) you always compare yourself to your competitors weakness. if doing
marketing, journalists should know that
>
> Short answer, we've all been there, done that before and are still smarting from the end results. It's simply a matter of people who want to forget history and repeat the mistakes of the past.
>
I don't know that it is that, certainly there are enough people who are ignorant or wilfully ignore the whole of relational theory - Curt Monash's quote is an excellent example of that - but there are swathe's of applications where the data storage does suit technologies like fast key/value lookup tables for example. If you look at some of the items that are referred to I probably wouldn't choose to use an RDBMS to store them
" Take Adobe's ConnectNow, which, even without a database, makes three copies of users' session data while they are online -- data that is mostly deleted after logoff"
" Design Goals:
Eventual consistency
–trade-off strong consistency in favor of high availability"
In each of these cases, you can see plenty of web applications that would benefit from this type of approach, if you don't need to store data at all, like the cookie equivalent, or you can cope with losing some of the data, as in the search example, and so on then a relational database would indeed be an expensive choice, and likely one that a relational approach would be overkill for.
-- Niall Litchfield Oracle DBA http://www.orawin.info -- http://www.freelists.org/webpage/oracle-lReceived on Fri Jul 03 2009 - 02:54:08 CDT