Sure, but he should create the Phoenix table already salted.

În Mar, 4 oct. 2016, 17:21 Mujtaba Chohan, <> a scris:
If you lead with timestamp key, you might want to consider experimenting with salting as writing data would hotspot on single region if keys are monotonically increasing.

On Tue, Oct 4, 2016 at 8:04 AM, Ciureanu Constantin <> wrote:
select * from metric_table where metric_type='x'
-- so far so good

and timestamp > 'start_date' and timestamp < 'end_date'.
-- here in case the timestamp is long (BIGINT in Phoenix) - it should work fine!
Try also with "timestamp between (x and y)"

Anyway - my proposal would be to reverse the key parts - have timestamp first, then metric type, then other parts in the key. 

Using the timestamp it would define the start+stop of the scan range (that's a must, step 1) - then it would filter locally the metric type with Skips when it's not the searched value then some other parts of the key with lower importance (if any of them are part of the where clause).

 Note: This new key proposal would solve your current use-case / but wouldn't be perfect for potential new use-case - then you would need indexes or duplicated data in other tables ...

2016-10-04 6:03 GMT+02:00 Krishna <>:
You have two options:
- Modify your primary key to include metric_type & timestamp as leading columns. 
- Create an index on metric_type & timestamp

On Monday, October 3, 2016, Kanagha <> wrote:
Sorry for the confusion. 

metricId  is defined as the primary key via Phoenix for metric_table.



On Mon, Oct 3, 2016 at 3:41 PM, Michael McAllister <> wrote:


there is no indexing available on this table yet.



So you haven’t defined a primary key constraint? Can you share your table creation DDL?


Michael McAllister

Staff Data Warehouse Engineer | Decision Systems | C: 512.423.7447 | skype: michael.mcallister.ha | webex: https://h.a/mikewebex

This electronic communication (including any attachment) is confidential.  If you are not an intended recipient of this communication, please be advised that any disclosure, dissemination, distribution, copying or other use of this communication or any attachment is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by reply e-mail and promptly destroy all electronic and printed copies of this communication and any attachment.


From: Kanagha <>
Reply-To: "" <>
Date: Monday, October 3, 2016 at 5:32 PM
To: "" <>, "" <>
Subject: Re: Question regarding designing row keys


there is no indexing available on this table yet.