Re: Working with libcql
On 2013-07-09 11:46, Shubham Mittal wrote:
yeah I tried that and below is the output I get
LOG: resolving remote host localhost:9160
libcql is an implementation for the new binary transport protocol:
https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=doc/native_protocol.spec;hb=refs/heads/cassandra-1.2
It is not a thrift transport.
By default it uses the 9042 port. You'll have to activate it on the
server. Write (or uncomment) start_native_transport: true in
conf/cassandra.yaml.
According to the posted log, you connect to the thrift transport port,
9160. As you send a frame of the new transport protocol to the old
thrift protocol, the server does not understand it and closes your
connection.
Regards,
Sorin
LOG: resolved remote host, attempting to connect
LOG: connection successful to remote host
LOG: sending message: 0x0105 {version: 0x01, flags: 0x00,
stream: 0x00, opcode: 0x05, length: 0} OPTIONS
LOG: wrote to socket 8 bytes
LOG: error reading header End of file
and I checked all the keyspaces in my cluster, it changes nothing in the
cluster.
I couldn't understand the code much. What is this code supposed to do
anyways?
On Tue, Jul 9, 2013 at 4:20 AM, aaron morton aa...@thelastpickle.com
mailto:aa...@thelastpickle.com wrote:
Did you see the demo app ?
Seems to have a few examples of reading data.
https://github.com/mstump/libcql/blob/master/demo/main.cpp#L85
Cheers
-
Aaron Morton
Freelance Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 9/07/2013, at 1:14 AM, Shubham Mittal smsmitta...@gmail.com
mailto:smsmitta...@gmail.com wrote:
Hi,
I found out that there exist a C++ client libcql for cassandra but
its github repository just provides the example on how to connect
to cassandra. Is there anyone who has written some code
using libcql to read and write data to a cassandra DB, kindly
share it.
Thanks
Re: partition key of composite type and where partition_key in (...) clause
On 2013-06-06 11:36, Sylvain Lebresne wrote:
We indeed don't support that kind of syntax. We might someday
(seehttps://issues.apache.org/jira/browse/CASSANDRA-4851
http://issues.apache.org/jira/browse/CASSANDRA-4851, even though the
description is more general, this kind of would introduce that kind of
syntax).
*But* another solution is just to do 2 (or more) separate queries
(instead of using a IN). And *no*, in general using a IN will not really
be much faster in that case because Cassandra doesn't really optimize
this kind of IN queries (IN queries on the partition key that is).
Provided you make sure to parallelize the queries client side, it may
even end up being faster in practice because the client will be able to
start processing query responses as they come back.
--
Sylvain
Thank you, Eric and Sylvain.
Sorin
On Wed, Jun 5, 2013 at 7:18 PM, Eric Stevens migh...@gmail.com
mailto:migh...@gmail.com wrote:
Hi Sorin,
I'm not aware of CQL supporting Cartesian set notation, and like you
when I tried it, the CQL parser bailed at the first parenthesis -
*(*k1, k2)
You cannot use SELECT in a BATCH statement, see
http://cassandra.apache.org/doc/cql/CQL.html#BATCH
So I'm not sure what your options are other than to manually
composite your K1, K2 pairs into a separate column, /which is part
of the primary key /(necessary for the IN() clause to work). If you
still need to query separately on k1 and/or k2, you can also
preserve these as independent columns with indices.
cqlsh:test drop table tbl;
cqlsh:test create table tbl (
... k1k2 text,
... k1 int,
... k2 text,
... k3 text,
... m blob,
... PRIMARY KEY (k1k2, k3)
... );
cqlsh:test CREATE INDEX ON tbl (k1);
cqlsh:test CREATE INDEX ON tbl (k2);
cqlsh:test
cqlsh:test INSERT INTO tbl (k1, k2, k3, m, k1k2) VALUES (0, 'abc',
'def', 'deadbeef', '0|abc');
cqlsh:test INSERT INTO tbl (k1, k2, k3, m, k1k2) VALUES (1, 'xyz',
'uvw', '8badf00d', '1|xyz');
cqlsh:test SELECT * FROM tbl WHERE k1k2 IN ('0|abc','1|xyz');
k1k2 | k3 | k1 | k2 | m
---+-++-+
0|abc | def | 0 | abc | 0xdeadbeef
1|xyz | uvw | 1 | xyz | 0x8badf00d
cqlsh:test SELECT * FROM tbl WHERE k1=0;
k1k2 | k3 | k1 | k2 | m
---+-++-+
0|abc | def | 0 | abc | 0xdeadbeef
-Eric Stevens
ProtectWise, Inc.
On Wed, Jun 5, 2013 at 9:29 AM, Sorin Manolache sor...@gmail.com
mailto:sor...@gmail.com wrote:
Hello,
Is it possible to use the where partition_key in (...) clause
if the partition key has a composite type?
I have a schema as follows:
create table tbl (
k1 int,
k2 varchar,
k3 varchar,
m blob,
primary key((k1, k2), k3)
)
I would like to be able to do something like
select m from tbl where (k1, k2) in ((0, 'abc'), (1, 'xyz'));
I think though that I'll have to use the more verbose
begin unlogged batch
select m from tbl where k1=0 and k2='abc'
select m from tbl where k1=1 and k2='xyz'
apply batch;
Thanks,
Sorin
partition key of composite type and where partition_key in (...) clause
Hello, Is it possible to use the where partition_key in (...) clause if the partition key has a composite type? I have a schema as follows: create table tbl ( k1 int, k2 varchar, k3 varchar, m blob, primary key((k1, k2), k3) ) I would like to be able to do something like select m from tbl where (k1, k2) in ((0, 'abc'), (1, 'xyz')); I think though that I'll have to use the more verbose begin unlogged batch select m from tbl where k1=0 and k2='abc' select m from tbl where k1=1 and k2='xyz' apply batch; Thanks, Sorin
Re: C++ Thrift client
On 2013-05-16 02:58, Bill Hastings wrote: Hi All I am doing very small inserts into Cassandra in the range of say 64 bytes. I use a C++ Thrift client and seem consistently get latencies anywhere between 35-45 ms. Could some one please advise as to what might be happening? Sniff the network traffic in order to check whether you use the same connection or you open a new connection for each new insert. Also check if the client does a set_keyspace (or use keyspace) before every insert. That would be wasteful too. In the worst case, the client would perform an authentication too. Inspect timestamps of the network packets in the capture file in order to determine which part takes too long: the connection phase? The authentication? The interval between sending the request and getting the response? I do something similar (C++ Thrift, small inserts of roughly the same size as you) and I get response times of 100ms for the first request when opening the connection, authentifying, and setting the keyspace. But subsequent requests on the same connection have response times in the range of 8-11ms. Sorin
Re: C language - cassandra
On 2013-05-17 16:42, Apostolis Xekoukoulotakis wrote: Hello, new here, What are my options in using cassandra from a program written in c? A) Thrift has no documentation, so it will take me time to understand. Thrift also doesnt have a balancing pool, asking different nodes every time, which is a big problem. Thrift has a sort of documentation. Check interface/cassandra.thrift in cassandra's source files. The file contains quite thorough comments for each method and data structure. Once you've read this file, it is quite easy to browse through the Cassandra.h and cassandra_types.h that are generated from cassandra.thrift by the thrift compiler. Sending requests is quite straightforward. Setting up a connection is more verbose and, imo, relatively complex. About pools, you're right. I guess you'll have to write your own. B) Should I use the hector (java) client and then send the data to my program with my own protocol? Seems a lot of unnecessary work. Any other suggestions? I would go for thrift. After digging one or two days you'll have it working. Sorin -- Sincerely yours, Apostolis Xekoukoulotakis
Re: Deletes, null values
On 2013-04-26 11:55, Alain RODRIGUEZ wrote:
Of course:
From CQL 2 (cqlsh -2):
delete '183#16684','183#16714','183#16717' from myCF where key = 'all';
And selecting this data as follow gives me the result above:
select '1228#16857','1228#16866','1228#16875','1237#16544','1237#16553'
from myCF where key = 'all';
From thrift (phpCassa client):
$pool = new
ConnectionPool('myKeyspace',array('192.168.100.201'),6,0,3,3);
$my_cf= new ColumnFamily($pool, 'myCF', true, true,
ConsistencyLevel::QUORUM, ConsistencyLevel::QUORUM);
$my_cf-remove('all', array('1228#16857','1228#16866','1228#16875'));
I see. I'm sorry, I know nothing about phpCassa. I use batch_mutation
with deletions and it works. But I guess phpCassa must use the same
thrift primitives.
Sorin
2013/4/25 Sorin Manolache sor...@gmail.com mailto:sor...@gmail.com
On 2013-04-25 11:48, Alain RODRIGUEZ wrote:
Hi, I tried to delete some columns using cql2 as well as thrift on
C*1.2.2 and instead of being unreachable, deleted columns have a
null value.
I am using no value in this CF, the only information I use is the
existence of the column. So when I select all the column for a
given key
I have the following returned:
1228#16857 | 1228#16866 | 1228#16875 | 1237#16544 | 1237#16553
---+--__+--+--__-+__--
null | null | null |
|
This is quite annoying since my app thinks that I have 5 columns
there
when I should have 2 only.
I first thought that this was a visible marker of tombstones but
they
didn't vanish after a major compaction.
How can I get rid of these null/ghost columns and why does it
happen ?
I do something similar but I don't see null values. Could you please
post the code where you delete the columns?
Sorin
Re: Prepared Statement - cache duration (CQL3 - Cassandra 1.2.4)
On 2013-04-19 13:57, Stuart Broad wrote: Hi, I am using Cassandra.Client prepare_cql3_query/execute_prepared_cql3_query to create and run some prepared statements. It is working well but I am unclear as to how long the server side 'caches' the prepared statements. Should a prepared statement be prepared for every new Cassandra.Client? Based on my limited testing it seems like I can create some prepared statements in one Cassandra.Client and use in another but I am not sure how reliable/lasting this is i.e. If I called the prepared statement again the next day would it still exist? What about if cassandra was re-started? _Background:_ I am creating prepared statements for batch updates of pre-defined lengths (e.g. 1, 1000, 500, 250, 50, 10, 1) and wanted to know if these could just be set up once. We felt that using the prepared statements was easier than escaping values within a CQL statement and probably more performant. Thanks in advance for your help. I've looked in Cassandra's code (v1.2.3). The cache of prepared statements has a size of 100,000. So if you prepare more than 100 thousand statements, the least recently used ones will vanish. You'll get the exception PreparedQueryNotFoundException, code 0x2500. Regards, Sorin
Re: Prepared Statement - cache duration (CQL3 - Cassandra 1.2.4)
On 2013-04-19 13:57, Stuart Broad wrote: Hi, I am using Cassandra.Client prepare_cql3_query/execute_prepared_cql3_query to create and run some prepared statements. It is working well but I am unclear as to how long the server side 'caches' the prepared statements. Should a prepared statement be prepared for every new Cassandra.Client? Based on my limited testing it seems like I can create some prepared statements in one Cassandra.Client and use in another but I am not sure how reliable/lasting this is i.e. If I called the prepared statement again the next day would it still exist? What about if cassandra was re-started? I don't know the answer and I have the same question. But have a look at this discussion, dating from September 2012. https://issues.apache.org/jira/browse/CASSANDRA-4449 Apparently prepared statements are shared among threads (they were per-connection previously), they don't survive server restarts, apparently there's an LRU mechanism, and apparently you get a special exception if the prepared statement disappeared so you can prepare it again. Regards, Sorin _Background:_ I am creating prepared statements for batch updates of pre-defined lengths (e.g. 1, 1000, 500, 250, 50, 10, 1) and wanted to know if these could just be set up once. We felt that using the prepared statements was easier than escaping values within a CQL statement and probably more performant. Thanks in advance for your help. Regards, Stuart p.s. I am relatively new to cassandra.
is the select result grouped by the value of the partition key?
Hello,
Let us consider that we have a table t created as follows:
create table t(k1 vachar, k2 varchar, value varchar, primary key (k1, k2));
Its contents is
a m x
a n y
z 0 9
z 1 8
and I perform a
select * from p where k1 in ('a', 'z');
Is it guaranteed that the rows are grouped by the value of the partition
key? That is, is it guaranteed that I'll get
a m x
a n y
z 0 9
z 1 8
or
a n y
a m x
z 1 8
z 0 9
or even
z 0 9
z 1 8
a n y
a m x
but NEVER
a m x
z 0 9
a n y
z 1 8
Thank you,
Sorin
