If your summary data is frequently accessed, you will probably be best off
storing the two sets of data separately (either in separate column families
or with different key-prefixes). This will give you the greatest
cache-locality for your summary data, which you say is popular. If your
summary dat
By higher level data I meant the common data.
For example we plan on creating an index using Solr for search but as its
lucene based you can store the common data as part of a Document. It won't be
indexed but is still accessible as the document will share the same "id" as the
row key.
Sent f
Aditya,
Have you done any benchmarking where you are specifically having read problems?
I will be surprised if using a technique described, you won't be able
to get the performance you are looking for.
Zach
On Sat, Oct 29, 2011 at 3:35 PM, Aditya Narayan wrote:
> Thanks Zach, Nice Idea !
>
> a
Thanks Zach, Nice Idea !
and what about looking at, may be, some custom caching solutions, leaving
aside cassandra caching .. ?
On Sun, Oct 30, 2011 at 2:00 AM, Zach Richardson <
j.zach.richard...@gmail.com> wrote:
> Aditya,
>
> Depending on how often you have to write to the database, you c
Aditya,
Depending on how often you have to write to the database, you could
perform dual writes to two different column families, one that has
summary + details in it, and one that only has the summary.
This way you can get everything with one query, or the summary with
one query, this should als
On Sat, Oct 29, 2011 at 11:23 AM, Aditya Narayan wrote:
> @Mohit:
> I have stated the example scenarios in my first post under this heading.
> Also I have stated above why I want to split that data in two rows & like
> Ikeda below stated, I'm too trying out to prevent the frequently accessed
> row
@Mohit:
I have stated the example scenarios in my first post under this heading.
Also I have stated above why I want to split that data in two rows & like
Ikeda below stated, I'm too trying out to prevent the frequently accessed
rows being bloated with large data & want to prevent that data from en
Okay so as most know this practice is called a wide row - we use them quite a
lot. However, as your schema shows it will cache (while being active) all the
row in memory. One way we got around this issue was to basically create some
materialized views of any more common data so we can easily ge
Yes you need 2 queries but a better schema design. I think you might
be trying to optimize where it actually will not give you any gain
except few lines of less code. Can you give an example of what you are
trying to do?
Other question why not store in within the same row?
On Sat, Oct 29, 2011 at
..so that I can retrieve them through a single query.
For reading cols from two CFs you need two queries, right ?
On Sat, Oct 29, 2011 at 9:53 PM, Mohit Anchlia wrote:
> Why not use 2 CFs?
>
> On Fri, Oct 28, 2011 at 9:42 PM, Aditya Narayan wrote:
> > I need to keep the data of some entities
Why not use 2 CFs?
On Fri, Oct 28, 2011 at 9:42 PM, Aditya Narayan wrote:
> I need to keep the data of some entities in a single CF but split in two
> rows for each entity. One row contains an overview information for the
> entity & another row contains detailed information about entity. I am
> w
I need to keep the data of some entities in a single CF but split in two
rows for each entity. One row contains an overview information for the
entity & another row contains detailed information about entity. I am
wanting to keep both rows in single CF so they may be retrieved in a single
query whe
12 matches
Mail list logo
