Hi,
We are having an issue with TTL on Secondary index columns. We get 0
rows in return when running queries on indexed columns that have TTL.
Everything works fine with small amounts of data, but when we get over
a ceratin threshold it looks like older rows dissapear from the index.
In the
Hi!
I want to know how many client connections has each one of my cluster nodes
(to check if my load balancing is spreading in a balanced way, to check if
increase in the cluster load can be related to an increase in the number of
connections, and things like that). I was thinking about going
I was trying to mix CQL2 and CQL3 to check whether a columnfamily with
compound keys can be further indexed. Because using CQL3 secondary indexing
on table with composite PRIMARY KEY is not possible. And surprisingly by
mixing the CQL versions i was able to do so. But when i want to insert
Hi,
for a number of reasons (particularly to prevent accidental access), I've
decided to try to secure (slightly) our Cassandra installation(s).
To this end I've started with 'securing' client access via code very similar
to SimpleAuthenticator (in examples dir). This, however, has no effect on
CQL2 and CQL3 indexes are not compatible. I guess CQL2 is able to detect
that the table was defined in CQL3 probably should not allow it. Backwards
comparability is something the storage engines and interfaces have to
account for. At least they should prevent you from hurting yourself.
But do not
Hi folks. Still working through the details of building out a Cassandra
solution and I have an interesting requirement that I'm not sure how to
implement in Cassandra:
In our current Oracle world, we have the data for this system partitioned by
month, and each month the data that are now
You could make a column family for each period of time and then drop the column
family when you want to destroy it. Before you drop it you could use the
sstabletojson converter and write the json files out to tape.
Might make your life difficult however if you need an input split for map
If I'm understanding you correctly, you can write TTL's on each insert.
18 months would be roughly 540 days which would be 46656000 seconds. I've not
tried that number, but I use smaller TTL's all the time and they work fine.
Once they are expired they get tombstones and are no longer
My understanding was that TTLs only apply to columns and not on a per row
basis. This means that for each column insert you would need to set that TTL.
Does this mean that the amount of data space used in such a case would be the
TTL * the number of columns? I was hoping there was a way to
No way to read the taped data with TTL later - will disappear from tapes :)
Best regards / Pagarbiai
Viktor Jevdokimov
Senior Developer
Email: viktor.jevdoki...@adform.commailto:viktor.jevdoki...@adform.com
Phone: +370 5 212 3063, Fax +370 5 261 0453
J. Jasinskio 16C, LT-01112 Vilnius,
Michael - That is one approach I have considered, but that also makes querying
the system particularly onerous since every column family would require its own
query – I don’t think there is any good way to “join” those, right?
Chris – that is an interesting concept, but as Viktor and Keith
Just make month time stamp a part of row key. Then once a month select old
data, move it and delete.
Andrey
On Tue, Dec 18, 2012 at 8:08 AM, stephen.m.thomp...@wellsfargo.com wrote:
Hi folks. Still working through the details of building out a Cassandra
solution and I have an interesting
Yeah. No JOINs as of now in Cassandra.
What if you dumped the CF in question once a month to json and rewrote out each
record in the json data if it met the time stamp you were interested in
archiving.
You could then bulk load each month back in if you had to restore.
Doesn't help with
in your data directory, for each keyspace there is a solr.json. cassandra
stores the SSTABLEs it knows about when using leveled compaction. take a
look at that file and see if it looks accurate. if not, this is a bug with
cassandra that we are checking into as well
On Thu, Dec 6, 2012 at 7:38
AFAIK there is no way to disable hoisting.
Feel free to let your jira fingers do the talking.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 18/12/2012, at 6:10 PM, Edward Capriolo edlinuxg...@gmail.com wrote:
I have heard it best to try and avoid the use of super columns for now.
Yup.
Your model makes sense. If you are creating the CF using the cassandra-cli you
will probably want to reverse order the column names see
http://thelastpickle.com/2011/10/03/Reverse-Comparators/
If you want to use
Thanks for the nice steps to reproduce.
I ran this on my MBP using C* 1.1.7 and got the expected results, both get's
returned a row.
Were you running against a single node or a cluster ? If a cluster did you
change the CL, cassandra-cli defaults to ONE.
Cheers
-
Aaron
AFAIK the count connections is not exposed.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 18/12/2012, at 10:37 PM, Tomas Nunez tomas.nu...@groupalia.com wrote:
Hi!
I want to know how many client connections
netstat + cron is your friend at this point in time
On Dec 18, 2012, at 8:25 PM, aaron morton
aa...@thelastpickle.commailto:aa...@thelastpickle.com wrote:
AFAIK the count connections is not exposed.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
Hi,
I have been trying to run cassandra on windows(1.1.6) and i am getting an
exception while checking my node status.
nodetool ring -h localhost
Classcastexception: can not convert java.lang.String to some another java
type( i don't remember exact java class).
But somehow, this is fine on
20 matches
Mail list logo
