Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@accumulo.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1283)
Subject: Re: Number of partitions for sharded table
From: Krishmin Rai <krrai@missionfoc.us>
In-Reply-To: <4C975E4B-4EB5-4E96-95DA-E28E9BAF2424@missionfoc.us>
Date: Tue, 30 Oct 2012 15:28:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2BC540F-8246-4D46-B2E2-FBA2B69A2753@missionfoc.us>
References: <4C975E4B-4EB5-4E96-95DA-E28E9BAF2424@missionfoc.us>
To: user@accumulo.apache.org

I should clarify that I've been pre-splitting tables at each shard so =
that each tablet consists of a single row.

On Oct 30, 2012, at 3:06 PM, Krishmin Rai wrote:

> Hi All,=20
>  We're working with an index table whose row is a shardId (an integer, =
like the wiki-search or IndexedDoc examples). I was just wondering what =
the right strategy is for choosing a number of partitions, particularly =
given a cluster that could potentially grow.
>=20
>  If I simply set the number of shards equal to the number of slave =
nodes, additional nodes would not improve query performance (at least =
over the data already ingested). But starting with more partitions than =
slave nodes would result in multiple tablets per tablet server=85 I'm =
not really sure how that would impact performance, particularly given =
that all queries against the table will be batchscanners with an =
infinite range.
>=20
>  Just wondering how others have addressed this problem, and if there =
are any performance rules of thumb regarding the ratio of tablets to =
tablet servers.
>=20
> Thanks!
> Krishmin