Hi there,
I did try to reverse the order of the Composite Key and it worked!
I changed BIGINT to UNSIGNED_LONG because I was facing some issues with the
timezone of the DATE field.
There is one small detail I cannot understand why is happening:
When I give the query:
SELECT * FROM SENSOR_DATA
Hi there,
I am investigating Phoenix as a potential data-store for time-series data
on sensors.
What I am really interested in, as a first milestone, is to have efficient
time range queries for a particular sensor. From those queries the results
would consist of 1 or 2 columns (so small rows).
I
Hi Vladimir,
thanks a lot for your input, just some followup questions:
1) When you say try to fit it in long you mean UNSIGNED_LONG from
https://phoenix.apache.org/language/datatypes.html right?
2) Would also string format be efficient? Like MMDDHHmm right?
Thanks a lot!
On 8 June 2015 at
There are several time data types, natively supported by Phoenix: TIME is
probably most suitable for your case (it should have millisecond accuracy,
but you better check it yourself.)
-Vlad
On Mon, Jun 8, 2015 at 9:02 AM, Yiannis Gkoufas johngou...@gmail.com
wrote:
Hi Vladimir,
thanks a lot
Both DATE and TIME have millisecond granularity (both are stored as 8
byte longs), so I'd recommend using either of those. Phoenix also
supports date arithmetic, so you can do queries like this to get the
last weeks worth of data:
SELECT * FROM SENSOR_DATA
WHERE sid = 'ID1' AND dt CURRENT_TIME()
