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 A5F1C115C5 for ; Wed, 2 Apr 2014 06:13:05 +0000 (UTC) Received: (qmail 79637 invoked by uid 500); 2 Apr 2014 06:13:02 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 79067 invoked by uid 500); 2 Apr 2014 06:13:01 -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 79058 invoked by uid 99); 2 Apr 2014 06:12:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Apr 2014 06:12:58 +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 apoorva.gaurav@myntra.com designates 209.85.223.170 as permitted sender) Received: from [209.85.223.170] (HELO mail-ie0-f170.google.com) (209.85.223.170) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Apr 2014 06:12:53 +0000 Received: by mail-ie0-f170.google.com with SMTP id rd18so10308324iec.15 for ; Tue, 01 Apr 2014 23:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myntra.com; s=myntra; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=6332x5tvOASbrJksfKCgAeR6P9XuyAkwdv/91GROlq4=; b=eefUJJAo6d8Ljr+6FZMmi1jtWelxqA3zTJ9MYyEJQUZins6H6wIJeoWPO5puB15/FC OpG/Gd+jh2pfbgfFDGPuSFF3WD1C7JlxKWVPWquM4aaJpy+CAN1igmtNzxtMsicuUd7F QmLWmRvCyiOeLy0V+KeEm4cyU83aAZ94UwtMw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=6332x5tvOASbrJksfKCgAeR6P9XuyAkwdv/91GROlq4=; b=e23eU+TI/gc7txfPu3ZP7+39TzRSn0tn+c8GbS7d5IwbhsV99ktxNe1UQzdzJ5zrbK +I1HWT3N5PfggEWlctgskczpV0ZDmkJ06+sCWdBe/M9VXmermuvSwFizAChTPAj2ezEM l8oCveLf0mEU+z8xu4nIcu5ll1sa/wid43o0A3gjJPOK5FtuvlLWFWiYSwOD3sXAOE9A t2Tx6TzgAVAHjUNPuPzBa+TATH6r480InLzLTzpzX4WAt8BVpZkX20SyGLmLoLEutV/n p/819w4EI3De+OK2zBsJ4vStpLZZ3HnDtCKR51K2+SH4II1dNAMRAII5brzrkWDmwX0K FRxg== X-Gm-Message-State: ALoCoQl6FvmlaXuilgp39bO+UmuDADQReuwRr6DKCVuMgMY4Y+ZvsYAgNtkABllnuMDJF2oWlBDQ X-Received: by 10.42.121.147 with SMTP id j19mr45676348icr.13.1396419151637; Tue, 01 Apr 2014 23:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.223.20 with HTTP; Tue, 1 Apr 2014 23:12:11 -0700 (PDT) In-Reply-To: References: From: Apoorva Gaurav Date: Wed, 2 Apr 2014 11:42:11 +0530 Message-ID: Subject: Re: Read performance in map data type To: user Content-Type: multipart/alternative; boundary=20cf301b67e97dc9d904f6092b81 X-Virus-Checked: Checked by ClamAV on apache.org --20cf301b67e97dc9d904f6092b81 Content-Type: text/plain; charset=ISO-8859-1 I've observed that reducing fetch size results in better latency (isn't that obvious :-)), tried from fetch size varying from 100 to 10000, seeing a lot of errors for 10000. Haven't tried modifying the number of columns. Let me start a new thread focused on fetch size. On Wed, Apr 2, 2014 at 9:53 AM, Sourabh Agrawal wrote: > From the doc : The fetch size controls how much resulting rows will be > retrieved simultaneously. > So, I guess it does not depend on the number of columns as such. As all > the columns for a key reside on the same node, I think it wouldn't matter > much whatever be the number of columns as long as we have enough memory in > the app. > > Default value is 5000. (com.datastax.driver.core.QueryOptions) > > We use it with the default value. I have never profiled cassandra for read > load. If you profile it for different fetch sizes, please share the results > :) > > > On Wed, Apr 2, 2014 at 8:45 AM, Apoorva Gaurav wrote: > >> Thanks Sourabh, >> >> I've modelled my table as "studentID int, subjectID int, marks int, >> PRIMARY KEY(studentID, subjectID)" as primarily I'll be querying using >> studentID and sometime using studentID and subjectID. >> >> I've tried driver 2.0.0 and its giving good results. Also using its auto >> paging feature. Any idea what should be a typical value for fetch size. And >> does the fetch size depends on how many columns are there in the CQL table >> for e.g. should fetch size in a table like "studentID int, subjectID >> int, marks1 int, marks2 int, marks3 int.... marksN int PRIMARY >> KEY(studentID, subjectID)" be less than fetch size in "studentID int, >> subjectID int, marks int, PRIMARY KEY(studentID, subjectID)" >> >> >> On Wed, Apr 2, 2014 at 2:20 AM, Robert Coli wrote: >> >>> On Mon, Mar 31, 2014 at 9:13 PM, Apoorva Gaurav < >>> apoorva.gaurav@myntra.com> wrote: >>> >>>> Thanks Robert, Is there a workaround, as in our test setups we keep >>>> dropping and recreating tables. >>>> >>> >>> Use unique keyspace (or table) names for each test? That's the approach >>> they're taking in 5202... >>> >>> =Rob >>> >>> >> >> >> -- >> Thanks & Regards, >> Apoorva >> > > > > -- > Sourabh Agrawal > Bangalore > +91 9945657973 > -- Thanks & Regards, Apoorva --20cf301b67e97dc9d904f6092b81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've observed that reducing fetch size results in bett= er latency (isn't that obvious :-)), tried from fetch size varying from= 100 to 10000, seeing a lot of errors for 10000. Haven't tried modifyin= g the number of columns.=A0

Let me start a new thread focused on fetch size.


On Wed, Apr 2, 2014 at = 9:53 AM, Sourabh Agrawal <iitr.sourabh@gmail.com> wrote= :
From the doc : The fetch si= ze controls how much resulting rows will be retrieved simultaneously.=A0So, I guess it does not depend on the number of columns as such. As all t= he columns for a key reside on the same node, I think it wouldn't matte= r much whatever be the number of columns as long as we have enough memory i= n the app.

Default value is 5000. (com.datastax.driver.core.QueryO= ptions)

We use it with the default value. I have n= ever profiled cassandra for read load. If you profile it for different fetc= h sizes, please share the results :)


On Wed, Apr 2, 2014 at 8:45 AM, Apoorva Gaurav <apoorva.gaurav@= myntra.com> wrote:
Thanks Sourabh,

I've modelled my table as=A0"studentID int, subjectID int, marks int, PRIMARY KEY(stude= ntID, subjectID)" as primarily I'll be querying using studentID an= d sometime using studentID and subjectID.

I've tried driver 2.0.0 and its giving good results. Also u= sing its auto paging feature. Any idea what should be a typical value for f= etch size. And does the fetch size depends on how many columns are there in= the CQL table for e.g. should fetch size in a table like=A0"studentID int, subjectID int, ma= rks1 int, marks2 int, marks3 int.... marksN int PRIMARY KEY(studentID, subj= ectID)" be less than fetch size in=A0"studentID int, subjectID int, marks int, PR= IMARY KEY(studentID, subjectID)"


On Wed, Apr 2, 2014 at 2:20 AM, Robert Coli <rcol= i@eventbrite.com> wrote:
=A0On Mon, Mar 31, 201= 4 at 9:13 PM, Apoorva Gaurav <apoorva.gaurav@myntra.com> wrote:
Thanks Robert, Is there a w= orkaround, as in our test setups we keep dropping and recreating tables.

Use unique keyspace (or table) names= for each test? That's the approach they're taking in 5202...
=
=A0=A0
=3DRob




--=
Thanks & Regards,
Apoorva



--=
Sourabh Agrawal
Bangalore
+91 994565797= 3



--
Thanks &= Regards,
Apoorva
--20cf301b67e97dc9d904f6092b81--