Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Unable to fetch large amount of rows
From: aaron morton <aaron@thelastpickle.com>
In-Reply-To: <1C124BA2870F4EA1825B51273DE285FB@pune.wibhu.com>
Date: Tue, 19 Mar 2013 20:40:53 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A7C7E4C-1D9C-464B-BCD8-75EF3C3B32D4@thelastpickle.com>
References: <1C124BA2870F4EA1825B51273DE285FB@pune.wibhu.com>
To: user@cassandra.apache.org

>  I have 1000 timestamps, and for each timestamp, I have 500K different =
MACAddress.
So you are trying to read about 2 million columns ?=20
500K MACAddresses each with 3 other columns?=20

> When I run the following query, I get RPC Timeout exceptions:
What is the exception?=20
Is it a client side socket timeout or a server side TimedOutException ?

If my understanding is correct then try reading fewer columns and/or =
check the server side for logs. It sounds like you are trying to read =
too much though.=20

Cheers


-----------------
Aaron Morton
Freelance Cassandra Consultant
New Zealand

@aaronmorton
http://www.thelastpickle.com

On 19/03/2013, at 3:51 AM, Pushkar Prasad =
<pushkar.prasad@airtightnetworks.net> wrote:

> Hi,
> =20
> I have following schema:
> =20
> TimeStamp
> MACAddress
> Data Transfer
> Data Rate
> LocationID
> =20
> PKEY is (TimeStamp, MACAddress). That means partitioning is on =
TimeStamp, and data is ordered by MACAddress, and stored together =
physically (let me know if my understanding is wrong). I have 1000 =
timestamps, and for each timestamp, I have 500K different MACAddress.
> =20
> When I run the following query, I get RPC Timeout exceptions:
> =20
> =20
> Select * from db_table where Timestamp=3D=92=85..=92
> =20
> =46rom my understanding, this should give all the rows with just one =
disk seek, as all the records for a particular timeStamp. This should be =
very quick, however, clearly, that doesn=92t seem to be the case. Is =
there something I am missing here? Your help would be greatly =
appreciated.
> =20
> Thanks
> PP