Jon,
Great article. Thank you. (I have nothing to do with this issue, but I
appreciate nuggets of information I glean from the list)
Regards,
Eric
On Tue, Apr 17, 2018 at 10:57 PM Jonathan Haddad wrote:
> To add to what Nate suggested, we have an entire blog post on
To add to what Nate suggested, we have an entire blog post on scaling time
series data models:
http://thelastpickle.com/blog/2017/08/02/time-series-data-modeling-massive-scale.html
Jon
On Tue, Apr 17, 2018 at 7:39 PM Nate McCall wrote:
> I disagree. Create date as a
;
发送时间: 2018年4月18日 6:00
收件人: user@cassandra.apache.org
主题: Re: 答复: Time serial column family design
Hi David,
Could you describe why you chose to include the create date in the partition
key? If the vin in enough "partitioning", meaning that the size (number of rows
x size of row) o
I disagree. Create date as a raw integer is an excellent surrogate for
controlling time series "buckets" as it gives you complete control over the
granularity. You can even have multiple granularities in the same table -
remember that partition key "misses" in Cassandra are pretty lightweight as
Hi David,
Could you describe why you chose to include the create date in the
partition key? If the vin in enough "partitioning", meaning that the size
(number of rows x size of row) of each partition is less than 100MB, then
remove the date and just use the create_time, because the date is
Your table design will work fine as you have appropriately bucketed by an
integer-based 'create_date' field.
Your goal for this refactor should be to remove the "IN" clause from your
code. This will move the rollup of multiple partition keys being retrieved
into the client instead of relying on
Hi Nate,
Thanks for your reply!
Is there other way to design this table to meet this requirement?
Best Regards,
倪项菲/ David Ni
中移德电网络科技有限公司
Virtue Intelligent Network Ltd, co.
Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
Mob: +86 13797007811|Tel: + 86 27 5024 2516
发件人: