I am creating a new table through a SQL query from a spatial table:
CREATE TABLE SomeShapes AS
SELECT ash.id, ash.Geometry
FROM AllShapes ash
WHERE ash.id = 30
However, this returns a "normal" table, so when I try to load it in a GIS program (QGIS), it doesn't show the geometry. How do I declare that the geometry column contains, well, geometry?
You need to create a "non-spatial" table, and then add the Geometry column to it.
Then, you can insert data into your table.
It can't be done in one single step (create table as select). From the documentation:
Creating a Geometry-type at the same time the corresponding table is
created isn't allowed. You always must first create the table, then
adding the Geometry-column in a second time and as a separate step.
CREATE TABLE test_geom (
id INTEGER NOT NULL
PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
measured_value DOUBLE NOT NULL);
SELECT AddGeometryColumn('test_geom', 'Geometry', 4326, 'POINT', 'XY');
Also, take into account that you may want to use spatial indexes to improve the performance
SELECT CreateSpatialIndex('test_geom', 'Geometry');
Related
We are trying to remove 2 columns in a table with 3 types and make them as UDT instead of having those 2 as columns. So we came up with below two options. I just wanted to understand if there are any difference in these two UDT in Cassandra database?
First option is:
CREATE TYPE test_type (
cid int,
type text,
hid int
);
and then using like this in a table definition
test_types set<frozen<test_type>>,
vs
Second option is:
CREATE TYPE test_type (
type text,
hid int
);
and then using like this in a table definition
test_types map<int, frozen<test_type>
So I am just curious which one is a preferred option here for performance related or they both are same in general?
It's really depends on how will you use it - in the first solution you won't able to select element by cid, because to access the set element you'll need to specify the full UDT value, with all fields.
The better solution would be following, assuming that you have only one collection column:
CREATE TYPE test_type (
type text,
hid int
);
create table test (
pk int,
cid int
udt frozen<test_type>,
primary key(pk, cid)
);
In this case:
you can easily select individual element by specifying the full primary key. The ability to select individual elements from map is coming only in Cassandra 4.0. See the CASSANDRA-7396. Until that you'll need to get full map back, even if you need one element, and this will limit you on the size of the map
you can even select the range of the values, using the range query
you can get all values by specifying only partition key (pk in this example)
you can select multiple non-consecutive values by doing select * from test where pk = ... and cid in (..., ..., ...);
See the "Check use of collection types" section in the data model checks best practices doc.
I have a very simple data table. But after reading a lot of examples in the internet, I am still more and more confused how to solve the following scenario:
1) The Table
My data table looks like this (without defining the primayr key, as this is my understanding problem):
CREATE TABLE documents (
uid text,
created text,
data text
}
Now my goal is to have to different ways to select data.
2) Select by the UID:
SELECT * FROM documents
WHERE uid = ‘xxxx-yyyyy-zzzz’
3) Select by a date limit
SELECT * FROM documents
WHERE created >= ‘2015-06-05’
So my question is:
What should my table definition in Cassandra look like, so that I can perform these selections?
To achieve both queries, you would need two tables.
First one would look like:
CREATE TABLE documents (
uid text,
created text,
data text,
PRIMARY KEY (uid));
and you retrieve your data with: SELECT * FROM documents WHERE uid='xxxx-yyyy-zzzzz' Of course, uid must be unique. You might want to consider the uuid data type (instead of text)
Second one is more delicate. If you set your partition to the full date, you won't be able to do a range query, as range query is only available on the clustering column. So you need to find the sweet spot for your partition key in order to:
make sure a single partition won't be too large (max 100MB,
otherwise you will run into trouble)
satisfy your query requirements.
As an example:
CREATE TABLE documents_by_date (
year int,
month int,
day int,
uid text,
data text,
PRIMARY KEY ((year, month), day, uid);
This works fine if within a day, you don't have too many documents (so your partition don't grow too much). And this allows you to create queries such as: SELECT * FROM documents_by_date WHERE year=2018 and month=12 and day>=6 and day<=24; If you need to issue a range query across multiple months, you will need to issue multiple queries.
If your partition is too large due to the data field, you will need to remove it from documents_by_date. And use documents table to retrieve the data, given the uid you retreived from documents_by_date.
If your partition is still too large, you will need to add hour in the partition key of documents_by_date.
So overall, it's not a straightforward request, and you will need to find the right balance for yourself when defining your partition key.
If latency is not a huge concern, an alternative would be to use the stratio lucene cassandra plugin, and index your date.
Question does not specify how your data is going to be with respect user and create time. But since its a document, I am assuming that one user will be creating one document at one "created" time.
Below is the table definition you can use.
CREATE TABLE documents (
uid text,
created text,
data text
PRIMARY KEY (uid, created)
) WITH CLUSTERING ORDER BY (created DESC);
WITH CLUSTERING ORDER BY (created DESC) can help you get the data order by created for a given user.
For your first requirement you can query like given below.
SELECT * FROM documents WHERE uid = 'SEARCH_UID';
For your second requirement you can query like given below
SELECT * FROM documents WHERE created > '2018-04-10 11:32:00' ALLOW FILTERING;
Use of Allow Filtering should be used diligently as it scans all partitions. If we have to create a separate table with date as primary key, it becomes tricky if there are many documents being inserted at very same second. Clustering order works best for the requirements where documents for a given user need to be sorted by time.
I want to retrieve all items within a specific column of a table.
In this scenario, I have 2 tables, The first table contains a primary key, and the second table contains a foreign key. a 1 to many relationship is set up for the tables respectively.
I want a function/way of retrieving all items within a column in table 2 that has a foreign key that matches the primary key in table 1.
One way of doing this is through a VLOOKUP, though surely through using DAX, or some other function set, I can exploit the relationship I have made in the DataModel to make this easier for me to do.
Why don't you just get the required data from the DB with a proper SELECT statement? Something like
SELECT column
FROM t1, t2
WHERE t1.key = t2.fkey
AND t1.key = 'whatever you search for';
Then you should get the data you want.
Suppose we have such table:
create table users (
id text,
roles set<text>,
PRIMARY KEY ((id))
);
I want all the values of this table to be stored on the same Cassandra node (OK, not really the same, same 3, but have all the data mirrored, but you got the point), so to achieve that i want to change this table to be like this:
create table users_v2 (
partition int,
id text,
roles set<text>,
PRIMARY KEY ((partition), id)
);
How can i do that without losing the data from the first table?
It seems to be impossible to ALTER TABLE in order to add such column. i'm OK with that.
What i try to do is to copy data from the first table and insert to the second table.
When i do it as it is, the partition column іs missing, which is expected.
I can ALTER the first table and add a 'partition' column to the end, and then COPY in correct order, but i can't update all the rows in the first table to set the all some partition, and it seems to be no "default" value when column is added.
You simply cannot alter the primary key of a Cassandra table. You need to create another table with your new schema and perform a data migration. I would suggest that you use Spark for that since it is really easy to do a migration between two tables with only a few lines of code.
This also answer to the alter primary key question.
If you have not a lot of data in table there is another way.
In utility "DataStax Dev Center", select table and use command "Export All result to file as INSERT". It will save all data from table to file with Insert CQL-instructions.
Then you should drop table, create new one with new PARTITION KEY and finally fill it by instructions from file via CQL.
I am trying to create a following hierarchy:
UserId as rowKey, Hourly time series as columns and inside each hourly column I want to have a user specific information such as hourly activity.
{
UserId:long
{
Timestamp:datetime{
pageview: integer,
clicks:integer
}
}
I've read that it is possible to achieve it using supercolumns but at the same time it was mentioned that supercolumns are outdated right now. If it is true, any alternatives I can use?
Could you please provide me CQL / Java thrift example how should I create and insert such type of structure in Cassandra?
Thanks!
You can user composite primary key for this, I add a table creation CQL query for the table. And you can use counter column for clicks.
CREATE TABLE user_click_by_hour(
userid long,
time_stamp timestamp,
clicks int,
pageview int,
PRIMARY KEY(userid,time_stamp)
)
If your information is subjected to a particular used and accessed together . For example,if you are at anytime , require both clicks and pageview, i would suggest you to use it as a json store
CREATE TABLE user_click_by_hour(
userid long,
time_stamp timestamp,
val text,
PRIMARY KEY(userid,time_stamp)
)
val is a json object containing clicks, pageview and etc.
Advantage
1.You need not worry about altering the table for adding extra column, which add a null value for each and every previous entry
If this data is designated to grow, you are bound to save a lot of space as there is one less column metadata in each node