Great ! Thanks for the link.
On 07. 08. 11 10:10, aaron morton wrote:
Wider rows may need to run through the slower 2-phase compaction
process, see in_memory_compaction_limit_in_mb in the yaml file. They
can also result in more GC, depending on work load etc.
Some testing I did on query per
Wider rows may need to run through the slower 2-phase compaction process, see
in_memory_compaction_limit_in_mb in the yaml file. They can also result in more
GC, depending on work load etc.
Some testing I did on query performance
http://thelastpickle.com/2011/07/04/Cassandra-Query-Plans/
Ther
Thanks for your advise. Make sense.
And without sticking to my dummy example, conceptually, what has a
smaller memory footprint : 1M rows of 1 column or 1 row with 1M columns ?
And if the row key and column name are known, is there any performance
difference between both scenarios ?
Thanks
The principle is, "keep data you retrieve at the same time, in the same row."
Here the logical unit to query is one user so I don't see any benefit
to forcing them into a single row "unnaturally."
On Thu, Aug 4, 2011 at 2:38 AM, Benoit Perroud wrote:
> Hi All,
>
> In a conceptual point of view,
Hi All,
In a conceptual point of view, I'm wondering what is the pros & cons,
mainly in term of access efficiency, of both approach :
- Grouping row keys together to reduce the number of keys, but having
wider rows (with more columns)
- One object in one row
Let's illustrate with an example :
I
