Looking through the CQL 3.1 grammar in Cassandra, I found a "':' ident"
alternative in the "value" rule (line 961).
Is this for binding named parameters in prepared statements? Is this
currently supported by any of the drivers or in Cassandra (2.1) itself?
Looking at the docs and the current Java
Cassandra partitions data across the cluster based on PK,
thus is optimized for WHERE PK=...
You are doing table scans, the opposite of what a distributed
system is designed for.
However, some users find Solr helps with queries like yours.
To learn what C* is good at, read this:
http://planet
> Hi All
>
>
>
> I am trying to configure a Cassandra cluster with two nodes. I am new to
Cassandra.
>
>
>
> I am using datastax distribution of Cassandra ( windows). I have
installed the same in two nodes and configured it works as a separate
instance but not as cluster.
>
>
>
> The key changes
cqlsh in Cassandra 2.1.0 uses the DataStax python driver. The
"cassandra.metadata" module is provided by this package. By default it uses
the driver from an archive included in the Cassandra distribution
(.../lib/cassandra-driver-internal-only-2.1.0.zip).
See /usr/local/apache-cassandra-2.1.0/bin/
>
> cqlsh in Cassandra 2.1.0 uses the DataStax python driver. The
> "cassandra.metadata" module is provided by this package. By default it uses
> the driver from an archive included in the Cassandra distribution
> (.../lib/cassandra-driver-internal-only-2.1.0.zip).
Ok that's really good to know.
Hi,
I'm currently testing Cassandra 2.0.9 (and since the last week 2.1) under some
read heavy load...
I have 2 cassandra nodes (RF : 2) running under CentOS 6 with 16GB of RAM and 8
Cores.
I have around 93GB of data per node (one Disk of 300GB with SAS interface and a
Rotational Speed of 105
Yes, you can bind parameters by name:
```
INSERT INTO songs (id, title, album, artist) VALUES (:id, :title, :album,
:artist)
```
All DataStax drivers for Cassandra support this feature. In Java it looks
like
// prepare only once
PreparedStatememt pstmt = session.prepare("INSERT INTO songs (id, t
Thanks everyone for the responses. One thing I'd forgotten about was the
need to model the CFs with regard to the kind of queries that are needed.
Fortunately this is primarily a write-once/read-many type of application,
so deletions are not currently a concern, but worth keeping in mind for the
fu
Its going to depend a lot on your data model but 5-6k is on the low end of what
I would expect. N=RF=2 is not really something I would recommend. That said
93GB is not much data so the bottleneck may exist more in your data model,
queries, or client.
What profiler are you using? The cpu on t
Hi Adam,
Ok thanks again for the tips there! So I fell back to the stock
configuration of cassandra 2.1.0 and setup my environment variables... and
I was able to get cqlsh to work!
[root@beta-new:~] #cqlsh
Connected to mydomain Cluster at beta-new.mydomain.com:9042.
[cqlsh 5.0.1 | Cassandra 2.
Eric,
We have a new stress tool to help you share your schema for wider bench
marking. see
http://www.datastax.com/dev/blog/improved-cassandra-2-1-stress-tool-benchmark-any-schema
If you wouldn't mind creating a yaml for your schema I would be happy to
take a look.
-Jake
On Mon, Sep 22, 2014
I have a 6 (i2.2xlarge) node cluster on AWS with 4.5 DSE running on it. I
notice high compaction pending on one of the node around 35.
Compaction throughput set to 64 MB and flush writes to 4. Any suggestion is
much appreciated.
--
Arun
Senior Hadoop Engineer
Cloudwick
Champion of Big Data
http
Hi,
I have a column family storing very large blobs that I would not like to
duplicate, if possible.
Here's a simplified version:
CREATE TABLE timeline (
key text,
a int,
b int,
value blob,
PRIMARY KEY (key, a, b)
);
On this, I run exactly two types of query. Both of them must hav
35 isn't that high really in some scenarios (ie, theres a lot of column
families), is it continuing to climb or does it drop down shortly after?
---
Chris Lohfink
On Sep 22, 2014, at 7:57 PM, arun sirimalla wrote:
> I have a 6 (i2.2xlarge) node cluster on AWS with 4.5 DSE running on it. I
> n
Its constant since 4 hours. Remaining nodes have around 10 compactions. We have
4 column families.
> On Sep 22, 2014, at 19:39, Chris Lohfink wrote:
>
> 35 isn't that high really in some scenarios (ie, theres a lot of column
> families), is it continuing to climb or does it drop down shortly
Whats the output of 'nodetool compactionstats'? Is concurrent_compactors not
set in your cassandra.yaml? Any Exception or Error 's in the system.log or
output.log?
---
Chris Lohfink
On Sep 22, 2014, at 9:50 PM, Arun wrote:
> Its constant since 4 hours. Remaining nodes have around 10 compac
16 matches
Mail list logo
