Re: Concatenating ids with extension to keep multiple rows related to an entity in a single CF
the data in different rows of an entity is all of similar type but serves
different features but still has almost similar storage and retrieval needs
thus I wanted to put them in one CF and reduce column families.
From my knowledge, I believe compositeType existed for columns as
an alternative choice to implement something similar to supercolumns, are
there any cassandra's built in features to design composite keys using two
provided Integer ids.
Is my approach correct and recommended if I need to keep multiple rows
related to an entity in single CF ?
On Fri, Nov 4, 2011 at 10:11 AM, Tyler Hobbs ty...@datastax.com wrote:
On Thu, Nov 3, 2011 at 3:48 PM, Aditya Narayan ady...@gmail.com wrote:
I am concatenating two Integer ids through bitwise operations(as
described below) to create a single primary key of type long. I wanted to
know if this is a good practice. This would help me in keeping multiple
rows of an entity in a single column family by appending different
extensions to the entityId.
Are there better ways ? My Ids are of type Integer(4 bytes).
public static final long makeCompositeKey(int k1, int k2){
return (long)k1 32 | k2;
}
You could use an actual CompositeType(IntegerType, IntegerType), but it
would use a little extra space and not buy you much.
It doesn't sound like this is the case for you, but if you have several
distinct types of rows, you should consider using separate column families
for them rather than putting them all into one big CF.
--
Tyler Hobbs
DataStax http://datastax.com/
Re: Cassandra 1.x and proper JNA setup
Super - thank you for help :) On Thu, Nov 3, 2011 at 6:55 PM, Jonathan Ellis jbel...@gmail.com wrote: Relying on that was always a terrible idea because you could easily OOM before it could help. There's no substitute for don't make the caches too large in the first place. We're working on https://issues.apache.org/jira/browse/CASSANDRA-3143 to make cache sizing easier. On Thu, Nov 3, 2011 at 3:16 AM, Maciej Miklas mac.mik...@googlemail.com wrote: According to source code, JNA is being used to call malloc and free. In this case each cached row will be serialized into RAM. We must be really careful when defining cache size - to large size would cause out of memory. Previous Cassandra releases has logic that would decrease cache size if heap is low. Currently each row will be serialized without any memory limit checks - assuming that I understood it right. Those properties: reduce_cache_sizes_at: 0.85 reduce_cache_capacity_to: 0.6 are not used anymore - at least not when JNA is enabled, witch is default from Cassandra 1.0 On Wed, Nov 2, 2011 at 1:53 PM, Maciej Miklas mac.mik...@googlemail.com wrote: I've just found, that JNA will be not used from 1.1 release - https://issues.apache.org/jira/browse/CASSANDRA-3271 I would be also nice to know what was the reason for this decision. Regards, Maciej On Wed, Nov 2, 2011 at 1:34 PM, Viktor Jevdokimov viktor.jevdoki...@adform.com wrote: Up, also interested in answers to questions below. Best regards/ Pagarbiai Viktor Jevdokimov Senior Developer Email: viktor.jevdoki...@adform.com Phone: +370 5 212 3063 Fax: +370 5 261 0453 J. Jasinskio 16C, LT-01112 Vilnius, Lithuania Disclaimer: The information contained in this message and attachments is intended solely for the attention and use of the named addressee and may be confidential. If you are not the intended recipient, you are reminded that the information remains the property of the sender. You must not use, disclose, distribute, copy, print or rely on this e-mail. If you have received this message in error, please contact the sender immediately and irrevocably delete this message and any copies.-Original Message- From: Maciej Miklas [mailto:mac.mik...@googlemail.com] Sent: Tuesday, November 01, 2011 11:15 To: user@cassandra.apache.org Subject: Cassandra 1.x and proper JNA setup Hi all, is there any documentation about proper JNA configuration? I do not understand few things: 1) Does JNA use JVM heap settings? 2) Do I need to decrease max heap size while using JNA? 3) How do I limit RAM allocated by JNA? 4) Where can I see / monitor row cache size? 5) I've configured JNA just for test on my dev computer and so far I've noticed serious performance issues (high cpu usage on heavy write load), so I must be doing something wrong I've just copied JNA jars into Cassandra/lib, without installing any native libs. This should not work at all, right? Thanks, Maciej -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Clear snapshot on windows
Clearing snapshots on Windows with nodetool sometimes fails. The reason is because the snapshot files hardlinks into corresponding files in the data directory. When compaction runs, most of the files are merged and the corresponding snapshot files can be deleted but often .e.g. the secondary index files isn't compacted. If one of those undeletable files is the first in the loop to be deleted then the whole clear snapshot fails, and deletable files in the snapshot isn't deleted. I guess all files in data directory is eventually compacted and will then be eligible for deletion but would this be problem if we have seldom updated column family that wont be compacted very often? Is this considered a bug or is it something that won't be fixed due to the way Windows handles hard links? Regards /Fredrik
Cassandra Counters and TTL
Hello, I'm a new user of Cassandra and I think it's great. Still, while developing my APP using Cassandra, I got stuck with some things and I'm not really sure that Cassandra can handle them at the moment. So, first of all, does Cassandra allow for Counters and regular Keys to be located in the same ColumnFamily ? Secondly, is there any way to dynamically set the TTL for a key ? In the sense that I have a key, I initially set it with no TTL, but after a while I decide that it should expire in 100 seconds. Can Cassandra do this ? 3. Can counters have a TTL ? 4. Is there any way to atomically reset a counter ? I read on the website that the only way to do it is read the variable value, and then set it to -value, which seems rather bogus to me. Regards, -- Vlad Paiu OpenSIPS Developer
Re: Cassandra Counters and TTL
Answers inline. On Fri, Nov 4, 2011 at 4:59 PM, Vlad Paiu vladp...@opensips.org wrote: Hello, I'm a new user of Cassandra and I think it's great. Still, while developing my APP using Cassandra, I got stuck with some things and I'm not really sure that Cassandra can handle them at the moment. So, first of all, does Cassandra allow for Counters and regular Keys to be located in the same ColumnFamily ? What do you mean when you say regular Keys? If you are hinting at columns apart from counters, then the answer is *no*: only counters can exist in a CounterColumnFamily and other column families cannot hold counters. Secondly, is there any way to dynamically set the TTL for a key ? In the sense that I have a key, I initially set it with no TTL, but after a while I decide that it should expire in 100 seconds. Can Cassandra do this ? TTL is not for one key, it is for one column. 3. Can counters have a TTL ? No. Currently, counters do not (or if I am correct - cannot) have TTL. 4. Is there any way to atomically reset a counter ? I read on the website that the only way to do it is read the variable value, and then set it to -value, which seems rather bogus to me. I think that is the only way to reset a counter. I would like to know if there is another way. Background: I am using Cassandra since the past two months. Hope the community corrects me if I am wrong. Regards, -- Vlad Paiu OpenSIPS Developer -- Regards Amit S. Chavan
Multiget question
Multiget slice queries seem to fetch rows sequentially, at least fromwhat I understood of the sources. This means the node that receives amultiget of N keys does N get operations to the other nodes in thecluster to fetch the remaining keys. Am I right? Is this the way multiget works internally? Also, shouldn't this be done in parallel, to avoid contacting nodesmore than once? -- Filipe Gonçalves
Large Increase in SSTable count after Upgrade to 0.6.13
Hello, We moved from 0.6.6 to 0.6.13 recently on an 8 nodes cluster and started to see issues with two nodes where memtables are being flushed at a high rate and compaction seems to have fallen off or behind. A huge number of sstables has accumilated as a result of slowed compaction. We are also seeing a high number of dropped reads on only these two nodes. Here are the log entries for the two nodes: Node 11 2011-11-04_12:20:20.71219 '' WARN [DroppedMessagesLogger] 12:20:20,924 MessagingService.java:479 Dropped 126 READ messages in the last 5000ms 2011-11-04_12:20:20.92854 '' INFO [DroppedMessagesLogger] 12:20:20,924 GCInspector.java:143 Pool NameActive Pending 2011-11-04_12:20:20.92874 '' INFO [DroppedMessagesLogger] 12:20:20,924 GCInspector.java:157 STREAM-STAGE 0 0 2011-11-04_12:20:20.92895 '' INFO [DroppedMessagesLogger] 12:20:20,924 GCInspector.java:157 FILEUTILS-DELETE-POOL 0 0 2011-11-04_12:20:20.92915 '' INFO [FLUSH-WRITER-POOL:1] 12:20:20,924 Memtable.java:166 Completed flushing /var/lib/cassandra/data/current/SoundCloud/Activities-487528-Data.db (3619622 bytes) 2011-11-04_12:20:20.93263 '' INFO [DroppedMessagesLogger] 12:20:20,924 GCInspector.java:157 RESPONSE-STAGE0 0 2011-11-04_12:20:20.93263 '' INFO [DroppedMessagesLogger] 12:20:20,925 GCInspector.java:157 ROW-READ-STAGE8 348 2011-11-04_12:20:20.93264 '' INFO [DroppedMessagesLogger] 12:20:20,925 GCInspector.java:157 LB-OPERATIONS 0 0 2011-11-04_12:20:20.93264 '' INFO [DroppedMessagesLogger] 12:20:20,925 GCInspector.java:157 MISCELLANEOUS-POOL0 0 2011-11-04_12:20:20.93265 '' INFO [DroppedMessagesLogger] 12:20:20,925 GCInspector.java:157 GMFD 0 0 2011-11-04_12:20:20.93265 '' INFO [DroppedMessagesLogger] 12:20:20,925 GCInspector.java:157 CONSISTENCY-MANAGER 0 0 2011-11-04_12:20:20.93265 '' INFO [DroppedMessagesLogger] 12:20:20,926 GCInspector.java:157 LB-TARGET 0 0 2011-11-04_12:20:20.93266 '' INFO [DroppedMessagesLogger] 12:20:20,926 GCInspector.java:157 ROW-MUTATION-STAGE0 0 2011-11-04_12:20:20.93267 '' INFO [DroppedMessagesLogger] 12:20:20,926 GCInspector.java:157 MESSAGE-STREAMING-POOL0 0 2011-11-04_12:20:20.93267 '' INFO [DroppedMessagesLogger] 12:20:20,926 GCInspector.java:157 LOAD-BALANCER-STAGE 0 0 2011-11-04_12:20:20.93268 '' INFO [DroppedMessagesLogger] 12:20:20,926 GCInspector.java:157 FLUSH-SORTER-POOL 0 0 2011-11-04_12:20:20.93268 '' INFO [DroppedMessagesLogger] 12:20:20,926 GCInspector.java:157 MEMTABLE-POST-FLUSHER 1 2 2011-11-04_12:20:20.93269 '' INFO [DroppedMessagesLogger] 12:20:20,927 GCInspector.java:157 AE-SERVICE-STAGE 0 0 2011-11-04_12:20:20.93269 '' INFO [DroppedMessagesLogger] 12:20:20,927 GCInspector.java:157 FLUSH-WRITER-POOL 1 2 2011-11-04_12:20:20.93269 '' INFO [DroppedMessagesLogger] 12:20:20,927 GCInspector.java:157 HINTED-HANDOFF-POOL 1 6 2011-11-04_12:20:20.93270 '' INFO [DroppedMessagesLogger] 12:20:20,927 GCInspector.java:161 CompactionManager n/a 4089 2011-11-04_12:20:20.93270 '' INFO [DroppedMessagesLogger] 12:20:20,927 GCInspector.java:165 ColumnFamilyMemtable ops,data Row cache size/cap Key cache size/cap 2011-11-04_12:20:20.93271 '' INFO [DroppedMessagesLogger] 12:20:20,927 GCInspector.java:168 system.LocationInfo 0,0 0/0 1/3 2011-11-04_12:20:20.93272 '' INFO [DroppedMessagesLogger] 12:20:20,927 GCInspector.java:168 system.HintsColumnFamily 4,46 0/0 2/6 2011-11-04_12:20:20.93272 '' INFO [DroppedMessagesLogger] 12:20:20,927 GCInspector.java:168 SoundCloud.OwnActivities 28790,539601 0/037303/20 2011-11-04_12:20:20.93273 '' INFO [DroppedMessagesLogger] 12:20:20,928 GCInspector.java:168 SoundCloud.ExclusiveTracks10230,207529 0/0 3646/20 2011-11-04_12:20:20.93273 '' INFO [DroppedMessagesLogger] 12:20:20,928 GCInspector.java:168 SoundCloud.Activities5,90 0/0 20/20 2011-11-04_12:20:20.93274 '' INFO [DroppedMessagesLogger] 12:20:20,928 GCInspector.java:168 SoundCloud.IncomingTracks 0,0 0/0 20/20 Node 17 2011-11-04_12:21:55.15215 '' WARN [DroppedMessagesLogger] 12:21:55,417 MessagingService.java:479 Dropped 81 READ messages in the last 5000ms 2011-11-04_12:21:55.41788 '' INFO [DroppedMessagesLogger] 12:21:55,417 GCInspector.java:143 Pool NameActive Pending 2011-11-04_12:21:55.41789 '' INFO [DroppedMessagesLogger] 12:21:55,418 GCInspector.java:157 STREAM-STAGE 0 0
Why SSTable is sorted by tokens instead of row keys?
I want to save time series event logs into Cassandra, and I need to load them by key range (row key is time-based). But we can't use RandomPartitioner in this way, while OrderPreservingPartitioner leads to hot spot problem. So I wonder why Cassandra save SSTable by sorted row tokens instead of keys: if rows in SSTable are sorted by keys, it should be quite easy to return rows by key range -- token should be used to determine which node contains the data. For key range requests, Cassandra could ask every node for that range of rows, merge them and return to the caller. -- regards, Gary Shi
Re: Why SSTable is sorted by tokens instead of row keys?
On Fri, Nov 4, 2011 at 1:49 PM, Gary Shi gary...@gmail.com wrote: I want to save time series event logs into Cassandra, and I need to load them by key range (row key is time-based). But we can't use RandomPartitioner in this way, while OrderPreservingPartitioner leads to hot spot problem. So I wonder why Cassandra save SSTable by sorted row tokens instead of keys: if rows in SSTable are sorted by keys, it should be quite easy to return rows by key range -- token should be used to determine which node contains the data. For key range requests, Cassandra could ask every node for that range of rows, merge them and return to the caller. Without going for exhaustiveness: - Requesting every node is not too scalable. Cassandra is built to target the 'lots of cheap machines' kind of cluster, so that kind of operation is going the exact opposite way. In other words, that would be slow enough that you're better off modeling this using columns for time series. - That would make topology operations (bootstrap, move, decommission) much more costly, because we wouldn't be able to tell which keys to move unless we iterate over all the data each time. -- Sylvain -- regards, Gary Shi
Question about minor compaction
Assume the following default settings: min_compaction_threshold = 4, max_compaction_threshold = 32. When I start a bulk insert in Cassandra, I see minor compactions work: all similar sized files are compacted when there are four of them. However, when files gets larger, Cassandra waits with minor compactions. For example: four files are compacted to a 1GB file. There were already 3 other 1GB files. However, Cassandra does not immediately compact the four 1GB files. What makes Cassandra decide to wait with this minor compaction? Thank!
Re: Multiget question
2011/11/4 Filipe Gonçalves the.wa.syndr...@gmail.com: Multiget slice queries seem to fetch rows sequentially, at least fromwhat I understood of the sources. This means the node that receives amultiget of N keys does N get operations to the other nodes in thecluster to fetch the remaining keys. Am I right? Is this the way multiget works internally? The 'sequentially' is probably not right depending on what you meant by that (see below) but otherwise yes, a multiget of N keys is internally splitted into N gets. Also, shouldn't this be done in parallel, to avoid contacting nodesmore than once? It's done in parallel, in that the coordinating nodes send all the get requests in parallel. It doesn't wait for the result to the first get to issue the second one. But it does do every get separately, i.e. it may contact the same note multiple times. In theory we could do with at most one message to each node for each multiget. We don't do it because it would actually require quite a bit of change in the current code and it's unclear it would really buy us much. Since we already parallelize requests, we would mostly win a bit on network traffic (by merging messages) but there is good chance this is unsignificant (of course I could be wrong given we haven't tried). -- Sylvain -- Filipe Gonçalves
Re: Question about minor compaction
What makes Cassandra decide to wait with this minor compaction? What version do you using? There were some patch for 1.x branch which will do it as you expect. Cassandra 0.8 waited with compactions.
Re: Multiget question
Thanks for the answer. I hadn't realised requests were made in parallel, I first noticed it when multiget's took linear time in machines with high loads. Looking at the code led me to the previous conclusion (N gets for multiget for N keys). I agree it would take a major overhaul of the code to change the current behaviour, possiby more than it's worth for the potencial gains. 2011/11/4 Sylvain Lebresne sylv...@datastax.com: 2011/11/4 Filipe Gonçalves the.wa.syndr...@gmail.com: Multiget slice queries seem to fetch rows sequentially, at least fromwhat I understood of the sources. This means the node that receives amultiget of N keys does N get operations to the other nodes in thecluster to fetch the remaining keys. Am I right? Is this the way multiget works internally? The 'sequentially' is probably not right depending on what you meant by that (see below) but otherwise yes, a multiget of N keys is internally splitted into N gets. Also, shouldn't this be done in parallel, to avoid contacting nodesmore than once? It's done in parallel, in that the coordinating nodes send all the get requests in parallel. It doesn't wait for the result to the first get to issue the second one. But it does do every get separately, i.e. it may contact the same note multiple times. In theory we could do with at most one message to each node for each multiget. We don't do it because it would actually require quite a bit of change in the current code and it's unclear it would really buy us much. Since we already parallelize requests, we would mostly win a bit on network traffic (by merging messages) but there is good chance this is unsignificant (of course I could be wrong given we haven't tried). -- Sylvain -- Filipe Gonçalves -- Filipe Gonçalves
Re: Using Cli to create a column family with column name metadata question
[Moving to user@] Because Cassandra's sparse data model supports using rows as materialized views, having non-UTF8 column names is common and totally valid. On Fri, Nov 4, 2011 at 5:19 AM, Arsene Lee arsene@ruckuswireless.com wrote: Hi, I'm trying to use Column Family's metadata to do some validation. I found out that in Cassandra's CLI CliClient.java code when trying to create a column family with column name metadata. It is based on CF's comparator type to convert the name String to ByteBuffer. I'm wondering if there is any particular reason for this? For the column name metadata shouldn't it be easier just to all use UTF8Type. Because if CF's comparator is other than UTF8Type, it is hard to convert the column name back. Regards, Arsene Lee -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
RE: Question about minor compaction
I'm using Cassandra 0.7.9. Ok, so in this version, Cassandra waits with compaction. But when (in my original example) are the four 1GB files compacted? Thanks! -Original Message- From: Radim Kolar [mailto:h...@sendmail.cz] Sent: vrijdag 4 november 2011 15:55 To: user@cassandra.apache.org Subject: Re: Question about minor compaction What makes Cassandra decide to wait with this minor compaction? What version do you using? There were some patch for 1.x branch which will do it as you expect. Cassandra 0.8 waited with compactions.
Re: Question about minor compaction
Dne 4.11.2011 16:16, Rene Kochen napsal(a): I'm using Cassandra 0.7.9. Ok, so in this version, Cassandra waits with compaction. But when (in my original example) are the four 1GB files compacted? There are compacted when next file of similar size to 1 GB is created
RE: Question about minor compaction
Thanks for your quick response. I indeed see that similar sized files are compacted. However, for four similar 1GB files, this is not what I see. The documentation states: These parameters set thresholds for the number of similar-sized SSTables that can accumulate before a minor compaction is triggered. With the default values, a minor compaction may begin any time after four SSTables are created on disk for a column family, and must begin before 32 SSTables accumulate. So a more general question: In which situation does Cassandra not start a minor compaction immediately (when there are four similar sized files), but waits (up to 32)? Thanks! -Original Message- From: Radim Kolar [mailto:h...@sendmail.cz] Sent: vrijdag 4 november 2011 16:48 To: user@cassandra.apache.org Subject: Re: Question about minor compaction Dne 4.11.2011 16:16, Rene Kochen napsal(a): I'm using Cassandra 0.7.9. Ok, so in this version, Cassandra waits with compaction. But when (in my original example) are the four 1GB files compacted? There are compacted when next file of similar size to 1 GB is created
Re: Problem after upgrade to 1.0.1
One possibility: If you're overloading the cluster, replicas will drop updates to avoid OOMing. (This is logged at WARN level.) Before 1.x Cassandra would just let that slide, but with w/ 1.0 it started recording hints for those. On Thu, Nov 3, 2011 at 7:17 PM, Bryce Godfrey bryce.godf...@azaleos.com wrote: Thanks for the help so far. Is there any way to find out why my HintsColumnFamily is so large now, since it wasn't this way before the upgrade and it seems to just climbing? I've tried invoking o.a.c.db.HintedHnadoffManager.countPendingHints() thinking I have a bunch of stale hints from upgrade issues, but it just eventually times out. Plus the node it gets invoked against gets thrashed and stops responding, forcing me to restart cassandra. -Original Message- From: Jonathan Ellis [mailto:jbel...@gmail.com] Sent: Thursday, November 03, 2011 5:06 PM To: user@cassandra.apache.org Subject: Re: Problem after upgrade to 1.0.1 I found the problem and posted a patch on https://issues.apache.org/jira/browse/CASSANDRA-3451. If you build with that patch and rerun scrub the exception should go away. On Thu, Nov 3, 2011 at 2:08 PM, Bryce Godfrey bryce.godf...@azaleos.com wrote: A restart fixed the load numbers, they are back to where I expect them to be now, but disk utilization is double the load #. I'm also still get the cfstats exception from any node. -Original Message- From: Jonathan Ellis [mailto:jbel...@gmail.com] Sent: Thursday, November 03, 2011 11:52 AM To: user@cassandra.apache.org Subject: Re: Problem after upgrade to 1.0.1 Does restarting the node fix this? On Thu, Nov 3, 2011 at 1:51 PM, Bryce Godfrey bryce.godf...@azaleos.com wrote: Disk utilization is actually about 80% higher than what is reported for nodetool ring across all my nodes on the data drive Bryce Godfrey | Sr. Software Engineer | Azaleos Corporation | T: 206.926.1978 | M: 206.849.2477 From: Dan Hendry [mailto:dan.hendry.j...@gmail.com] Sent: Thursday, November 03, 2011 11:47 AM To: user@cassandra.apache.org Subject: RE: Problem after upgrade to 1.0.1 Regarding load growth, presumably you are referring to the load as reported by JMX/nodetool. Have you actually looked at the disk utilization on the nodes themselves? Potential issue I have seen: http://www.mail-archive.com/user@cassandra.apache.org/msg18142.html Dan From: Bryce Godfrey [mailto:bryce.godf...@azaleos.com] Sent: November-03-11 14:40 To: user@cassandra.apache.org Subject: Problem after upgrade to 1.0.1 I recently upgraded from 0.8.6 to 1.0.1 and everything seemed to go just fine with the rolling upgrade. But now I'm having extreme load growth on one of my nodes (and others are growing faster than usual also). I attempted to run a cfstats against the extremely large node that was seeing 2x the load of others and I get this error below. I'm also went into the o.a.c.db.HintedHandoffManager mbean and attempted to list pending hints to see if it was growing out of control for some reason, but that just times out eventually for any node. I'm not sure what to do next with this issue. Column Family: HintsColumnFamily SSTable count: 3 Space used (live): 12681676437 Space used (total): 10233130272 Number of Keys (estimate): 384 Memtable Columns Count: 117704 Memtable Data Size: 115107307 Memtable Switch Count: 66 Read Count: 0 Read Latency: NaN ms. Write Count: 21203290 Write Latency: 0.014 ms. Pending Tasks: 0 Key cache capacity: 3 Key cache size: 0 Key cache hit rate: NaN Row cache: disabled Compacted row minimum size: 30130993 Compacted row maximum size: 9223372036854775807 Exception in thread main java.lang.IllegalStateException: Unable to compute ceiling for max when histogram overflowed at org.apache.cassandra.utils.EstimatedHistogram.mean(EstimatedHistogram. java:170) at org.apache.cassandra.db.DataTracker.getMeanRowSize(DataTracker.java:3 9 5) at org.apache.cassandra.db.ColumnFamilyStore.getMeanRowSize(ColumnFamily S tore.java:293) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. j ava:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces s orImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMB e anIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMB e anIntrospector.java:27)
Re: Question about minor compaction
On Fri, Nov 4, 2011 at 5:22 PM, Rene Kochen rene.koc...@emea.schange.com wrote: Thanks for your quick response. I indeed see that similar sized files are compacted. However, for four similar 1GB files, this is not what I see. The documentation states: These parameters set thresholds for the number of similar-sized SSTables that can accumulate before a minor compaction is triggered. With the default values, a minor compaction may begin any time after four SSTables are created on disk for a column family, and must begin before 32 SSTables accumulate. So a more general question: In which situation does Cassandra not start a minor compaction immediately (when there are four similar sized files), but waits (up to 32)? Cassandra looks if there is minor compaction that can be started after each flush and after each compaction, so basically fairly regularly. So it should usually compact files as soon as it can. That being said compaction in 0.7.9 is mono-threaded so first it has to wait to other running compaction before starting. Then it needs 4 files in the same bucket (i.e have similar size), but it is possible that the sizes are such that one of the sstable is just a little bit too small or too big to be in the same bucket than the other three (in which case you'd have to wait for some other sstable to come fill that bucket). -- Sylvain Thanks! -Original Message- From: Radim Kolar [mailto:h...@sendmail.cz] Sent: vrijdag 4 november 2011 16:48 To: user@cassandra.apache.org Subject: Re: Question about minor compaction Dne 4.11.2011 16:16, Rene Kochen napsal(a): I'm using Cassandra 0.7.9. Ok, so in this version, Cassandra waits with compaction. But when (in my original example) are the four 1GB files compacted? There are compacted when next file of similar size to 1 GB is created
Re: Question about minor compaction
On Fri, Nov 4, 2011 at 6:01 PM, Rene Kochen rene.koc...@emea.schange.com wrote: Thanks for this very clear explanation. Could it be that Cassandra does not begin a minor compaction if there is memory pressure? No (and in 0.7 Cassandra really does nothing specific under memory pressure except being constantly interrupted by the GC. But even in 1.0, compaction is not one of the thing affected by the memory pressure valves in place). It can not being a compaction because it thinks that it won't have enough disk space to do the compaction, but you'll have a message in the log if that happens. -- Sylvain -Original Message- From: Sylvain Lebresne [mailto:sylv...@datastax.com] Sent: vrijdag 4 november 2011 17:48 To: user@cassandra.apache.org Subject: Re: Question about minor compaction On Fri, Nov 4, 2011 at 5:22 PM, Rene Kochen rene.koc...@emea.schange.com wrote: Thanks for your quick response. I indeed see that similar sized files are compacted. However, for four similar 1GB files, this is not what I see. The documentation states: These parameters set thresholds for the number of similar-sized SSTables that can accumulate before a minor compaction is triggered. With the default values, a minor compaction may begin any time after four SSTables are created on disk for a column family, and must begin before 32 SSTables accumulate. So a more general question: In which situation does Cassandra not start a minor compaction immediately (when there are four similar sized files), but waits (up to 32)? Cassandra looks if there is minor compaction that can be started after each flush and after each compaction, so basically fairly regularly. So it should usually compact files as soon as it can. That being said compaction in 0.7.9 is mono-threaded so first it has to wait to other running compaction before starting. Then it needs 4 files in the same bucket (i.e have similar size), but it is possible that the sizes are such that one of the sstable is just a little bit too small or too big to be in the same bucket than the other three (in which case you'd have to wait for some other sstable to come fill that bucket). -- Sylvain Thanks! -Original Message- From: Radim Kolar [mailto:h...@sendmail.cz] Sent: vrijdag 4 november 2011 16:48 To: user@cassandra.apache.org Subject: Re: Question about minor compaction Dne 4.11.2011 16:16, Rene Kochen napsal(a): I'm using Cassandra 0.7.9. Ok, so in this version, Cassandra waits with compaction. But when (in my original example) are the four 1GB files compacted? There are compacted when next file of similar size to 1 GB is created
Re: Debian package jna bug workaroung
The cassandra-cli tool will show you, if you're using at least cassandra 1.0.1, in a describe command. If not, you can make a thrift describe_keyspace() call some other way, and check the value of the appropriate CfDef's row_cache_provider string. If it's SerializingCacheProvider, it's off-heap. Note that I think you need to create the columnfamily while JNA is present, not just have JNA present when cassandra starts. Might be wrong on that. p On Thu, Nov 3, 2011 at 4:10 PM, Peter Tillotson slatem...@yahoo.co.ukwrote: Cassandra 1.0.1 and only seemed to happen with * JAVA_HOME=/usr/lib/jvm/java-6-sun and jna.jar copied into /usr/share/cassandra(/lib) I then saw the detail in the init script and how it was being linked Is there a way I can verify which provider is being used? I want to make sure Off heap is being used in the default config. On 03/11/11 19:06, paul cannon wrote: I can't reproduce this. What version of the cassandra deb are you using, exactly, and why are you symlinking or copying jna.jar into /usr/share/cassandra? The initscript should be adding /usr/sahre/java/jna.jar to the classpath, and that should be all you need. The failure you see with o.a.c.cache.FreeableMemory is not because the jre can't find the class, it's just that it can't initialize the class (because it needs JNA, and it can't find JNA). p On Wed, Nov 2, 2011 at 4:42 AM, Peter Tillotson slatem...@yahoo.co.uk mailto:slatem...@yahoo.co.uk wrote: see below * JAVA_HOME=/usr/lib/jvm/java-6-openjdk works -- Reading the documentation over at Datastax “The Debian and RPM packages of Cassandra install JNA automatically” http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-improved-memory-and-disk-space-management And indeed the Debian package depends on jna, and the /etc/init.d/cassandra looks as though in adds /usr/share/java/jna.jar to the classpath, and here is the but. If I copy or symlink jna.jar into: * /usr/share/cassandra * /usr/share/cassandra/lib Whenever a column family initialises I get: java.lang.NoClassDefFoundError: Could not initialize class org.apache.cassandra.cache.FreeableMemory This suggests to me that: 1) By default, for me at least, in Debian jna.jar is not on the classpath 2) There is an additional classpath issue jar -tf apache-cassandra.jar | grep FreeableMemory succeeds I'm running on: * Ubuntu 10.04 x64 * JAVA_HOME=/usr/lib/jvm/java-6-sun Full stack traces: java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native at com.sun.jna.Pointer.clinit(Pointer.java:42) at org.apache.cassandra.cache.SerializingCache.serialize(SerializingCache.java:92) at org.apache.cassandra.cache.SerializingCache.put(SerializingCache.java:154) at org.apache.cassandra.cache.InstrumentingCache.put(InstrumentingCache.java:63) at org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1150) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1174) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1131) at org.apache.cassandra.db.Table.getRow(Table.java:378) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:61) at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:797) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1265) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) INFO [pool-1-thread-1] 2011-11-02 10:26:46,738 Memtable.java (line 177) CFS(Keyspace='BigSet', ColumnFamily='theKeys') liveRatio is 18.20062753783684 (just-counted was 16.960966424636872). calculation took 408ms for 8169 columns ERROR [ReadStage:33] 2011-11-02 10:26:56,599 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[ReadStage:33,5,main] java.lang.NoClassDefFoundError: Could not initialize class org.apache.cassandra.cache.FreeableMemory at org.apache.cassandra.cache.SerializingCache.serialize(SerializingCache.java:92) at org.apache.cassandra.cache.SerializingCache.put(SerializingCache.java:154) at org.apache.cassandra.cache.InstrumentingCache.put(InstrumentingCache.java:63) at org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1150) at
Re: Why SSTable is sorted by tokens instead of row keys?
On Fri, Nov 4, 2011 at 7:49 AM, Gary Shi gary...@gmail.com wrote: I want to save time series event logs into Cassandra, and I need to load them by key range (row key is time-based). But we can't use RandomPartitioner in this way, while OrderPreservingPartitioner leads to hot spot problem. You should read this: http://rubyscale.com/2011/basic-time-series-with-cassandra/ -Brandon
Cassandra Integration w/ SOLR using Virgil
Up front, I'd like to say this is still pretty raw. We'd love to get feedback (and better yet contributions ;). With that as a disclaimer, I added SOLR integration to Virgil. When you add and delete rows and columns via the REST interface, an index is updated in SOLR. For more information check out: http://code.google.com/a/apache-extras.org/p/virgil/wiki/solr Let me know what you guys think. -brian -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://weblogs.java.net/blog/boneill42/ blog: http://brianoneill.blogspot.com/
The use of SuperColumns
There have been mentions that the use of SuperColumns is not really encouraged, recommendation to use composite columns instead. Will SuperColumns be removed. Any comments greatly appreciated. --- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
Re: Why SSTable is sorted by tokens instead of row keys?
Thank you. I agree that request lots of machines process a single query could be slow, if there are hundreds of them instead of dozens. Will a cluster of e.g. 4-20 nodes behave well if we spread the query to all nodes? Many articles suggest model TimeUUID in columns instead of rows, but since only one node can serve a single row, won't this lead to hot spot problems? 在 2011-11-4 晚上10:28，Sylvain Lebresne sylv...@datastax.com写道： On Fri, Nov 4, 2011 at 1:49 PM, Gary Shi gary...@gmail.com wrote: I want to save time series event logs into Cassandra, and I need to load them by key range (row key is time-based). But we can't use RandomPartitioner in this way, while OrderPreservingPartitioner leads to hot spot problem. So I wonder why Cassandra save SSTable by sorted row tokens instead of keys: if rows in SSTable are sorted by keys, it should be quite easy to return rows by key range -- token should be used to determine which node contains the data. For key range requests, Cassandra could ask every node for that range of rows, merge them and return to the caller. Without going for exhaustiveness: - Requesting every node is not too scalable. Cassandra is built to target the 'lots of cheap machines' kind of cluster, so that kind of operation is going the exact opposite way. In other words, that would be slow enough that you're better off modeling this using columns for time series. - That would make topology operations (bootstrap, move, decommission) much more costly, because we wouldn't be able to tell which keys to move unless we iterate over all the data each time. -- Sylvain -- regards, Gary Shi
Re: Second Cassandra users survey
- Bulk column deletion by (column name) range. Without this feature, we are forced to perform a range query and iterate over all of the columns, deleting them one by one (we do this in a batch, but it's still a very slow approach). See CASSANDRA-494/3448. If anyone else has a need for this issue, please raise your voice, as the feature has been tabled due to lack of interest. On 11/3/2011 11:44 AM, Todd Burruss wrote: - Better performance when access random columns in a wide row - caching subsets of wide rows - possibly on the same boundaries as the index - some sort of notification architecture when data is inserted. This could be co-processors, triggers, plugins, etc - auto load balance when adding new nodes On 11/1/11 3:59 PM, Jonathan Ellisjbel...@gmail.com wrote: Hi all, Two years ago I asked for Cassandra use cases and feature requests. [1] The results [2] have been extremely useful in setting and prioritizing goals for Cassandra development. But with the release of 1.0 we've accomplished basically everything from our original wish list. [3] I'd love to hear from modern Cassandra users again, especially if you're usually a quiet lurker. What does Cassandra do well? What are your pain points? What's your feature wish list? As before, if you're in stealth mode or don't want to say anything in public, feel free to reply to me privately and I will keep it off the record. [1] http://www.mail-archive.com/cassandra-dev@incubator.apache.org/msg01148.ht ml [2] http://www.mail-archive.com/cassandra-user@incubator.apache.org/msg01446.h tml [3] http://www.mail-archive.com/dev@cassandra.apache.org/msg01524.html -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Second Cassandra users survey
On Fri, Nov 4, 2011 at 9:19 PM, Jim Newsham jnews...@referentia.com wrote: - Bulk column deletion by (column name) range. Without this feature, we are forced to perform a range query and iterate over all of the columns, deleting them one by one (we do this in a batch, but it's still a very slow approach). See CASSANDRA-494/3448. If anyone else has a need for this issue, please raise your voice, as the feature has been tabled due to lack of interest. I think the lack of interest here has been this: it's unusual to want to delete columns for which you do not know the names, but also not want to delete the entire row. Is there any chance you're trying to delete the entire row, or is it truly the case I just described? -Brandon
Re: Second Cassandra users survey
On 11/4/2011 4:32 PM, Brandon Williams wrote: On Fri, Nov 4, 2011 at 9:19 PM, Jim Newshamjnews...@referentia.com wrote: - Bulk column deletion by (column name) range. Without this feature, we are forced to perform a range query and iterate over all of the columns, deleting them one by one (we do this in a batch, but it's still a very slow approach). See CASSANDRA-494/3448. If anyone else has a need for this issue, please raise your voice, as the feature has been tabled due to lack of interest. I think the lack of interest here has been this: it's unusual to want to delete columns for which you do not know the names, but also not want to delete the entire row. Is there any chance you're trying to delete the entire row, or is it truly the case I just described? -Brandon Our use case is time-series data (such as sampled sensor data). Each row describes a particular statistic over time, the column name is a time, and the column value is the sample. So it makes perfect sense to want to delete columns for a given time range. I'm sure there must be numerous other use cases for which using a range of column names makes sense. Regards, Jim
