se this is not
>>> so much the case.
>>>
>>> In HBase, the sharding and distribution come for free out of the box.
>>> With a relational database you must jump through hoops and often end
>>> up implementing your own sharding/distributed hashing algori
It's
>> feasible to implement something like that on top of a distributed
>> relational database but again the complexity is enormous. With
>> HBase/Hadoop it's a built-in part of the system, a system which is
>> very intelligent at keeping logic close to data, et
e huge.
>>>
>>>
>>> In addition to all this, with HBase/Hadoop you get MapReduce. It's
>>> feasible to implement something like that on top of a distributed
>>> relational database but again the complexity is enormous. With
>>> HBase/Hadoop i
7;s nothing simpler than that. Distributing a relational
database is never simple.
I hope this starts to shed some light on what the differences are.
Jonathan Gray
Streamy Inc.
-Original Message-
From: Mork0075 [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 8:48 AM
To: core-u
Thanks a lot for all replies, this is really helpful.
As you describe it, its a problem of implementation. BigTable is
designed to scale, there are routines to shard the data, desitribute it
to the pool of connected servers. Could MySQL perhaps decide tomorrow to
implement something similar or
mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 8:48 AM
To: core-user@hadoop.apache.org; [EMAIL PROTECTED]
Subject: Re: Why is scaling HBase much simpler then scaling a relational db?
Thank you, but i still don't got it.
I've read tons of websites and papers, but there's
I'm no expert, but maybe I can explain it the way I see it, maybe it
will resonate with other newbies like me :) Sorry if it's long winded,
or boring for those who already know all this.
BigTable and Hadoop are inherently sharded and distributed. They are
architected to store the data in re
Thank you, but i still don't got it.
I've read tons of websites and papers, but there's no clear und founded
answer "why use BigTable instead of relational databases".
MySQL Cluster seams to offer the same scalabilty and level of
abstraction, whithout switching to a non relational pardigm. Lo
e.org
> Subject: Re: Why is scaling HBase much simpler then scaling a relational db?
>
> On Tue, Aug 19, 2008 at 9:44 AM, Mork0075 <[EMAIL PROTECTED]> wrote:
> > Can you please explain, why someone should use HBase for horizontal
> > scaling instead of a relational databa
On Tue, Aug 19, 2008 at 9:44 AM, Mork0075 <[EMAIL PROTECTED]> wrote:
> Can you please explain, why someone should use HBase for horizontal
> scaling instead of a relational database? One reason for me would be,
> that i don't have to implement the sharding logic myself. Are there other?
A slight t
Thanks, this was really informativ :)
Bigtable uses both. First it splits row ranges based on size. It also has the
ability to detect hot row ranges and will split a region if it becomes too hot.
This is tricky because you don't want to have a hot range split off and then
have it drop below t
ubject: Re: Why is scaling HBase much simpler then scaling a relational db?
>
> I've read some papers and tutorials this week and now got some conrete
> questions:
>
> (1) Sharding is also available in common relational systems. Often it is
> discribed that you nee
I've read some papers and tutorials this week and now got some conrete
questions:
(1) Sharding is also available in common relational systems. Often it is
discribed that you need an application layer for the (shards)
federation. I unterstand HBase like this layer, which implements the
whole s
Mork0075 wrote:
Hello,
can someone please explain oder point me to some documentation or
papers, where i can read well proven facts, why scaling a relational db
is so hard and scaling a document oriented db isnt?
http://labs.google.com/papers/bigtable.html
relational dbs are great for ha
Hello,
can someone please explain oder point me to some documentation or
papers, where i can read well proven facts, why scaling a relational db
is so hard and scaling a document oriented db isnt?
So perhaps if i got lots of requests to my relational db, i would
duplicate it to several serve
15 matches
Mail list logo
