From Wed Apr 9 06:22:43 2014 Return-Path: X-Original-To: Delivered-To: Received: from ( []) by (Postfix) with SMTP id 3115F10DF1 for ; Wed, 9 Apr 2014 06:22:43 +0000 (UTC) Received: (qmail 3599 invoked by uid 500); 9 Apr 2014 06:22:39 -0000 Delivered-To: Received: (qmail 3488 invoked by uid 500); 9 Apr 2014 06:22:36 -0000 Mailing-List: contact; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list Received: (qmail 3479 invoked by uid 99); 9 Apr 2014 06:22:34 -0000 Received: from (HELO ( by (qpsmtpd/0.29) with ESMTP; Wed, 09 Apr 2014 06:22:34 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: Received-SPF: pass ( domain of designates as permitted sender) Received: from [] (HELO ( by (qpsmtpd/0.29) with ESMTP; Wed, 09 Apr 2014 06:22:28 +0000 Received: by with SMTP id uo5so2072986pbc.24 for ; Tue, 08 Apr 2014 23:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type; bh=y/pNR55igcrIGshOorJWSoCjvpHe8hFueRXM7TrU6CI=; b=wR9wUwDgNvZ7UF29HpPqr8KsDziic6PxgAKCgsjRmhoCdjT4oxFLfG+MzqVuDt4W93 /8MZcyCfP/BCU5BdcXQ0OH9P4fLV8V0DJn/wPaPSeGyzlzfyIDSCi2LExXrSsFstkW5z El8k2QQLW1zjfWHpVa7WSZXoij6fVsjC1mRsRYzab/jvFNwVpcfj9h12Ubftvm9Se7pW VmbpKYH6iKyFwixeqNZUahprwR5lSkXRRSEOr+KCEkeXc6nUmeXu/glYzKFTRJ7K4C2F sYmxn+zoEKM5vaDrrSafnYplDU1Kx0R63iK4nXJIQ0HwCRCEdmKKhLx5bxkGR6Hfmxcj 7Aow== X-Received: by with SMTP id yy3mr9819253pbc.56.1397024527521; Tue, 08 Apr 2014 23:22:07 -0700 (PDT) Received: from tarvos.local ( []) by with ESMTPSA id h6sm7988pbl.75.2014. for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 23:22:06 -0700 (PDT) Date: Tue, 8 Apr 2014 23:22:02 -0700 From: Allan C To: Message-ID: Subject: Multiget performance X-Mailer: Airmail (237) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5344e70c_2d517796_9d5a" X-Virus-Checked: Checked by ClamAV on --5344e70c_2d517796_9d5a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, I=E2=80=99ve always been told that multigets are a Cassandra anti-pattern= for performance reasons. I ran a quick test tonight to prove it to mysel= f, and, sure enough, slowness ensued. It takes about 150ms to get 100 key= s for my use case. Not terrible, but at least an order of magnitude from = what I need it to be. So far, I=E2=80=99ve been able to denormalize and not have any problems. = Today, I ran into a use case where denormalization introduces a huge amou= nt of complexity to the code. It=E2=80=99s very tempting to cache a subset in Redis and call it a day =E2= =80=94 probably will. But, that=E2=80=99s not a very satisfying answer. I= t=E2=80=99s only about 5GB of data and it feels like I should be able to = tune a Cassandra C=46 to be within 2x. The workload is around 70% reads. Most of the writes are updates to exist= ing data. Currently, it=E2=80=99s in an LCS C=46 with =7E30M rows. The cl= uster is 300GB total with 3-way replication, running across 12 fairly lar= ge boxes with 16G RAM. All on SSDs. Striped across 3 AZs in AWS (hi1.4xla= rges, fwiw). Has anyone had success getting good results for this kind of workload=3F = Or, is Cassandra just not suited for it=C2=A0at all and I should just use= an in-memory store=3F -Allan --5344e70c_2d517796_9d5a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline