From user-return-15371-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Sun Apr 03 16:14:27 2011 Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 28821 invoked from network); 3 Apr 2011 16:14:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Apr 2011 16:14:27 -0000 Received: (qmail 87398 invoked by uid 500); 3 Apr 2011 16:14:25 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 87372 invoked by uid 500); 3 Apr 2011 16:14:25 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 87364 invoked by uid 99); 3 Apr 2011 16:14:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Apr 2011 16:14:25 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of nguba@mac.com designates 17.148.16.91 as permitted sender) Received: from [17.148.16.91] (HELO asmtpout016.mac.com) (17.148.16.91) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Apr 2011 16:14:18 +0000 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_VUHqtsbVzNdJHhU2h5OcQQ)" Received: from [192.168.1.65] ([87.194.108.113]) by asmtp016.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPA id <0LJ300HF53R7UT60@asmtp016.mac.com> for user@cassandra.apache.org; Sun, 03 Apr 2011 09:13:57 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-02_08:2011-04-02,2011-04-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104030062 Message-id: <4D989CC3.5020603@mac.com> Date: Sun, 03 Apr 2011 17:13:55 +0100 From: Nico Guba User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 To: user@cassandra.apache.org Subject: Re: Ditching Cassandra References: In-reply-to: X-Enigmail-Version: 1.1.1 X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --Boundary_(ID_VUHqtsbVzNdJHhU2h5OcQQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 3/30/2011 1:11 AM, Gregori Schmidt wrote > > * You need to have official client libraries and they need to be > programmer friendly. Yes, I know there are nice people > maintaining a plethora of different libraries, but you need to > man up and face reality: the chaos that is the Cassandra client > space is a horrible mess. > I wouldn't call it a horrible mess but the learning curve for newcomers can be quite steep. This said, having a common portable spec to program to (ie thrift) is a very good idea instead. > * It is buggy and the solution seems to be to just go to the next > release. And the next. And the next. Which would be okay if > you could upgrade all the time, but what to do once you hit > production? > It's a fair concern. But bugs are fixed in either upstream or minor releases (or even *shudder* maintenance patches...). But that may be a small price to pay when you consider the headaches scaling out other systems (and don't you even think this will be un-problematic). > I would recommend that everyone interested in improving Cassandra take > the day off, download MongoDB and > read https://github.com/karlseguin/the-little-mongodb-book . Then, > while you are downloading, unpacking, looking at what was in the JAR, > reading the book and pawing through the examples: _pay attention_ to > the neatness and the effortlessness the ease with which you can use > MongoDB. Then spend the rest of the day implementing something on top > of it to gain some hacking experience. Arguably, the documentation is neat. The scaling solution however, is not. And that's the biggest headache. Mongo should learn from cassandra in this respect. > No, really. Do it. This is important. You need to connect with the > user and you need to understand what you ought to be aspiring to. Took you advice, done it. You may be looking for a rdbms replacement -- and mongo may be a good solution there, but the master/slave replication setup puts me off. That's a big nono for us and probably a lot of people on this list. Considering the griefs of master/slave replication for scalability (oh, how have we been bitten by this one over the years), I strongly applaud a project like cassandra to step up to the challenge and propel the free software community into 21st century scalability! Yes, the documentation could be better (it always can be), yes the Cassandra book by O'Reilly has a HUGE amount of duplication (speak unnecessary code/bad programming practice). But the constructive thing to do here is to: 1 - CONTRIBUTE to the documentation (I was unhappy with the Exim and Windowmaker docs a looong time ago and my efforts did not go in vain) 2 - Direct your flame about to book on ora.com or amazon where this sort of feedback goes to the right channels, but don't blame the cassandra project for the shortcomings of the book. That's someone else's problem ;) 3 - enjoy MongoDB. Let us know how it scales. Every project can learn from each other. Happy Hacking! -- =NPG= --Boundary_(ID_VUHqtsbVzNdJHhU2h5OcQQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 3/30/2011 1:11 AM, Gregori Schmidt wrote
  • You need to have official client libraries and they need to be programmer friendly.  Yes, I know there are nice people maintaining a plethora of different libraries, but you need to man up and face reality:  the chaos that is the Cassandra client space is a horrible mess.

I wouldn't call it a horrible mess but the learning curve for newcomers can be quite steep.   This said, having a common portable spec to program to (ie thrift) is a very good idea instead.

  • It is buggy and the solution seems to be to just go to the next release.  And the next.  And the next.  Which would be okay if you could upgrade all the time, but what to do once you hit production?

It's a fair concern.  But bugs are fixed in either upstream or minor releases (or even *shudder* maintenance patches...).  But that may be a small price to pay when you consider the headaches scaling out other systems (and don't you even think this will be un-problematic).

I would recommend that everyone interested in improving Cassandra take the day off,  download MongoDB and read https://github.com/karlseguin/the-little-mongodb-book . Then, while you are downloading, unpacking, looking at what was in the JAR, reading the book and pawing through the examples: _pay attention_ to the neatness and the effortlessness the ease with which you can use MongoDB.  Then spend the rest of the day implementing something on top of it to gain some hacking experience.

Arguably, the documentation is neat.  The scaling solution however, is not.  And that's the biggest headache.  Mongo should learn from cassandra in this respect.

No, really.  Do it.  This is important.  You need to connect with the user and you need to understand what you ought to be aspiring to.

Took you advice, done it.  You may be looking for a rdbms replacement -- and mongo may be a good solution there, but the master/slave replication setup puts me off.  That's a big nono for us and probably a lot of people on this list.

Considering the griefs of master/slave replication for scalability (oh, how have we been bitten by this one over the years),  I strongly applaud a project like cassandra to step up to the challenge and propel the free software community into 21st century scalability!  

Yes, the documentation could be better (it always can be), yes the Cassandra book by O'Reilly has a HUGE amount of duplication (speak unnecessary code/bad programming practice).   But the constructive thing to do here is to:

1 - CONTRIBUTE to the documentation (I was unhappy with the Exim and Windowmaker docs a looong time ago and my efforts did not go in vain)

2 - Direct your flame about to book on ora.com or amazon where this sort of feedback goes to the right channels, but don't blame the cassandra project for the shortcomings of the book.  That's someone else's problem ;)

3 - enjoy MongoDB.  Let us know how it scales.  Every project can learn from each other.

Happy Hacking!

--
    =NPG=

--Boundary_(ID_VUHqtsbVzNdJHhU2h5OcQQ)--