Return-Path: Delivered-To: apmail-incubator-cassandra-dev-archive@minotaur.apache.org Received: (qmail 88068 invoked from network); 12 Mar 2010 07:58:24 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Mar 2010 07:58:24 -0000 Received: (qmail 12545 invoked by uid 500); 12 Mar 2010 07:57:48 -0000 Delivered-To: apmail-incubator-cassandra-dev-archive@incubator.apache.org Received: (qmail 12337 invoked by uid 500); 12 Mar 2010 07:57:45 -0000 Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-dev@incubator.apache.org Delivered-To: mailing list cassandra-dev@incubator.apache.org Received: (qmail 12329 invoked by uid 99); 12 Mar 2010 07:57:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Mar 2010 07:57:44 +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 (athena.apache.org: domain of masoodmortazavi@gmail.com designates 209.85.222.185 as permitted sender) Received: from [209.85.222.185] (HELO mail-pz0-f185.google.com) (209.85.222.185) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Mar 2010 07:57:39 +0000 Received: by pzk15 with SMTP id 15so549051pzk.21 for ; Thu, 11 Mar 2010 23:57:19 -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=D+e8LfCzaCfsWTk/WkYj0GkFHKu2WC/QWv6pYih4U2o=; b=qW1wkyYxhf2+5mptX65kE89tich9r1KAPPH/J/7+GOK26v/bYRHoBq6XHpSg05nCoA mqXiDiE9UBZ0KgCdkKuxIshyzC82iVcARQnkt3pyr9it0WCff6flMQ1K8T9AVloKKVgK yQl/rt+1Z1ndmqR1m92axvJ9WNlrmZGGrrgCE= 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=b6GZwfjuVb6RPMx/Rp3C+nYwiG2+pehLFXiGTIUFIUmOQ9nsmruJqNvYyeXpMtgZi5 IbgAnqiDcs4E95FvV9r7EmXrrC0UfpGW/gkSJnZZ3U/RMIJ5tDmMPo2CMe60k+suaawG 0Tc02Fl4Zz8cKGu897u0ST8tEPO2rMNd0TDL4= MIME-Version: 1.0 Received: by 10.140.251.8 with SMTP id y8mr2596917rvh.144.1268380639311; Thu, 11 Mar 2010 23:57:19 -0800 (PST) In-Reply-To: <201003121336073026052@gmail.com> References: <201003121336073026052@gmail.com> Date: Fri, 12 Mar 2010 15:57:18 +0800 Message-ID: Subject: Re: wo did some test on cassandra ,but the result puzzled us From: Masood Mortazavi To: cassandra-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=000e0cd17fa672368b048195e1af --000e0cd17fa672368b048195e1af Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bingbing Liu, On Fri, Mar 12, 2010 at 1:36 PM, Bingbing Liu wrote: > We did some test on on Cassandra, and the benchmark is from Section 7 of > the BigTable paper =93Bigtable: A Distributed Storage System for Structur= ed > Data=94, the benchmark task includes: random write, random read, sequenti= al > write, and sequential read. The test results made us puzzled. We use a > cluster of 5 nodes (each node has a 4 cores cpu , 4G memory).The data for > test is a table with 4,000,000 records each of which is 1000 bytes. The > test results are as follows: > Sequential write: 875124 ms > Sequential read: 1972588 ms > Random read: 43331738 ms > Random write: 20193484 ms > We wondered why the speed of sequential write are so faster than the spee= d > of sequential read, and why the speed of sequential write are so faster t= han > that of random write? We think that the speed of read should be faster th= an > that of data write, but the results are just the opposite, would you plea= se > give us some explanations, thanks a lot! > Please read the BigTable paper, carefully, again. They have similar characteristics and describe why this is the case. I thin= k you'll find that behavior you observed is quite consistent with the theory of it all (and reading the text to which Jonathan has pointed you, will essentially give you the same reasons). It is part and parcel of the storage architecture of "BigTable" type systems. - m. --000e0cd17fa672368b048195e1af--