From user-return-20528-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Tue Sep 6 16:34:21 2011 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5A73F707B for ; Tue, 6 Sep 2011 16:34:21 +0000 (UTC) Received: (qmail 99270 invoked by uid 500); 6 Sep 2011 16:34:19 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 99097 invoked by uid 500); 6 Sep 2011 16:34:18 -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 99089 invoked by uid 99); 6 Sep 2011 16:34:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Sep 2011 16:34:18 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [98.139.91.233] (HELO nm27-vm1.bullet.mail.sp2.yahoo.com) (98.139.91.233) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 06 Sep 2011 16:34:10 +0000 Received: from [98.139.91.69] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 06 Sep 2011 16:33:49 -0000 Received: from [98.139.91.6] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 06 Sep 2011 16:33:49 -0000 Received: from [127.0.0.1] by omp1006.mail.sp2.yahoo.com with NNFMP; 06 Sep 2011 16:33:49 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 606290.10348.bm@omp1006.mail.sp2.yahoo.com Received: (qmail 21924 invoked by uid 60001); 6 Sep 2011 16:33:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315326828; bh=bwn3V4kzxndPjIMH85OBqsHRizTt2ej6saycwUku3lw=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=6VCcYaozC9Ulr3QnBcdaG1bUBPgrwUJ1GfBGQ8wdX6vcYgpFMDrBGPr8uL17yQ6mDQIhC2f6erP16jNES489SOiLr2rJnVoYfUPe9txRd+Nx9/782/561ILtxZYouSBw7iiYa3Y3zsto9tcX92NZ+wE3Oz0afx08AkYYmnm6X5E= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=kIWBa3NbRqWQrXS+UbsfZzbKcpXyRWMoKXMqaMNJN8nq5T+9SD1LmVu1wL+41ssIhLP77g4Kj/ZKZmcPR8Pl40GWwd1n901Cz09IqmQXiRJcJLH3xF7h0xNNhbu0ePsbHBzg4NGbwRdCyRsDAT2+sme6U9dYGIm64Aybn0ei5bk=; X-YMail-OSG: yAiw12IVM1lyJ1aDyGMutHeTXXfjhdmtUdoT7DiUToaXiQX LRxhMEntRRy4KJAL6Ce1gL7yWWkaeX35iKvAs4eQN3gGWqfi6xHNc2j4p6Bx XVzicyv0JY9v0aBqe5VxKHQbzq0fv4ms6EhWqYNiRTVxGvOyXU67GpacyUY6 5Ls8Mec55ZC7NbKNIKRVmbpnJKaT_MtqPa0xo2_qHpG8uUTbVfp1UHDqmi8i lT.vWt82.UXQV02mrgOVhKyP1RNTx6Q5QbiVGryRe2W7OuKvAm4qkVyUkJeg olzCOdFmh56AizfsDGNAuO5NneibbeZbYtH_4fy6oOVllNPFuZ7hH9A0s.zH EqEuR6hPeByOKFIMGWK_EF2q2g08ounHwWA.n1zUXCuhxICYq5k3sOGAUMfg gJqSQiueE9bkoCOszCRty Received: from [119.158.64.210] by web45015.mail.sp1.yahoo.com via HTTP; Tue, 06 Sep 2011 09:33:48 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <1315006252.26001.YahooMailNeo@web45009.mail.sp1.yahoo.com> Message-ID: <1315326828.595.YahooMailNeo@web45015.mail.sp1.yahoo.com> Date: Tue, 6 Sep 2011 09:33:48 -0700 (PDT) From: China Stoffen Reply-To: China Stoffen Subject: Re: commodity server spec To: "user@cassandra.apache.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-178326422-1315326828=:595" --0-178326422-1315326828=:595 Content-Type: text/plain; charset=us-ascii >>In general, more smaller is better than fewer big. Probably go for >>what's cost-effective. Cost effective solution is few and fat servers because it also saves hosting cost. >>The exception to that would be if you're truly only caring about >>writes and have *very* few reads that are not latency critical (so >>you're okay with waiting for several disk seeks on reads and the >>number of reads is low enough that serving them from platters will >>work). In such cases it might make sense to have fewer Big Fat >>Machines with lots of memory and a lot of disk space. But... even so. >>I would not recommend huge 48 tb nodes... unless you really know what >>you're doing. I want writes should be as fast as possible but reads are not necessary to be in milliseconds. If you don't recommend 48tb then how much max disk space I can go with? ----- Original Message ----- From: Peter Schuller To: user@cassandra.apache.org; China Stoffen Cc: Sent: Saturday, September 3, 2011 1:08 PM Subject: Re: commodity server spec > Is there any recommendation about commodity server hardware specs if 100TB > database size is expected and its heavily write application. > Should I got with high powered CPU (12 cores) and 48TB HDD and 640GB RAM and > total of 3 servers of this spec. Or many smaller commodity servers are > recommended? In general, more smaller is better than fewer big. Probably go for what's cost-effective. In your case, 100 TB is *quite* big. I would definitely recommend against doing anything like your 3 server setup. You'll probably want 100-1000 small servers. The exception to that would be if you're truly only caring about writes and have *very* few reads that are not latency critical (so you're okay with waiting for several disk seeks on reads and the number of reads is low enough that serving them from platters will work). In such cases it might make sense to have fewer Big Fat Machines with lots of memory and a lot of disk space. But... even so. I would not recommend huge 48 tb nodes... unless you really know what you're doing. In reality, more information about your use-case would be required to offer terribly useful advice. -- / Peter Schuller (@scode on twitter) --0-178326422-1315326828=:595 Content-Type: text/html; charset=us-ascii
>>In general, more smaller is better than fewer big. Probably go for
>>what's cost-effective.

Cost effective solution is few and fat servers because it also saves hosting cost.


>>The exception to that would be if you're truly only caring about
>>writes and have *very* few reads that are not latency critical (so
>>you're okay with waiting for several disk seeks on reads and the
>>number of reads is low enough that serving them from platters will
>>work). In such cases it might make sense to have fewer Big Fat
>>Machines with lots of memory and a lot of disk space. But... even so.
>>I would not recommend huge 48 tb nodes... unless you really know what
>>you're doing.

I want writes should be as fast as possible but reads are not necessary to be in milliseconds.
If you don't recommend 48tb then how much max disk space I can go with?





----- Original Message -----
From: Peter Schuller <peter.schuller@infidyne.com>
To: user@cassandra.apache.org; China Stoffen <chinastoffen@yahoo.com>
Cc:
Sent: Saturday, September 3, 2011 1:08 PM
Subject: Re: commodity server spec

> Is there any recommendation about commodity server hardware specs if 100TB
> database size is expected and its heavily write application.
> Should I got with high powered CPU (12 cores) and 48TB HDD and 640GB RAM and
> total of 3 servers of this spec. Or many smaller commodity servers are
> recommended?

In general, more smaller is better than fewer big. Probably go for
what's cost-effective.

In your case, 100 TB is *quite* big. I would definitely recommend
against doing anything like your 3 server setup. You'll probably want
100-1000 small servers.

The exception to that would be if you're truly only caring about
writes and have *very* few reads that are not latency critical (so
you're okay with waiting for several disk seeks on reads and the
number of reads is low enough that serving them from platters will
work). In such cases it might make sense to have fewer Big Fat
Machines with lots of memory and a lot of disk space. But... even so.
I would not recommend huge 48 tb nodes... unless you really know what
you're doing.

In reality, more information about your use-case would be required to
offer terribly useful advice.

--
/ Peter Schuller (@scode on twitter)
--0-178326422-1315326828=:595--