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 226B9D6BA for ; Fri, 13 Jul 2012 15:43:49 +0000 (UTC) Received: (qmail 55988 invoked by uid 500); 13 Jul 2012 15:43:47 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 55311 invoked by uid 500); 13 Jul 2012 15:43:43 -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 54709 invoked by uid 99); 13 Jul 2012 15:43:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2012 15:43:41 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.160.172] (HELO mail-gh0-f172.google.com) (209.85.160.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2012 15:43:36 +0000 Received: by ghbg16 with SMTP id g16so4050076ghb.31 for ; Fri, 13 Jul 2012 08:43:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=fIjETuV/WXf0ldeCJMgeUVvf4ARJsTtkxFcv2YQX0ec=; b=iaZJFL8rt4g13ioD2+TEq1xP5iQ3NWUZkvjJjXHORSQfYqV7pcG9DfE/E3rGrLjbgx a7/gs9ZM9wdxQW4C81d8hLri4QrDauZhGcTsabYKCIhkCnVHM3gs9PXBb7LSw1v1tnN+ UCP3vrvSP5rua+cAVzQqNIH9oO6oV9zkqty+SWoXRiU08Xn3tKxcZJI2Yjn9XIgyLUDG UKrBuNvyAOaJ7YM+xGHDYFxt0OYmB7VJAsuIu86fCwCi3I2eTrj1rE58OnOzAawy6PVN yZDKtGm6BOkyFOK5rkmkU0U562KS4rTNvzFYHGF36LbV4sHwuLIsd5EN/l43oLWDmCTG IGmw== MIME-Version: 1.0 Received: by 10.101.176.19 with SMTP id d19mr485990anp.38.1342194195083; Fri, 13 Jul 2012 08:43:15 -0700 (PDT) Received: by 10.146.57.40 with HTTP; Fri, 13 Jul 2012 08:43:15 -0700 (PDT) X-Originating-IP: [208.80.67.68] Received: by 10.146.57.40 with HTTP; Fri, 13 Jul 2012 08:43:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jul 2012 08:43:15 -0700 Message-ID: Subject: Re: How to speed up data loading From: Tupshin Harper To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001636c5bed837b0e204c4b7f00b X-Gm-Message-State: ALoCoQlIPhamZjB69cOGdmna0g85gXD3U3MIcl8SJEladF/nbk56C0eRibey3ZeizguPeLYg99OV X-Virus-Checked: Checked by ClamAV on apache.org --001636c5bed837b0e204c4b7f00b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Any chance your server has been running for the last two weeks with the leap second bug? http://www.datastax.com/dev/blog/linux-cassandra-and-saturdays-leap-second-= problem -Tupshin On Jul 12, 2012 1:43 PM, "Leonid Ilyevsky" wrote: > I am loading a large set of data into a CF with composite key. The load > is going pretty slow, hundreds or even thousands times slower than it wou= ld > do in RDBMS.**** > > I have a choice of how granular my physical key (the first component of > the primary key) is, this way I can balance between smaller rows and too > many keys vs. wide rows and fewer keys. What are the guidelines about thi= s? > How the width of the physical row affects the speed of load?**** > > ** ** > > I see that Cassandra is doing a lot of processing behind the scene, even > when I kill the client, the server is still consuming a lot of CPU for a > long time.**** > > ** ** > > What else should I look at ? Anything in configuration? **** > > ------------------------------ > This email, along with any attachments, is confidential and may be legall= y > privileged or otherwise protected from disclosure. Any unauthorized > dissemination, copying or use of the contents of this email is strictly > prohibited and may be in violation of law. If you are not the intended > recipient, any disclosure, copying, forwarding or distribution of this > email is strictly prohibited and this email and any attachments should be > deleted immediately. This email and any attachments do not constitute an > offer to sell or a solicitation of an offer to purchase any interest in a= ny > investment vehicle sponsored by Moon Capital Management LP (=93Moon > Capital=94). Moon Capital does not provide legal, accounting or tax advic= e. > Any statement regarding legal, accounting or tax matters was not intended > or written to be relied upon by any person as advice. Moon Capital does n= ot > waive confidentiality or privilege as a result of this email. > --001636c5bed837b0e204c4b7f00b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Any chance your server has been running for the last two weeks with the = leap second bug?
http://www.datastax.com/dev/blog/linux-cassandra-and-sa= turdays-leap-second-problem

-Tupshin

On Jul 12, 2012 1:43 PM, "Leonid Ilyevsky&q= uot; <lilyevsky@mooncapital= .com> wrote:

I am loading a large set = of data into a CF with composite key. The load is going pretty slow, hundre= ds or even thousands times slower than it would do in RDBMS.

I have a choice of how gr= anular my physical key (the first component of the primary key) is, this wa= y I can balance between smaller rows and too many keys vs. wide rows and fewer keys. What are the guidelines about this? How the = width of the physical row affects the speed of load?

=A0<= /p>

I see that Cassandra is d= oing a lot of processing behind the scene, even when I kill the client, the= server is still consuming a lot of CPU for a long time.

=A0<= /p>

What else should I look a= t ? Anything in configuration?


This email, along with any a= ttachments, is confidential and may be legally privileged or otherwise prot= ected from disclosure. Any unauthorized dissemination, copying or use of th= e contents of this email is strictly prohibited and may be in violation of law. If you are not the intended recipient, any= disclosure, copying, forwarding or distribution of this email is strictly = prohibited and this email and any attachments should be deleted immediately= . This email and any attachments do not constitute an offer to sell or a solicitation of an offer to purcha= se any interest in any investment vehicle sponsored by Moon Capital Managem= ent LP (=93Moon Capital=94). Moon Capital does not provide legal, accountin= g or tax advice. Any statement regarding legal, accounting or tax matters was not intended or written to be relied = upon by any person as advice. Moon Capital does not waive confidentiality o= r privilege as a result of this email.
--001636c5bed837b0e204c4b7f00b--