;>>>> On Tue, Jul 7, 2015 at 11:32 AM, Peer, Oded wrote:
>>>>>
>>>>>> The data model suggested isn’t optimal for the “end of month” query
>>>>>> you want to run since you are not querying by partition key.
>>>>>>
>
month as clustering and keep
employee details as static columns so they wont be repeated Naidu Saladi
From: Srinivasa T N
To: "user@cassandra.apache.org"
Sent: Tuesday, July 7, 2015 3:07 AM
Subject: Re: Example Data Modelling
Thanks for the inputs.
Now my question is how
or a specific month which might
> cause hotspots on those nodes.
>
>
>
> Choose the approach that works best for you.
>
>
>
>
>
> *From:* Carlos Alonso [mailto:i...@mrcalonso.com
> ]
> *Sent:* Monday, July 06, 2015 7:04 PM
> *To:* user@cassandra.apache.or
;>>>> where month = 1” which requires filtering and has unpredictable
>>>>> performance.
>>>>>
>>>>>
>>>>>
>>>>> For this type of query to be fast you can use the “month” column as
>>>>> the pa
This approach also has drawbacks:
>>>>
>>>> 1. This data model creates a wide row. Depending on the number of
>>>> employees this partition might be very large. You should limit partition
>>>> sizes to 25MB
>>>>
>>>> 2. D
ng data according to month means that only a small number
>>> of nodes will hold all of the salary data for a specific month which might
>>> cause hotspots on those nodes.
>>>
>>>
>>>
>>> Choose the approach that works best for you.
>>
ion
>> sizes to 25MB
>>
>> 2. Distributing data according to month means that only a small number of
>> nodes will hold all of the salary data for a specific month which might
>> cause hotspots on those nodes.
>>
>>
>>
>> Choose the approach that
number of
> nodes will hold all of the salary data for a specific month which might
> cause hotspots on those nodes.
>
>
>
> Choose the approach that works best for you.
>
>
>
>
>
> *From:* Carlos Alonso [mailto:i...@mrcalonso.com]
> *Sent:* Monday, Ju
7:04 PM
To: user@cassandra.apache.org
Subject: Re: Example Data Modelling
Hi Srinivasa,
I think you're right, In Cassandra you should favor denormalisation when in
RDBMS you find a relationship like this.
I'd suggest a cf like this
CREATE TABLE salaries (
EmpID varchar,
FN var
Hi Srinivasa,
I think you're right, In Cassandra you should favor denormalisation when in
RDBMS you find a relationship like this.
I'd suggest a cf like this
CREATE TABLE salaries (
EmpID varchar,
FN varchar,
LN varchar,
Phone varchar,
Address varchar,
month integer,
basic integer,
10 matches
Mail list logo
