You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Cyril Auburtin <cy...@gmail.com> on 2012/06/18 19:18:39 UTC
large Rows Vs multinodes ring
In what extent, having possibly large rows, (many columns (sorted as
timeststamp, or geohash or ...) will be nefast for a muli-node ring.
I guess a row can be read/write just on one node, if yes it's more likely
to fail, (than having one row per timestamp ..)
thanks for explanations
Re: large Rows Vs multinodes ring
Posted by Cyril Auburtin <cy...@gmail.com>.
ok so it would be better to cut those large rows, inserting rows with row+
monthId, or row+week, and then all the corresponding columns inside, it
will drastically reduce rows size, but to retrieve results overlapping
between weeks or month, I have to to a multiget, less simple than a get
thx for answer
2012/6/18 aaron morton <aa...@thelastpickle.com>
> It's not an exact science. Some general guidelines though:
>
> * A row normally represents an entity
> * Rows wider than the thrift_max_message_length_in_mb (16MB) cannot be
> retrieved in a single call
> * Wide rows (in the 10's of MB) become can make repair do more work than
> is needed.
> * Rows wider than in_memory_compaction_limit_in_mb (64) make compaction
> run slower
>
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 19/06/2012, at 5:18 AM, Cyril Auburtin wrote:
>
> In what extent, having possibly large rows, (many columns (sorted as
> timeststamp, or geohash or ...) will be nefast for a muli-node ring.
> I guess a row can be read/write just on one node, if yes it's more likely
> to fail, (than having one row per timestamp ..)
>
> thanks for explanations
>
>
>
Re: large Rows Vs multinodes ring
Posted by aaron morton <aa...@thelastpickle.com>.
It's not an exact science. Some general guidelines though:
* A row normally represents an entity
* Rows wider than the thrift_max_message_length_in_mb (16MB) cannot be retrieved in a single call
* Wide rows (in the 10's of MB) become can make repair do more work than is needed.
* Rows wider than in_memory_compaction_limit_in_mb (64) make compaction run slower
Cheers
-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 19/06/2012, at 5:18 AM, Cyril Auburtin wrote:
> In what extent, having possibly large rows, (many columns (sorted as timeststamp, or geohash or ...) will be nefast for a muli-node ring.
> I guess a row can be read/write just on one node, if yes it's more likely to fail, (than having one row per timestamp ..)
>
> thanks for explanations