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
Hey Jack,
I don't want to use Titan, though it's a great product. IIRC, they
require Order Preserving Partitioner to load edges that span multiple row
keys for their Cassandra storage engine.
Also, the graph is embedded as part of this open source product.
http://usergrid.incubator.apache.org/
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
You might want to take a look at Titan, a graph database that can use Cassandra
as its storage engine, and see how it does these things.
-- Jack Krupansky
From: Todd Nine
Sent: Sunday, August 31, 2014 11:06 AM
To: user@cassandra.apache.org
Subject: Re: Help with migration from Thrift to CQL3 o
You need to switch gears to new terminology as well - a "thrift row" is a
partition now, etc... :)
So yes - the *partition* key of the *table* would be scopeId, scopeType in
my proposed scheme.
But the partitions would be too big, given what you describe.
You could shard the rows, but even then
Hey Michael,
Thanks for the response. If I use the clustered columns in the way you
described, won't that make the row key of the column family scopeId and
scopeType?
The scope fields represent a graph's owner. The graph itself can have
several billion nodes in it. When a lot of deletes star
Actually I think you do want to use scopeId, scopeType as the partition key
(and drop row caching until you upgrade to 2.1 where "rows" are in fact
rows and not partitions):
CREATE TABLE IF NOT EXISTS Graph_Marked_Nodes
(
scopeId uuid, scopeType varchar, nodeId uuid, nodeType varchar,
timestam
Hi Gary,
On 31 Aug 2014, at 07:19, Gary Zhao wrote:
> Hi
>
> Could you recommend a Scala driver and share your experiences of using it. Im
> thinking if i use java driver in Scala directly
>
>
I am using Martin’s approach without any problems:
https://github.com/magro/play2-scala-cassandra
12 matches
Mail list logo
