Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 37294 invoked from network); 13 Jul 2010 16:07:38 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 13 Jul 2010 16:07:38 -0000 Received: (qmail 35492 invoked by uid 500); 13 Jul 2010 16:07:37 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 35476 invoked by uid 500); 13 Jul 2010 16:07:36 -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 35459 invoked by uid 99); 13 Jul 2010 16:07:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Jul 2010 16:07:36 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.216.44] (HELO mail-qw0-f44.google.com) (209.85.216.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Jul 2010 16:07:30 +0000 Received: by qwe5 with SMTP id 5so1875006qwe.31 for ; Tue, 13 Jul 2010 09:07:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.77 with SMTP id l13mr8902245qac.166.1279037229103; Tue, 13 Jul 2010 09:07:09 -0700 (PDT) Received: by 10.229.224.141 with HTTP; Tue, 13 Jul 2010 09:07:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 09:07:09 -0700 Message-ID: Subject: Re: advice, is cassandra suitable for a multi-tanency vBulletin type application? From: Benjamin Black To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Jul 13, 2010 at 2:43 AM, Paul Prescod wrote: > On Mon, Jul 12, 2010 at 11:44 PM, Benjamin Black wrote: >> We use Cassandra (multidimensional metrics) *and* redis (counters and >> alerts) *and* MySQL (supporting Rails). =A0Right tool for each job. =A0T= he >> idea that it is a good thing to cram everything into a single database >> (and data model), beaten into everyone by years of relational database >> marketing, is not true now and never really was. =A0Embrace diversity! > > As I'm sure you know more than most, every component in production has > an operational cost, and therefore each should be justifiable. > Similarly, there is a cost to using a tool that is ill-suited to the task. This is the fundamental trade-off in using more specialized systems vs a general, relational store. My experience so far is the additional operational overhead is quite low, and the benefits in performance and simplicity of implementation far outweigh it. b