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 3C21918FD2 for ; Sat, 23 Jan 2016 05:00:34 +0000 (UTC) Received: (qmail 41431 invoked by uid 500); 23 Jan 2016 05:00:31 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 41374 invoked by uid 500); 23 Jan 2016 05:00:31 -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 41364 invoked by uid 99); 23 Jan 2016 05:00:31 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Jan 2016 05:00:31 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 9F0D4C0EC3 for ; Sat, 23 Jan 2016 05:00:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.151 X-Spam-Level: *** X-Spam-Status: No, score=3.151 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, HTML_MESSAGE=3, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.in Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id iffkdptWEvtW for ; Sat, 23 Jan 2016 05:00:21 +0000 (UTC) Received: from nm29-vm4.bullet.mail.sg3.yahoo.com (nm29-vm4.bullet.mail.sg3.yahoo.com [106.10.151.163]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 55097215D6 for ; Sat, 23 Jan 2016 05:00:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s2048; t=1453525212; bh=NtSfUNCc9zhBmQBXhWrTmPfgA4taF4w3VWvFBeVujok=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=G2fjtASgYLolytORxxclv+SwjgufOL/SBgL/rqCyZvgt2b3ZwAI2OtrhdtEAk3B4uN8/f+njYF0k3kBinljltTfzILvgQzz+6b/cS/HNBHrXEMgPWFWR3E1ga9R4mR9hITyx/KdjRDQ/eZCpyBu+YCz5045hM9oPrUUeGuWnNMct5rUjDqaUFeGdTTndcNvYrEuRim60G8BSzlUe1KbZoxXpE4KnxuGkASIjBnJsWY3qAfE681gbq4TKDkAxNuK++ZQnqviNzSorAR9EyKiL5wHc1MlygHnxfugv6R/xPUDrXf4Q3hOHpdYk57SBvTGdAwNb93gpw6anfzY+Inmz3Q== Received: from [106.10.166.63] by nm29.bullet.mail.sg3.yahoo.com with NNFMP; 23 Jan 2016 05:00:12 -0000 Received: from [106.10.151.235] by tm20.bullet.mail.sg3.yahoo.com with NNFMP; 23 Jan 2016 05:00:12 -0000 Received: from [127.0.0.1] by omp1019.mail.sg3.yahoo.com with NNFMP; 23 Jan 2016 05:00:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 275633.53287.bm@omp1019.mail.sg3.yahoo.com Received: by 106.10.196.89; Sat, 23 Jan 2016 05:00:11 +0000 Date: Sat, 23 Jan 2016 05:00:10 +0000 (UTC) From: Anuj Wadehra To: "user@cassandra.apache.org" Message-ID: <910120895.74622.1453525210814.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: Production with Single Node MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_74621_1298963276.1453525210801" ------=_Part_74621_1298963276.1453525210801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think Jonathan said it earlier. You may be happy with the performance for= now as you are using the same commitlog settings that you use in large clu= sters. Test the new setting recommended so that you know the real picture. = Or be prepared to lose some data in case of failure. Other than durability, you single node cluster would be Single Point of Fai= lure for your site. RAID 5 will only protect you against a disk failure. Bu= t a server may be down for other reasons too. Question is :Are you ok with = site going down? I would suggest you to use hardware with smaller configuration to save on c= ost for smaller sites and go ahead with a 3 node minimum.That ways you will= provide all the good features of your design irrespective of the site. Cas= sandra is known to work on commodity servers too.=C2=A0 ThanksAnuj Sent from Yahoo Mail on Android=20 =20 On Sat, 23 Jan, 2016 at 4:23 am, Jack Krupansky= wrote: You do of course have the simple technical matters, most of which= need to be addressed with a proof of concept implementation, related to me= mory, storage, latency, and throughput. I mean, with a scaled cluster you c= an always add nodes to increase capacity and throughput, and reduce latency= , but with a single node you have limited flexibility. Just to be clear, Cassandra is still not recommended for "fat nodes" - even= if you can fit tons of data on the node, you may not have the computes to = satisfy throughput and latency requirements. And if you don't have enough s= ystem memory the amount of storage is irrelevant. Back to my original question:How much data (rows, columns), what kind of lo= ad pattern (heavy write, heavy update, heavy query), and what types of quer= ies (primary key-only, slices, filtering, secondary indexes, etc.)? I do recall a customer who ran into problems because they had SSD but only = a very limited amount so they were running out of storage. Having enough sy= stem memory for file system caching and offheap data is important as well. -- Jack Krupansky On Fri, Jan 22, 2016 at 5:07 PM, John Lammers wrote: Thanks for your response Jack. We are already sold on distributed databases, HA and scaling.=C2=A0 We just= have some small deployments coming up where there's no money for servers t= o run multiple Cassandra nodes. So, aside from the lack of HA, I'm asking if a single Cassandra node would = be viable in a production environment. =C2=A0(There would be RAID 5 and the= RAID controller cache is backed by flash memory). I'm asking because I'm concerned about using Cassandra in a way that it's n= ot designed for.=C2=A0 That to me is the unsettling aspect. If this is a bad idea, give me the ammo I need to shoot it down.=C2=A0 I ne= ed specific technical reasons. Thanks! --John On Fri, Jan 22, 2016 at 4:47 PM, Jack Krupansky = wrote: Is single-node Cassandra has the performance (and capacity) you need and th= e NoSQL data model and API are sufficient for your app, and your dev and op= s and support teams are already familiar with and committed to Cassandra, a= nd you don't need HA or scaling, then it sounds like you are set. You asked about risks, and normally lack of HA and scaling are unacceptable= risks when people are looking at distributed databases. Most people on this list are dedicated to and passionate about distributed = databases, HA, and scaling, so it is distinctly unsettling when somebody co= mes along who isn't interested in and committed to those same three qualiti= es. But if single-node happens to work for you, then that's great. -- Jack Krupansky =20 ------=_Part_74621_1298963276.1453525210801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think Jonathan said it earlier. You may be happy with the performance for= now as you are using the same commitlog settings that you use in large clu= sters. Test the new setting recommended so that you know the real picture. = Or be prepared to lose some data in case of failure.

Other than durability, you single node cluster = would be Single Point of Failure for your site. RAID 5 will only protect yo= u against a disk failure. But a server may be down for other reasons too. Q= uestion is :Are you ok with site going down?

I would suggest you to use hardware with smaller = configuration to save on cost for smaller sites and go ahead with a 3 node = minimum.That ways you will provide all the good features of your design irr= espective of the site. Cassandra is known to work on commodity servers too.=  

<= /div>


Thanks
Anuj





On Sat, 23 Jan, 2016 at 4:23 am, Jack Krupansky
<jack.krupansky@gmail.com> wrote:
You do of course have the simple technical matters,= most of which need to be addressed with a proof of concept implementation,= related to memory, storage, latency, and throughput. I mean, with a scaled= cluster you can always add nodes to increase capacity and throughput, and = reduce latency, but with a single node you have limited flexibility.
Just to be clear, Cassandra is still not recomm= ended for "fat nodes" - even if you can fit tons of data on the node, you m= ay not have the computes to satisfy throughput and latency requirements. An= d if you don't have enough system memory the amount of storage is irrelevan= t.

Back to my original question:
How much data (rows, columns), wh= at kind of load pattern (heavy write, heavy update, heavy query), and what = types of queries (primary key-only, slices, filtering, secondary indexes, e= tc.)?

I d= o recall a customer who ran into problems because they had SSD but only a v= ery limited amount so they were running out of storage. Having enough syste= m memory for file system caching and offheap data is important as well.

-- Jack= Krupansky

On Fri, Jan 22, 2016 at 5:07 PM, John Lammers <john= .lammers@karoshealth.com> wrote:
Thanks for your response Jack.
<= br clear=3D"none">
We are already sold on distributed databases, = HA and scaling.  We just have some small deployments coming up where t= here's no money for servers to run multiple Cassandra nodes.

So, aside from the lack of HA, I'm asking if a si= ngle Cassandra node would be viable in a production environment.  (The= re would be RAID 5 and the RAID controller cache is backed by flash memory)= .

I'm asking because I'm concerned = about using Cassandra in a way that it's not designed for.  That to me= is the unsettling aspect.

If this = is a bad idea, give me the ammo I need to shoot it down.  I need speci= fic technical reasons.

Thanks!

--John

On Fri, Jan = 22, 2016 at 4:47 PM, Jack Krupansky <jack.krupansky@gmail.com> wro= te:
Is s= ingle-node Cassandra has the performance (and capacity) you need and the No= SQL data model and API are sufficient for your app, and your dev and ops an= d support teams are already familiar with and committed to Cassandra, and y= ou don't need HA or scaling, then it sounds like you are set.

You asked about risks, and normally lack of HA and sca= ling are unacceptable risks when people are looking at distributed database= s.

Most people on this list are ded= icated to and passionate about distributed databases, HA, and scaling, so i= t is distinctly unsettling when somebody comes along who isn't interested i= n and committed to those same three qualities. But if single-node happens t= o work for you, then that's great.

-- Jack Krupansky


------=_Part_74621_1298963276.1453525210801--