You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-user@hadoop.apache.org by Bradford Stephens <br...@gmail.com> on 2009/10/29 21:48:43 UTC
HBase vs. Cassandra: new article!
Hey there,
Thought you guys would be interested in a new blog article I've posted
entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
-- I can always use some feedback!
http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
--
http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
and Distributed Lucene Consulting
http://www.roadtofailure.com -- The Fringes of Scalability, Social
Media, and Computer Science
Re: HBase vs. Cassandra: new article!
Posted by Sal Fuentes <fu...@gmail.com>.
Thanks for taking the time to contribute these corrections Jonathan. I
second Mr. Were's idea of perhaps having a wiki where we can host actual and
current facts as oppose to a blog post (that will hardly be updated as time
passes but will continue to perpetuate) about outdated and perhaps biased
descriptions/statements.
Perhaps this "comparison" should be hosted on wikipedia.org so that it won't
be perceived as subjective. Furthermore this should allow HBase devs and
users to contribute factual information as well. Lastly, this also has the
potential to contribute some healthy competition. I would be interested to
hear what you devs and users think about this as well.
On Thu, Oct 29, 2009 at 2:59 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> Okay, here are some corrections. It's a bit choppy because it's just
> that; a list of corrections.
>
> Again, this is just trying to address factual errors; I disagree with
> many of the expressed opinions, too. :)
>
> > Cassandra relies mostly on Key-Value pairs for storage
>
> No more than hbase does. Cassandra's columnfamily model does away
> with historical values, and adds supercolumns, but the two have a lot
> more in commmon with each other than with actual k/v stores.
>
> > it’s a fact that far more people are using HBase than Cassandra at this
> moment
>
> While it's possible that more people are using HBase right now, with
> 90 people in the cassandra irc chanel, and 55 in hbase, I'm
> comfortable that Cassandra's community is healthy.
>
> > despite both being similarly recent
>
> HBase is roughly 2x as old as Cassandra.
>
> > HBase values strong consistency and High Availability while Cassandra
> values Availability and Partitioning tolerance
>
> HBase actually picks CP.
>
> > Efficiently running MapReduce on Cassandra, on the other hand, is
> difficult because all of its keys are in one big “space”, so the MapReduce
> framework doesn’t know how to split and divide the data natively. There
> needs to be some hackery in place to handle all of that.
>
> Writing a hadoop input generator is a Feature, to use the article's
> terminology. It doesn't have to be hackish; in fact, trunk now has a
> key range splitter that could easily be adapted to Hadoop.
>
> Quoting an old patchset to "prove" that cassandra can only poorly
> interface to hadoop is weak.
>
> > Cassandra is only a Ruby gem install away.
>
> Or a tar download, or a deb package...
>
> > You still have to do quite a bit of manual configuration
>
> Other than columnfamily definition (which must also be done for
> hbase), I'm not sure what the author was thinking of here.
> bin/cassandra works out of the box, and (unlike hbase) there is only
> one type of process to deal with, which is a huge win for ops in
> production.
>
> > in HBase, if a region server is down, writes will be blocked for affected
> data until the data is redistributed
>
> (that is why hbase really has CP out of CAP, not CA)
>
> > Cassandra, however, has an internal method of resolving up-to-dateness
> issues with vector clocks — a complex but workable solution where basically
> the latest timestamp wins
>
> No; Cassandra uses latest-timestamp-wins, which is totally different
> from vector clocks.
>
> > Another architectural quibble is that Cassandra only supports one table
> per install. That means you can’t denormalize your data to make it more
> usable in analytical scenarios.
>
> Not even a kernel of truth there. wtf?
>
> > Cassandra is really more of a Key Value store than a Data Warehouse.
>
> Again: wtf?
>
> > Furthermore, schema changes require a cluster restart
>
> This part is true, for now. But, misleading since "schema change"
> means "adding CFs or keyspaces," not merely "modifying columns" like
> in traditional dbs.
>
> > it’s difficult to claim that Cassandra implements the BigTable model
>
> We never claimed to be a pure bigtable clone. We don't want to be,
> because of the single points of failures and operational complexity
> involved.
>
> > Cassandra is optimized for small datacenters (hundreds of nodes)
> connected by very fast fiber. HBase, being based on research originally
> published by Google, is happy to handle replication to thousands of
> planet-strewn nodes across the ’slow’, unpredictable Internet
>
> Cassandra has multi-datacenter support already. HBase didn't, last I
> checked. So this is weird.
>
> > This first diagram is a model of the Cassandra replication scheme.
>
> Note that all these steps happen in parallel.
>
> > it’s impossible to tell when the required number of replicas will be
> up-to-date. This can be extremely painful in a live situation — when one of
> your DCs goes down, you often want to know *exactly* when to expect data
> consistency
>
> Cassandra provides consistency when R + W > N (read replica count +
> write replica count > replication factor). If you do writes and reads
> both with QUORUM, for one example, you can expect data consistency as
> soon as there are enough nodes for a quorum (which may not even
> require the DC to be online). That is not "impossible to tell" at
> all.
>
> > It’s important to note that Cassandra relies on high-speed fiber between
> datacenters.
>
> Simply flat-out wrong.
>
> > If your writes are taking 1 or 2 ms, that’s fine. But when a DC goes out
> and you have to revert to a secondary one in China instead of 20 miles away,
> the incredible latency will lead to write timeouts and highly inconsistent
> data.
>
> Sure, "incredible" latency of 100ms or so is bad, but it's not the end
> of the world, and won't cause either write timeouts or inconsistent
> data, assuming that you are in fact using R + W > N.
>
--
Salvador Fuentes Jr.
323-540-4SAL
Re: HBase vs. Cassandra: new article!
Posted by Jonathan Ellis <jb...@gmail.com>.
Okay, here are some corrections. It's a bit choppy because it's just
that; a list of corrections.
Again, this is just trying to address factual errors; I disagree with
many of the expressed opinions, too. :)
> Cassandra relies mostly on Key-Value pairs for storage
No more than hbase does. Cassandra's columnfamily model does away
with historical values, and adds supercolumns, but the two have a lot
more in commmon with each other than with actual k/v stores.
> it’s a fact that far more people are using HBase than Cassandra at this moment
While it's possible that more people are using HBase right now, with
90 people in the cassandra irc chanel, and 55 in hbase, I'm
comfortable that Cassandra's community is healthy.
> despite both being similarly recent
HBase is roughly 2x as old as Cassandra.
> HBase values strong consistency and High Availability while Cassandra values Availability and Partitioning tolerance
HBase actually picks CP.
> Efficiently running MapReduce on Cassandra, on the other hand, is difficult because all of its keys are in one big “space”, so the MapReduce framework doesn’t know how to split and divide the data natively. There needs to be some hackery in place to handle all of that.
Writing a hadoop input generator is a Feature, to use the article's
terminology. It doesn't have to be hackish; in fact, trunk now has a
key range splitter that could easily be adapted to Hadoop.
Quoting an old patchset to "prove" that cassandra can only poorly
interface to hadoop is weak.
> Cassandra is only a Ruby gem install away.
Or a tar download, or a deb package...
> You still have to do quite a bit of manual configuration
Other than columnfamily definition (which must also be done for
hbase), I'm not sure what the author was thinking of here.
bin/cassandra works out of the box, and (unlike hbase) there is only
one type of process to deal with, which is a huge win for ops in
production.
> in HBase, if a region server is down, writes will be blocked for affected data until the data is redistributed
(that is why hbase really has CP out of CAP, not CA)
> Cassandra, however, has an internal method of resolving up-to-dateness issues with vector clocks — a complex but workable solution where basically the latest timestamp wins
No; Cassandra uses latest-timestamp-wins, which is totally different
from vector clocks.
> Another architectural quibble is that Cassandra only supports one table per install. That means you can’t denormalize your data to make it more usable in analytical scenarios.
Not even a kernel of truth there. wtf?
> Cassandra is really more of a Key Value store than a Data Warehouse.
Again: wtf?
> Furthermore, schema changes require a cluster restart
This part is true, for now. But, misleading since "schema change"
means "adding CFs or keyspaces," not merely "modifying columns" like
in traditional dbs.
> it’s difficult to claim that Cassandra implements the BigTable model
We never claimed to be a pure bigtable clone. We don't want to be,
because of the single points of failures and operational complexity
involved.
> Cassandra is optimized for small datacenters (hundreds of nodes) connected by very fast fiber. HBase, being based on research originally published by Google, is happy to handle replication to thousands of planet-strewn nodes across the ’slow’, unpredictable Internet
Cassandra has multi-datacenter support already. HBase didn't, last I
checked. So this is weird.
> This first diagram is a model of the Cassandra replication scheme.
Note that all these steps happen in parallel.
> it’s impossible to tell when the required number of replicas will be up-to-date. This can be extremely painful in a live situation — when one of your DCs goes down, you often want to know *exactly* when to expect data consistency
Cassandra provides consistency when R + W > N (read replica count +
write replica count > replication factor). If you do writes and reads
both with QUORUM, for one example, you can expect data consistency as
soon as there are enough nodes for a quorum (which may not even
require the DC to be online). That is not "impossible to tell" at
all.
> It’s important to note that Cassandra relies on high-speed fiber between datacenters.
Simply flat-out wrong.
> If your writes are taking 1 or 2 ms, that’s fine. But when a DC goes out and you have to revert to a secondary one in China instead of 20 miles away, the incredible latency will lead to write timeouts and highly inconsistent data.
Sure, "incredible" latency of 100ms or so is bad, but it's not the end
of the world, and won't cause either write timeouts or inconsistent
data, assuming that you are in fact using R + W > N.
Re: HBase vs. Cassandra: new article!
Posted by Jonathan Ellis <jb...@gmail.com>.
Okay, here are some corrections. It's a bit choppy because it's just
that; a list of corrections.
Again, this is just trying to address factual errors; I disagree with
many of the expressed opinions, too. :)
> Cassandra relies mostly on Key-Value pairs for storage
No more than hbase does. Cassandra's columnfamily model does away
with historical values, and adds supercolumns, but the two have a lot
more in commmon with each other than with actual k/v stores.
> it’s a fact that far more people are using HBase than Cassandra at this moment
While it's possible that more people are using HBase right now, with
90 people in the cassandra irc chanel, and 55 in hbase, I'm
comfortable that Cassandra's community is healthy.
> despite both being similarly recent
HBase is roughly 2x as old as Cassandra.
> HBase values strong consistency and High Availability while Cassandra values Availability and Partitioning tolerance
HBase actually picks CP.
> Efficiently running MapReduce on Cassandra, on the other hand, is difficult because all of its keys are in one big “space”, so the MapReduce framework doesn’t know how to split and divide the data natively. There needs to be some hackery in place to handle all of that.
Writing a hadoop input generator is a Feature, to use the article's
terminology. It doesn't have to be hackish; in fact, trunk now has a
key range splitter that could easily be adapted to Hadoop.
Quoting an old patchset to "prove" that cassandra can only poorly
interface to hadoop is weak.
> Cassandra is only a Ruby gem install away.
Or a tar download, or a deb package...
> You still have to do quite a bit of manual configuration
Other than columnfamily definition (which must also be done for
hbase), I'm not sure what the author was thinking of here.
bin/cassandra works out of the box, and (unlike hbase) there is only
one type of process to deal with, which is a huge win for ops in
production.
> in HBase, if a region server is down, writes will be blocked for affected data until the data is redistributed
(that is why hbase really has CP out of CAP, not CA)
> Cassandra, however, has an internal method of resolving up-to-dateness issues with vector clocks — a complex but workable solution where basically the latest timestamp wins
No; Cassandra uses latest-timestamp-wins, which is totally different
from vector clocks.
> Another architectural quibble is that Cassandra only supports one table per install. That means you can’t denormalize your data to make it more usable in analytical scenarios.
Not even a kernel of truth there. wtf?
> Cassandra is really more of a Key Value store than a Data Warehouse.
Again: wtf?
> Furthermore, schema changes require a cluster restart
This part is true, for now. But, misleading since "schema change"
means "adding CFs or keyspaces," not merely "modifying columns" like
in traditional dbs.
> it’s difficult to claim that Cassandra implements the BigTable model
We never claimed to be a pure bigtable clone. We don't want to be,
because of the single points of failures and operational complexity
involved.
> Cassandra is optimized for small datacenters (hundreds of nodes) connected by very fast fiber. HBase, being based on research originally published by Google, is happy to handle replication to thousands of planet-strewn nodes across the ’slow’, unpredictable Internet
Cassandra has multi-datacenter support already. HBase didn't, last I
checked. So this is weird.
> This first diagram is a model of the Cassandra replication scheme.
Note that all these steps happen in parallel.
> it’s impossible to tell when the required number of replicas will be up-to-date. This can be extremely painful in a live situation — when one of your DCs goes down, you often want to know *exactly* when to expect data consistency
Cassandra provides consistency when R + W > N (read replica count +
write replica count > replication factor). If you do writes and reads
both with QUORUM, for one example, you can expect data consistency as
soon as there are enough nodes for a quorum (which may not even
require the DC to be online). That is not "impossible to tell" at
all.
> It’s important to note that Cassandra relies on high-speed fiber between datacenters.
Simply flat-out wrong.
> If your writes are taking 1 or 2 ms, that’s fine. But when a DC goes out and you have to revert to a secondary one in China instead of 20 miles away, the incredible latency will lead to write timeouts and highly inconsistent data.
Sure, "incredible" latency of 100ms or so is bad, but it's not the end
of the world, and won't cause either write timeouts or inconsistent
data, assuming that you are in fact using R + W > N.
Re: HBase vs. Cassandra: new article!
Posted by Chris Were <ch...@gmail.com>.
Any chance of posting the factual errors publicly? Even in an abbreviated
form on the wiki under "common misconceptions" or similar would be useful.
Such a list would potentially be useful to new cassandra users and also
debunk myths that come about as a result of articles like this, or even
better, prevent them becoming myths in the first place.
On Fri, Oct 30, 2009 at 7:45 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> I never saw him ask anything here or #cassandra.
>
> I dropped in on #hbase and he said he's willing to fix factual errors,
> so I gave him a list. It was pretty long. :)
>
> On Thu, Oct 29, 2009 at 3:08 PM, Chris Goffinet <go...@digg.com> wrote:
> > Someone should really talk to this guy. There are many incorrect
> statements
> > ;-) Did he even ask the devs?
> >
> > ---
> > Chris Goffinet
> > goffinet@digg.com
> >
> >
> >
> >
> >
> > On Oct 29, 2009, at 1:51 PM, Michael Greene wrote:
> >
> >> Forwarding this along:
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Bradford Stephens <br...@gmail.com>
> >> Date: Thu, Oct 29, 2009 at 3:48 PM
> >> Subject: HBase vs. Cassandra: new article!
> >> To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
> >>
> >>
> >> Hey there,
> >>
> >> Thought you guys would be interested in a new blog article I've posted
> >> entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
> >> -- I can always use some feedback!
> >>
> http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
> >>
> >> --
> >> http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
> >> and Distributed Lucene Consulting
> >>
> >> http://www.roadtofailure.com -- The Fringes of Scalability, Social
> >> Media, and Computer Science
> >
> >
>
Re: HBase vs. Cassandra: new article!
Posted by Chris Were <ch...@gmail.com>.
Any chance of posting the factual errors publicly? Even in an abbreviated
form on the wiki under "common misconceptions" or similar would be useful.
Such a list would potentially be useful to new cassandra users and also
debunk myths that come about as a result of articles like this, or even
better, prevent them becoming myths in the first place.
On Fri, Oct 30, 2009 at 7:45 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> I never saw him ask anything here or #cassandra.
>
> I dropped in on #hbase and he said he's willing to fix factual errors,
> so I gave him a list. It was pretty long. :)
>
> On Thu, Oct 29, 2009 at 3:08 PM, Chris Goffinet <go...@digg.com> wrote:
> > Someone should really talk to this guy. There are many incorrect
> statements
> > ;-) Did he even ask the devs?
> >
> > ---
> > Chris Goffinet
> > goffinet@digg.com
> >
> >
> >
> >
> >
> > On Oct 29, 2009, at 1:51 PM, Michael Greene wrote:
> >
> >> Forwarding this along:
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Bradford Stephens <br...@gmail.com>
> >> Date: Thu, Oct 29, 2009 at 3:48 PM
> >> Subject: HBase vs. Cassandra: new article!
> >> To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
> >>
> >>
> >> Hey there,
> >>
> >> Thought you guys would be interested in a new blog article I've posted
> >> entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
> >> -- I can always use some feedback!
> >>
> http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
> >>
> >> --
> >> http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
> >> and Distributed Lucene Consulting
> >>
> >> http://www.roadtofailure.com -- The Fringes of Scalability, Social
> >> Media, and Computer Science
> >
> >
>
Re: HBase vs. Cassandra: new article!
Posted by Jonathan Ellis <jb...@gmail.com>.
I never saw him ask anything here or #cassandra.
I dropped in on #hbase and he said he's willing to fix factual errors,
so I gave him a list. It was pretty long. :)
On Thu, Oct 29, 2009 at 3:08 PM, Chris Goffinet <go...@digg.com> wrote:
> Someone should really talk to this guy. There are many incorrect statements
> ;-) Did he even ask the devs?
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
> On Oct 29, 2009, at 1:51 PM, Michael Greene wrote:
>
>> Forwarding this along:
>>
>>
>> ---------- Forwarded message ----------
>> From: Bradford Stephens <br...@gmail.com>
>> Date: Thu, Oct 29, 2009 at 3:48 PM
>> Subject: HBase vs. Cassandra: new article!
>> To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
>>
>>
>> Hey there,
>>
>> Thought you guys would be interested in a new blog article I've posted
>> entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
>> -- I can always use some feedback!
>> http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
>>
>> --
>> http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
>> and Distributed Lucene Consulting
>>
>> http://www.roadtofailure.com -- The Fringes of Scalability, Social
>> Media, and Computer Science
>
>
Re: HBase vs. Cassandra: new article!
Posted by Jonathan Ellis <jb...@gmail.com>.
I never saw him ask anything here or #cassandra.
I dropped in on #hbase and he said he's willing to fix factual errors,
so I gave him a list. It was pretty long. :)
On Thu, Oct 29, 2009 at 3:08 PM, Chris Goffinet <go...@digg.com> wrote:
> Someone should really talk to this guy. There are many incorrect statements
> ;-) Did he even ask the devs?
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
> On Oct 29, 2009, at 1:51 PM, Michael Greene wrote:
>
>> Forwarding this along:
>>
>>
>> ---------- Forwarded message ----------
>> From: Bradford Stephens <br...@gmail.com>
>> Date: Thu, Oct 29, 2009 at 3:48 PM
>> Subject: HBase vs. Cassandra: new article!
>> To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
>>
>>
>> Hey there,
>>
>> Thought you guys would be interested in a new blog article I've posted
>> entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
>> -- I can always use some feedback!
>> http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
>>
>> --
>> http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
>> and Distributed Lucene Consulting
>>
>> http://www.roadtofailure.com -- The Fringes of Scalability, Social
>> Media, and Computer Science
>
>
Re: HBase vs. Cassandra: new article!
Posted by Chris Goffinet <go...@digg.com>.
Someone should really talk to this guy. There are many incorrect
statements ;-) Did he even ask the devs?
---
Chris Goffinet
goffinet@digg.com
On Oct 29, 2009, at 1:51 PM, Michael Greene wrote:
> Forwarding this along:
>
>
> ---------- Forwarded message ----------
> From: Bradford Stephens <br...@gmail.com>
> Date: Thu, Oct 29, 2009 at 3:48 PM
> Subject: HBase vs. Cassandra: new article!
> To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
>
>
> Hey there,
>
> Thought you guys would be interested in a new blog article I've posted
> entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
> -- I can always use some feedback!
> http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
>
> --
> http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
> and Distributed Lucene Consulting
>
> http://www.roadtofailure.com -- The Fringes of Scalability, Social
> Media, and Computer Science
Re: HBase vs. Cassandra: new article!
Posted by Jonathan Ellis <jb...@gmail.com>.
is this guy serious? "Cassandra relies mostly on Key-Value pairs for
storage?" news to me.
On Thu, Oct 29, 2009 at 2:51 PM, Michael Greene
<mi...@gmail.com> wrote:
> Forwarding this along:
>
>
> ---------- Forwarded message ----------
> From: Bradford Stephens <br...@gmail.com>
> Date: Thu, Oct 29, 2009 at 3:48 PM
> Subject: HBase vs. Cassandra: new article!
> To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
>
>
> Hey there,
>
> Thought you guys would be interested in a new blog article I've posted
> entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
> -- I can always use some feedback!
> http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
>
> --
> http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
> and Distributed Lucene Consulting
>
> http://www.roadtofailure.com -- The Fringes of Scalability, Social
> Media, and Computer Science
>
Re: HBase vs. Cassandra: new article!
Posted by Chris Goffinet <go...@digg.com>.
Someone should really talk to this guy. There are many incorrect
statements ;-) Did he even ask the devs?
---
Chris Goffinet
goffinet@digg.com
On Oct 29, 2009, at 1:51 PM, Michael Greene wrote:
> Forwarding this along:
>
>
> ---------- Forwarded message ----------
> From: Bradford Stephens <br...@gmail.com>
> Date: Thu, Oct 29, 2009 at 3:48 PM
> Subject: HBase vs. Cassandra: new article!
> To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
>
>
> Hey there,
>
> Thought you guys would be interested in a new blog article I've posted
> entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
> -- I can always use some feedback!
> http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
>
> --
> http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
> and Distributed Lucene Consulting
>
> http://www.roadtofailure.com -- The Fringes of Scalability, Social
> Media, and Computer Science
Re: HBase vs. Cassandra: new article!
Posted by Jonathan Ellis <jb...@gmail.com>.
is this guy serious? "Cassandra relies mostly on Key-Value pairs for
storage?" news to me.
On Thu, Oct 29, 2009 at 2:51 PM, Michael Greene
<mi...@gmail.com> wrote:
> Forwarding this along:
>
>
> ---------- Forwarded message ----------
> From: Bradford Stephens <br...@gmail.com>
> Date: Thu, Oct 29, 2009 at 3:48 PM
> Subject: HBase vs. Cassandra: new article!
> To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
>
>
> Hey there,
>
> Thought you guys would be interested in a new blog article I've posted
> entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
> -- I can always use some feedback!
> http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
>
> --
> http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
> and Distributed Lucene Consulting
>
> http://www.roadtofailure.com -- The Fringes of Scalability, Social
> Media, and Computer Science
>
Fwd: HBase vs. Cassandra: new article!
Posted by Michael Greene <mi...@gmail.com>.
Forwarding this along:
---------- Forwarded message ----------
From: Bradford Stephens <br...@gmail.com>
Date: Thu, Oct 29, 2009 at 3:48 PM
Subject: HBase vs. Cassandra: new article!
To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
Hey there,
Thought you guys would be interested in a new blog article I've posted
entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
-- I can always use some feedback!
http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
--
http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
and Distributed Lucene Consulting
http://www.roadtofailure.com -- The Fringes of Scalability, Social
Media, and Computer Science
Fwd: HBase vs. Cassandra: new article!
Posted by Michael Greene <mi...@gmail.com>.
Forwarding this along:
---------- Forwarded message ----------
From: Bradford Stephens <br...@gmail.com>
Date: Thu, Oct 29, 2009 at 3:48 PM
Subject: HBase vs. Cassandra: new article!
To: hbase-user@hadoop.apache.org, core-user@hadoop.apache.org
Hey there,
Thought you guys would be interested in a new blog article I've posted
entitled "HBase vs. Cassandra: NoSQL Battle!". I hope you all enjoy it
-- I can always use some feedback!
http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
--
http://www.drawntoscaleconsulting.com - Scalability, Hadoop, HBase,
and Distributed Lucene Consulting
http://www.roadtofailure.com -- The Fringes of Scalability, Social
Media, and Computer Science