Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 11157 invoked from network); 4 Nov 2010 04:30:01 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 Nov 2010 04:30:01 -0000 Received: (qmail 97207 invoked by uid 500); 4 Nov 2010 04:30:30 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 96984 invoked by uid 500); 4 Nov 2010 04:30:27 -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 96976 invoked by uid 99); 4 Nov 2010 04:30:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Nov 2010 04:30:26 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.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 eprosenx@gmail.com designates 209.85.214.44 as permitted sender) Received: from [209.85.214.44] (HELO mail-bw0-f44.google.com) (209.85.214.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Nov 2010 04:30:20 +0000 Received: by bwz12 with SMTP id 12so1338343bwz.31 for ; Wed, 03 Nov 2010 21:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=JUZJbUPFlXxzFc3XyAzgeaGr9d6NzxPVSymRW755JY8=; b=v71iotX7AAej63EE3t5sCRG0YOTMjd6cRCuQwQHG8HPYNK/25iTlWecQJQ54ACXsnG oXdNBVeqMwUZCCfsmo4id1aC2Fw7UeZXP7hcxFh4dDC5AQV8AmynVNZBkopqzSh2VPdY PsKm5b86ZRlaJXR7653CWvuLhsnJVJu+WRbrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=j3NqA+NalVh6jNM6vPAWVPvOqTcGw7wOBvOlw4GlcuWpdtk56BI1Mv1nfHWW/5dFZZ mIQBogqgE/Xrp89WOWulPxm/05eYLkxyPjgdvf69t1VkvfgiqqgvkgtU3EiKKFSb/NVQ nktbv7OxmryHb++tjYr3OSzv4lT5Cn425Sb6M= MIME-Version: 1.0 Received: by 10.204.56.194 with SMTP id z2mr161056bkg.129.1288844999209; Wed, 03 Nov 2010 21:29:59 -0700 (PDT) Sender: eprosenx@gmail.com Received: by 10.204.154.144 with HTTP; Wed, 3 Nov 2010 21:29:59 -0700 (PDT) In-Reply-To: References: <4CD1B8EA.3050706@pdf.com> Date: Wed, 3 Nov 2010 21:29:59 -0700 X-Google-Sender-Auth: LoXYKCoyNOvOsgR92p6WpCYnq2Q Message-ID: Subject: Re: SSD vs. HDD From: Eric Rosenberry To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001636c923755933ee0494329ca4 X-Virus-Checked: Checked by ClamAV on apache.org --001636c923755933ee0494329ca4 Content-Type: text/plain; charset=ISO-8859-1 Some comments inline... On Wed, Nov 3, 2010 at 1:44 PM, Jonathan Shook wrote: > SSDs are not reliable after a (relatively-low compared to spinning > disk) number of writes. > They may significantly boost performance if used on the "journal" > storage, but will suffer short lifetimes for highly-random write > patterns. > I agree with this statement in general, however, my understanding is that Cassandra NEVER does random writes. It only ever does large sequential writes. Cassandra could potentially be the perfect use case for MLC (multi-level-cell) SSD's. On Wed, Nov 3, 2010 at 1:58 PM, Tyler Hobbs wrote: > > You do *not* want to waste an SSD on the commitlog drive, as even a slow > HDD can write sequentially very quickly. For the data drive, they might > make sense. > Totally agreed, we do a few thousand writes per second on a single 7200rpm SATA disk. On Wed, Nov 3, 2010 at 5:20 PM, Alaa Zubaidi wrote: > around 1800 col/sec per node, 3kb columns, reading is the same. > Data will be deleted after 4 hours. Hmm, only keeping the data for 4 hours could present some unique challenges with Cassandra since it does not actually delete the data (it only tombstones the data). There are several factors that play into when exactly the data actually goes away -Eric --001636c923755933ee0494329ca4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some comments inline...

On Wed, No= v 3, 2010 at 1:44 PM, Jonathan Shook <jshook@gmail.com> wrote:
SSDs are not reliable after a (relatively-low compared to spinning
disk) number of writes.
They may significantly boost performance if used on the "journal"=
storage, but will suffer short lifetimes for highly-random write
patterns.

I agree with this statement i= n general, however, my understanding is that=A0Cassandra NEVER does random = writes. =A0It only ever does large sequential writes. =A0Cassandra could po= tentially be the perfect use case for MLC (multi-level-cell) SSD's.

On Wed, Nov 3, 2010 at 1:58 = PM, Tyler Hobbs=A0<tyler@riptano.com>=A0wrote:
You do *not* want to waste an SSD on the commitlog drive, as even a slow HD= D can write sequentially very quickly.=A0 For the data drive, they might ma= ke sense.

Totally agreed, we do a few t= housand writes per second on a single 7200rpm SATA disk.

On Wed, Nov 3, 2010 at 5:20 PM,= Alaa Zubaidi=A0<alaa.zubaidi@pdf.com>=A0wrote:
around 1800 col/sec per node, 3kb columns, reading is the same.
Data wil= l be deleted after 4 hours.

Hmm, only= keeping the data for 4 hours could present some unique challenges with Cas= sandra since it does not actually delete the data (it only tombstones the d= ata). =A0There are several factors that play into when exactly the data act= ually goes away=A0

-Eric
--001636c923755933ee0494329ca4--