Re: No to SQL? Anti-database movement gains steam
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: Richard.Goulet@xxxxxxxxxxx
- Date: Fri, 3 Jul 2009 08:54:08 +0100
On Thu, Jul 2, 2009 at 9:00 PM, Goulet, Richard
<Richard.Goulet@xxxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
