Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 87046 invoked from network); 13 Dec 2009 11:45:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Dec 2009 11:45:18 -0000 Received: (qmail 34648 invoked by uid 500); 13 Dec 2009 11:45:17 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 34597 invoked by uid 500); 13 Dec 2009 11:45:16 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 34583 invoked by uid 99); 13 Dec 2009 11:45:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Dec 2009 11:45:16 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of markxr@gmail.com designates 209.85.219.220 as permitted sender) Received: from [209.85.219.220] (HELO mail-ew0-f220.google.com) (209.85.219.220) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Dec 2009 11:45:08 +0000 Received: by ewy20 with SMTP id 20so144347ewy.20 for ; Sun, 13 Dec 2009 03:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=qxCbPSQs7oKiV0qPz98oc24W63NF4AbZijyIX4UbztU=; b=pWCQNTnG6mZxlpB7/2eLEc+ZmHiZvuxdxdppG8z0mNZ4+9A4Q80g9UWtqtU7JYchRb bEK8BtdO+X38MhbJ2bmc435CfWHVzc97juUwCqYEBGuKwraWKObW5yfRKZiuGjYIcTpd 4h+oN2C6pQMj23yQwjIW+PDSAmTKgygf5Lecc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fB4X4hQQgzVlhF1KuLA+ctyeqyr36i4WNj3vDuxCsC2Mta2Ah7sMxAEZ+/CpjN+YSy x+B/iQF8O6HEHIJtuhl7gamkcRrGjjgaO+tzLjO4ji/WZKOUNua5OCdeYf90w/PcX/oD K2DiIsuPwZEtp/UbwAxTgw5xU6QmDNBDZi8B4= MIME-Version: 1.0 Received: by 10.213.1.20 with SMTP id 20mr2293016ebd.24.1260704687739; Sun, 13 Dec 2009 03:44:47 -0800 (PST) In-Reply-To: <5f7770580912121908g5067df68w3588f9bac71ba354@mail.gmail.com> References: <7c5131fa0912121508i5390615dmef66e8014bff77e2@mail.gmail.com> <5f7770580912121908g5067df68w3588f9bac71ba354@mail.gmail.com> Date: Sun, 13 Dec 2009 11:44:47 +0000 Message-ID: Subject: Re: Images store in Cassandra From: Mark Robson To: cassandra-user@incubator.apache.org Content-Type: multipart/alternative; boundary=000e0cdfce4414532d047a9aaf7b X-Virus-Checked: Checked by ClamAV on apache.org --000e0cdfce4414532d047a9aaf7b Content-Type: text/plain; charset=ISO-8859-1 2009/12/13 Tatu Saloranta > On Sat, Dec 12, 2009 at 3:08 PM, Ryan King wrote: > > On Sat, Dec 12, 2009 at 12:05 PM, Ran Tavory wrote: > >> As we're designing our systems for a move from mysql to Cassandra we're > >> considering moving our file storage to Cassandra as well. Is this wise? > I'm not sure about whether it's wise. But to work around Cassandra's limitations on bytes-per-key, you would probably have to split up large objects into several smaller ones and store them against different keys. This may be reasonable depending on what your application does. It will also work (hopefully) in your favour to split the load over multiple nodes. Mark --000e0cdfce4414532d047a9aaf7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/12/13 Tatu Saloranta <tsaloranta@gmail.com>
On Sat, Dec 12, 2009 at 3:08 PM, Ryan Kin= g <ryan@twitter.com> wrote: > On Sat, Dec 12, 2009 at 12:05 PM, Ran Tavory <rantav@gmail.com> wrote:
>> As we're designing our systems for a move from mysql to Cassan= dra we're
>> considering moving our file storage to Cassandra as well. Is this = wise?

I'm not sure abo= ut whether it's wise. But to work around Cassandra's limitations on= bytes-per-key, you would probably have to split up large objects into seve= ral smaller ones and store them against different keys.

This may be reasonable depending on what your application does. It will= also work (hopefully) in your favour to split the load over multiple nodes= .

Mark
--000e0cdfce4414532d047a9aaf7b--