Return-Path: 
 <user-return-40005-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
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 7B97C10814
	for <apmail-cassandra-user-archive@www.apache.org>;
 Mon,  7 Apr 2014 12:53:07 +0000 (UTC)
Received: (qmail 53463 invoked by uid 500); 7 Apr 2014 12:53:05 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 52690 invoked by uid 500); 7 Apr 2014 12:53:03 -0000
Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@cassandra.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@cassandra.apache.org>
List-Post: <mailto:user@cassandra.apache.org>
List-Id: <user.cassandra.apache.org>
Reply-To: user@cassandra.apache.org
Delivered-To: mailing list user@cassandra.apache.org
Received: (qmail 52647 invoked by uid 99); 7 Apr 2014 12:53:00 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2014 12:53:00 +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: apache.org
Received-SPF: pass (nike.apache.org: domain of cassandra.daks@gmail.com
 designates 209.85.213.196 as permitted sender)
Received: from [209.85.213.196] (HELO mail-ig0-f196.google.com)
 (209.85.213.196)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2014 12:52:54 +0000
Received: by mail-ig0-f196.google.com with SMTP id c1so962635igq.7
        for <user@cassandra.apache.org>; Mon, 07 Apr 2014 05:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:date:message-id:subject:from:to:content-type;
        bh=3kzd6q+V2PXprIrx7MOjIoDBhWedkRMsYm/LXsSd4bc=;
        b=ZVDN7XJ7ijCN3c5ULh3pYZbr08gpSLiV3Fdr0QQOjE9Y29TYIYcM1PsMcrLIHgs8LX
         1sycZGxe/5OaqIvl9sy9ulBwCw//bH9Sg3OEhZ6/eE2Q6dUpHKQYwPKqrk2sI8nFBDcA
         NBpIxwfxy8dTr+wPJc3jJNawz2Xh1xc52rqj9rjBlYXW7apAy5mi9WA/ZK5cGdXOQCVH
         lt2ksFx75vcGBMfYGV8uAoRn5+382N63vdofUhR8O6ORiH8XyuFitXcyE+b88afLz3Nb
         3ftdTN674C/NKvaUuAOWZ6tAhpu6fPNyT8tjSJKzlXTwGMbnOuW2BBHsOdtHvTksGuB/
         yTDw==
MIME-Version: 1.0
X-Received: by 10.43.138.8 with SMTP id iq8mr26272890icc.37.1396875152443;
 Mon, 07 Apr 2014 05:52:32 -0700 (PDT)
Received: by 10.64.70.34 with HTTP; Mon, 7 Apr 2014 05:52:32 -0700 (PDT)
Date: Mon, 7 Apr 2014 14:52:32 +0200
Message-ID: 
 <CALLRBxRf+UCiz1rgauazfUtxymB05m5suGOQgtch=2ox95Pi6w@mail.gmail.com>
Subject: Inserting with large number of column
From: Fasika Daksa <cassandra.daks@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=001a11c2036441cf5904f673576f
X-Virus-Checked: Checked by ClamAV on apache.org

--001a11c2036441cf5904f673576f
Content-Type: text/plain; charset=ISO-8859-1

We are running different workload test on Cassandra and Redis for
benchmarking. We wrote a java client to read, write and evaluate the
elapsed time of different test cases. Cassandra was doing great until we
introduced 20'000 number of cols...... the insertion is running for a day
and then i stopped it.

First I create the table, index all the columns then insert the data. I
looked in to the process and the part it is taking too long is the indexing
part. We need to index all the columns because we use all or part of the
columns depending on the query generator.


Can you see a potential solution for my case? Is there any way to optimize
the indexing?....or generally the insertion? I also tried indexing after
insertion but it is all the same.


we are running this experiment on a single machine with 196GB of ram ...
1.6 TB of disk space and 8core CPU...

cqlsh 4.1.0 | Cassandra 2.0.3

--001a11c2036441cf5904f673576f
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><p class="MsoNormal">We are running different workload test on Cassandra and Redis
for benchmarking. We wrote a java client to read, write and evaluate the
elapsed time of different test cases. Cassandra was doing great until we introduced 20&rsquo;000 number of cols...... the insertion is running for a day and then i stopped it. </p>

<p class="MsoNormal">First I create the table, index all the columns then insert
the data. I looked in to the process and the part it is taking too long is the
indexing part. We need to index all the columns because we use all or part of the
columns depending on the query generator. </p><p class="MsoNormal"><br></p>

<p class="MsoNormal">Can you see a potential solution for my case? Is there any way
to optimize the indexing?&hellip;.or generally the insertion? I also tried indexing
after insertion but it is all the same.</p><p class="MsoNormal"><br></p><p class="MsoNormal">we are running this experiment on a single machine with 196GB of ram ... 1.6 TB of disk space and 8core CPU...</p><p class="MsoNormal">
cqlsh 4.1.0 | Cassandra 2.0.3&nbsp;</p></div>

--001a11c2036441cf5904f673576f--