Thanks Michael I will certainly go with this approach for now.
-Subodh
On Mon, Sep 1, 2014 at 6:33 AM, Laing, Michael
wrote:
> This should work for your query requirements - 2 tables w same info because
> disk is cheap and writes are fast so optimize for reads:
>
> CREATE TABLE sensor_asset (
>
Laing, Michael
> Sent: Monday, September 1, 2014 11:34 AM
> To: user@cassandra.apache.org
> Subject: Re: Help with select IN query in cassandra
>
> Did the OP propose that?
>
>
> On Mon, Sep 1, 2014 at 10:53 AM, Jack Krupansky
> wrote:
>>
>> One comment on del
1, 2014 11:34 AM
To: user@cassandra.apache.org
Subject: Re: Help with select IN query in cassandra
Did the OP propose that?
On Mon, Sep 1, 2014 at 10:53 AM, Jack Krupansky wrote:
One comment on deletions – aren’t deletions kind of an anti-pattern for
modern data processing, such as sensor
ging” rather than the exercise in
> futility of doing a massive number of deletes and updates in place?
>
> -- Jack Krupansky
>
> *From:* Laing, Michael
> *Sent:* Monday, September 1, 2014 9:33 AM
> *To:* user@cassandra.apache.org
> *Subject:* Re: Help with select IN quer
Krupansky
From: Laing, Michael
Sent: Monday, September 1, 2014 9:33 AM
To: user@cassandra.apache.org
Subject: Re: Help with select IN query in cassandra
This should work for your query requirements - 2 tables w same info because
disk is cheap and writes are fast so optimize for reads:
CREATE TABLE
This should work for your query requirements - 2 tables w same info because
disk is cheap and writes are fast so optimize for reads:
CREATE TABLE sensor_asset (
asset_id text,
event_time timestamp,
tuuid timeuuid,
sensor_reading map,
sensor_serial_number text,
sensor_type int,
PRIMAR
Thanks for your help Michael.
If specifying asset_id would help I can construct queries that can
include asset_id
So I have been "playing" around with PRIMARY KEY definition and
following table definition
CREATE TABLE sensor_info_table (
asset_id text,
event_time timestamp,
"timestamp" tim
Oh it must be late - I missed the fact that you didn't want to specify
asset_id. The above queries will still work but you have to use 'allow
filtering' - generally not a good idea. I'll look again in the morning.
On Sun, Aug 31, 2014 at 9:41 PM, Laing, Michael
wrote:
> Hmm. Because the cluster
Hmm. Because the clustering key is (event_time, "timestamp"), event_time
must be specified as well - hopefully that info is available to the ux.
Unfortunately you will then hit another problem with your query: you are
selecting a collection field... this will not work with IN on "timestamp".
So y
Not really event time stamp is created by the sensor when it reads data
and timestamp is something server creates when inserting data into
cassandra db. At later point in time my django ux allows users to browse
this data and reference interesting data points via the timestamp field.
The timestam
Are event_time and timestamp essentially representing the same datetime?
On Sunday, August 31, 2014, Subodh Nijsure wrote:
> I have following database schema
>
> CREATE TABLE sensor_info_table (
> asset_id text,
> event_time timestamp,
> "timestamp" timeuuid,
> sensor_reading map,
> se
I have following database schema
CREATE TABLE sensor_info_table (
asset_id text,
event_time timestamp,
"timestamp" timeuuid,
sensor_reading map,
sensor_serial_number text,
sensor_type int,
PRIMARY KEY ((asset_id), event_time, "timestamp")
);
CREATE INDEX event_time_index ON sensor_i
12 matches
Mail list logo
