I agree, that traditional RDBMS have good and established admin/mgmt
tools/practices.
But C* strength is distributed, failure tolerant operation. And this is exactly
where nearly all traditional RDBMS just fail. I've seen both Oracle and IBM
"clusters"/"HA" "solutions" (and a lot of other software) fail regularly - even
just running at moderate load.
--
Sent from my iPhone
> Am 09.07.2014 um 02:51 schrieb Robert Coli <rc...@eventbrite.com>:
>
>> On Fri, Jul 4, 2014 at 2:10 PM, DuyHai Doan <doanduy...@gmail.com> wrote:
>> c. operational simplicity due to master-less architecture. This feature is,
>> although quite transparent for developers, is a key selling point. Having
>> suffered when installing manually a Hadoop cluster, I happen to love the
>> deployment simplicity of C*, only one process per node, no moving parts.
>
> Asserting that Cassandra, as a fully functioning production system, is
> currently easier to operate than RDBMS is just false. It is still false even
> if we ignore the availability of experienced RDBMS operators and decades of
> RDBMS operational best practice.
>
> The quality of software engineering practice in RDBMS land also most
> assuredly results in a more easily operable system in many, many use cases.
> Yes, Cassandra is more tolerant to individual node failures. This turns out
> to not matter as much in terms of "operability" as non-operators appear to
> think it does. Very trivial operational activities ("create a new
> columnfamily" or "replace a failed node") are subject to failure mode edge
> cases which often are not resolvable without brute force methods.
>
> I am unable to get my head around the oft-heard marketing assertion that a
> data-store in which such common activities are not bulletproof is capable of
> being than better to operate than the RDBMS status quo. The production
> operators I know also do not agree that Cassandra is simple to operate.
>
> All the above aside, I continue to maintain that Cassandra is the best at
> being the type of thing that it is. If you have a need to horizontally scale
> a use case that is well suited for its strength and poorly suited for RDBMS,
> you should use it. Far fewer people actually have this sort of case than
> think they do.
>
> =Rob
