Re: 2014 nosql benchmark
Today I've also seen this benchmark in Chinese websites. SequoiaDB seems come from a Chinese startup company, and in db-engines ranking http://db-engines.com/en/ranking it's score is 0.00. So IMO I have to say I think this benchmark is a soft sell. They compare three databases, two written by c++ and one by java, and use a very tricky testcase to make Cassandra can not hold all data in memtables. After all, java need more memory than c++. For a on-disk database, generally data size of one node is much larger than RAM, and it's performance of memory query is less important than disk query. So I think this benchmark have no value at all. 2014-12-19 14:47 GMT+08:00 Wilm Schumacher wilm.schumac...@gmail.com: Hi, I'm always interessted in such benchmark experiments, because the databases evolve so fast, that the race is always open and there is a lot motion in there. And of course I askes myself the same question. And I think that this publication is unreliable. For 4 reasons (from reading very fast, perhaps there is more): 1.) It is unclear what this is all about. The title is NoSQL Performance Testing. The subtitle is In-Memory Performance Comparison of SequoiaDB, Cassandra, and MongoDB. However, in the introduction there is not one word about in memory performance. The introduction could be a general introduction for a general on-disk-nosql benchmark. So ... only the subtitle (and a short sentence in the Result Summary) says what this is actually about. 2.) There are very important databases missing. For in memory e.g. redis. If e.g. redis is not a valid candidate in this race, why is this so?MySQL is capable of in memory distributed databanking, too. 3.) The methodology is unclear. Perhaps I'm the only one, but what does Run workload for 30 minutes (workload file workload[1-5]) mean for mixed read/write ops? Why 30 min? Okay, I can image, that the authors estimated the throughput, preset the number of 100 Mio rows and designed it to be larger than the estimated throughput in x minutes. However, all this information is missing. And why 45% and 22% of RAM? My first Idea would be a VERY low ration, like 2% or so, and a VERY large ratio, like 80-90%. And than everything in between. Is 22% or 45% somehow a magic number? Furthermore in the Result summary there 1/2 and 1/4 of RAM are discussed. Okay, 22% is near 1/4 ... but where does the difference origin from? And btw. ... 22% of what? Stuff to insert? Stuff already insererted? It's all deductable, but it's strange that the description is so sloppy. 4.) There is no repetion of the loads (as I understand). Its one run, one result ... and it's done. I don't know a lot of cassandra in in-memory use. But either the experiment should be repeated quite some runs OR it should be explained why this is not neccessary. Okay, perhaps 1 is a little picky, and 4 is a little fussy. But 3 is strange and 2 stinks. Well, just my first impression. And that's Cassandra is very fast ;). Best regards Wilm Am 19.12.2014 um 06:41 schrieb diwayou: i just have read this benchmark pdf, does anyone have some opinion about this? i think it's not fair about cassandra url: http://www.bankmark.de/wp-content/uploads/2014/12/bankmark-20141201-WP-NoSQLBenchmark.pdf http://msrg.utoronto.ca/papers/NoSQLBenchmark
Re: full gc too often
2014-12-05 15:40 GMT+08:00 Jonathan Haddad j...@jonhaddad.com: I recommend reading through https://issues.apache.org/jira/browse/CASSANDRA-8150 to get an idea of how the JVM GC works and what you can do to tune it. Also good is Blake Eggleston's writeup which can be found here: http://blakeeggleston.com/cassandra-tuning-the-jvm-for-read-heavy-workloads.html I'd like to note that allocating 4GB heap to Cassandra under any serious workload is unlikely to be sufficient. Thanks for your recommendation. After reading I try to allocate a larger heap and it is useful for me. 4G heap can't handle the workload in my use case indeed. So another question is, how much pressure dose default max heap (8G) can handle? The pressure may not be a simple qps, you know, slice query for many columns in a row will allocate more objects in heap than the query for a single column. Is there any testing result for the relationship between the pressure and the safety heap size? We know query a slice with many tombstones is not a good use case, but query a slice without tombstones may be a common use case, right? On Thu Dec 04 2014 at 8:43:38 PM Philo Yang ud1...@gmail.com wrote: I have two kinds of machine: 16G RAM, with default heap size setting, about 4G. 64G RAM, with default heap size setting, about 8G. These two kinds of nodes have same number of vnodes, and both of them have gc issue, although the node of 16G have a higher probability of gc issue. Thanks, Philo Yang 2014-12-05 12:34 GMT+08:00 Tim Heckman t...@pagerduty.com: On Dec 4, 2014 8:14 PM, Philo Yang ud1...@gmail.com wrote: Hi,all I have a cluster on C* 2.1.1 and jdk 1.7_u51. I have a trouble with full gc that sometime there may be one or two nodes full gc more than one time per minute and over 10 seconds each time, then the node will be unreachable and the latency of cluster will be increased. I grep the GCInspector's log, I found when the node is running fine without gc trouble there are two kinds of gc: ParNew GC in less than 300ms which clear the Par Eden Space and enlarge CMS Old Gen/ Par Survivor Space little (because it only show gc in more than 200ms, there is only a small number of ParNew GC in log) ConcurrentMarkSweep in 4000~8000ms which reduce CMS Old Gen much and enlarge Par Eden Space little, each 1-2 hours it will be executed once. However, sometimes ConcurrentMarkSweep will be strange like it shows: INFO [Service Thread] 2014-12-05 11:28:44,629 GCInspector.java:142 - ConcurrentMarkSweep GC in 12648ms. CMS Old Gen: 3579838424 - 3579838464; Par Eden Space: 503316480 - 294794576; Par Survivor Space: 62914528 - 0 INFO [Service Thread] 2014-12-05 11:28:59,581 GCInspector.java:142 - ConcurrentMarkSweep GC in 12227ms. CMS Old Gen: 3579838464 - 3579836512; Par Eden Space: 503316480 - 310562032; Par Survivor Space: 62872496 - 0 INFO [Service Thread] 2014-12-05 11:29:14,686 GCInspector.java:142 - ConcurrentMarkSweep GC in 11538ms. CMS Old Gen: 3579836688 - 3579805792; Par Eden Space: 503316480 - 332391096; Par Survivor Space: 62914544 - 0 INFO [Service Thread] 2014-12-05 11:29:29,371 GCInspector.java:142 - ConcurrentMarkSweep GC in 12180ms. CMS Old Gen: 3579835784 - 3579829760; Par Eden Space: 503316480 - 351991456; Par Survivor Space: 62914552 - 0 INFO [Service Thread] 2014-12-05 11:29:45,028 GCInspector.java:142 - ConcurrentMarkSweep GC in 10574ms. CMS Old Gen: 3579838112 - 3579799752; Par Eden Space: 503316480 - 366222584; Par Survivor Space: 62914560 - 0 INFO [Service Thread] 2014-12-05 11:29:59,546 GCInspector.java:142 - ConcurrentMarkSweep GC in 11594ms. CMS Old Gen: 3579831424 - 3579817392; Par Eden Space: 503316480 - 388702928; Par Survivor Space: 62914552 - 0 INFO [Service Thread] 2014-12-05 11:30:14,153 GCInspector.java:142 - ConcurrentMarkSweep GC in 11463ms. CMS Old Gen: 3579817392 - 3579838424; Par Eden Space: 503316480 - 408992784; Par Survivor Space: 62896720 - 0 INFO [Service Thread] 2014-12-05 11:30:25,009 GCInspector.java:142 - ConcurrentMarkSweep GC in 9576ms. CMS Old Gen: 3579838424 - 3579816424; Par Eden Space: 503316480 - 438633608; Par Survivor Space: 62914544 - 0 INFO [Service Thread] 2014-12-05 11:30:39,929 GCInspector.java:142 - ConcurrentMarkSweep GC in 11556ms. CMS Old Gen: 3579816424 - 3579785496; Par Eden Space: 503316480 - 441354856; Par Survivor Space: 62889528 - 0 INFO [Service Thread] 2014-12-05 11:30:54,085 GCInspector.java:142 - ConcurrentMarkSweep GC in 12082ms. CMS Old Gen: 3579786592 - 3579814464; Par Eden Space: 503316480 - 448782440; Par Survivor Space: 62914560 - 0 In each time Old Gen reduce only a little, Survivor Space will be clear but the heap is still full so there will be another full gc very soon then the node will down. If I restart the node, it will be fine without gc trouble. Can anyone help me to find out where is the problem that full gc can't reduce CMS Old Gen
full gc too often
Hi,all I have a cluster on C* 2.1.1 and jdk 1.7_u51. I have a trouble with full gc that sometime there may be one or two nodes full gc more than one time per minute and over 10 seconds each time, then the node will be unreachable and the latency of cluster will be increased. I grep the GCInspector's log, I found when the node is running fine without gc trouble there are two kinds of gc: ParNew GC in less than 300ms which clear the Par Eden Space and enlarge CMS Old Gen/ Par Survivor Space little (because it only show gc in more than 200ms, there is only a small number of ParNew GC in log) ConcurrentMarkSweep in 4000~8000ms which reduce CMS Old Gen much and enlarge Par Eden Space little, each 1-2 hours it will be executed once. However, sometimes ConcurrentMarkSweep will be strange like it shows: INFO [Service Thread] 2014-12-05 11:28:44,629 GCInspector.java:142 - ConcurrentMarkSweep GC in 12648ms. CMS Old Gen: 3579838424 - 3579838464; Par Eden Space: 503316480 - 294794576; Par Survivor Space: 62914528 - 0 INFO [Service Thread] 2014-12-05 11:28:59,581 GCInspector.java:142 - ConcurrentMarkSweep GC in 12227ms. CMS Old Gen: 3579838464 - 3579836512; Par Eden Space: 503316480 - 310562032; Par Survivor Space: 62872496 - 0 INFO [Service Thread] 2014-12-05 11:29:14,686 GCInspector.java:142 - ConcurrentMarkSweep GC in 11538ms. CMS Old Gen: 3579836688 - 3579805792; Par Eden Space: 503316480 - 332391096; Par Survivor Space: 62914544 - 0 INFO [Service Thread] 2014-12-05 11:29:29,371 GCInspector.java:142 - ConcurrentMarkSweep GC in 12180ms. CMS Old Gen: 3579835784 - 3579829760; Par Eden Space: 503316480 - 351991456; Par Survivor Space: 62914552 - 0 INFO [Service Thread] 2014-12-05 11:29:45,028 GCInspector.java:142 - ConcurrentMarkSweep GC in 10574ms. CMS Old Gen: 3579838112 - 3579799752; Par Eden Space: 503316480 - 366222584; Par Survivor Space: 62914560 - 0 INFO [Service Thread] 2014-12-05 11:29:59,546 GCInspector.java:142 - ConcurrentMarkSweep GC in 11594ms. CMS Old Gen: 3579831424 - 3579817392; Par Eden Space: 503316480 - 388702928; Par Survivor Space: 62914552 - 0 INFO [Service Thread] 2014-12-05 11:30:14,153 GCInspector.java:142 - ConcurrentMarkSweep GC in 11463ms. CMS Old Gen: 3579817392 - 3579838424; Par Eden Space: 503316480 - 408992784; Par Survivor Space: 62896720 - 0 INFO [Service Thread] 2014-12-05 11:30:25,009 GCInspector.java:142 - ConcurrentMarkSweep GC in 9576ms. CMS Old Gen: 3579838424 - 3579816424; Par Eden Space: 503316480 - 438633608; Par Survivor Space: 62914544 - 0 INFO [Service Thread] 2014-12-05 11:30:39,929 GCInspector.java:142 - ConcurrentMarkSweep GC in 11556ms. CMS Old Gen: 3579816424 - 3579785496; Par Eden Space: 503316480 - 441354856; Par Survivor Space: 62889528 - 0 INFO [Service Thread] 2014-12-05 11:30:54,085 GCInspector.java:142 - ConcurrentMarkSweep GC in 12082ms. CMS Old Gen: 3579786592 - 3579814464; Par Eden Space: 503316480 - 448782440; Par Survivor Space: 62914560 - 0 In each time Old Gen reduce only a little, Survivor Space will be clear but the heap is still full so there will be another full gc very soon then the node will down. If I restart the node, it will be fine without gc trouble. Can anyone help me to find out where is the problem that full gc can't reduce CMS Old Gen? Is it because there are too many objects in heap can't be recycled? I think review the table scheme designing and add new nodes into cluster is a good idea, but I still want to know if there is any other reason causing this trouble. Thanks, Philo Yang
Re: full gc too often
I have two kinds of machine: 16G RAM, with default heap size setting, about 4G. 64G RAM, with default heap size setting, about 8G. These two kinds of nodes have same number of vnodes, and both of them have gc issue, although the node of 16G have a higher probability of gc issue. Thanks, Philo Yang 2014-12-05 12:34 GMT+08:00 Tim Heckman t...@pagerduty.com: On Dec 4, 2014 8:14 PM, Philo Yang ud1...@gmail.com wrote: Hi,all I have a cluster on C* 2.1.1 and jdk 1.7_u51. I have a trouble with full gc that sometime there may be one or two nodes full gc more than one time per minute and over 10 seconds each time, then the node will be unreachable and the latency of cluster will be increased. I grep the GCInspector's log, I found when the node is running fine without gc trouble there are two kinds of gc: ParNew GC in less than 300ms which clear the Par Eden Space and enlarge CMS Old Gen/ Par Survivor Space little (because it only show gc in more than 200ms, there is only a small number of ParNew GC in log) ConcurrentMarkSweep in 4000~8000ms which reduce CMS Old Gen much and enlarge Par Eden Space little, each 1-2 hours it will be executed once. However, sometimes ConcurrentMarkSweep will be strange like it shows: INFO [Service Thread] 2014-12-05 11:28:44,629 GCInspector.java:142 - ConcurrentMarkSweep GC in 12648ms. CMS Old Gen: 3579838424 - 3579838464; Par Eden Space: 503316480 - 294794576; Par Survivor Space: 62914528 - 0 INFO [Service Thread] 2014-12-05 11:28:59,581 GCInspector.java:142 - ConcurrentMarkSweep GC in 12227ms. CMS Old Gen: 3579838464 - 3579836512; Par Eden Space: 503316480 - 310562032; Par Survivor Space: 62872496 - 0 INFO [Service Thread] 2014-12-05 11:29:14,686 GCInspector.java:142 - ConcurrentMarkSweep GC in 11538ms. CMS Old Gen: 3579836688 - 3579805792; Par Eden Space: 503316480 - 332391096; Par Survivor Space: 62914544 - 0 INFO [Service Thread] 2014-12-05 11:29:29,371 GCInspector.java:142 - ConcurrentMarkSweep GC in 12180ms. CMS Old Gen: 3579835784 - 3579829760; Par Eden Space: 503316480 - 351991456; Par Survivor Space: 62914552 - 0 INFO [Service Thread] 2014-12-05 11:29:45,028 GCInspector.java:142 - ConcurrentMarkSweep GC in 10574ms. CMS Old Gen: 3579838112 - 3579799752; Par Eden Space: 503316480 - 366222584; Par Survivor Space: 62914560 - 0 INFO [Service Thread] 2014-12-05 11:29:59,546 GCInspector.java:142 - ConcurrentMarkSweep GC in 11594ms. CMS Old Gen: 3579831424 - 3579817392; Par Eden Space: 503316480 - 388702928; Par Survivor Space: 62914552 - 0 INFO [Service Thread] 2014-12-05 11:30:14,153 GCInspector.java:142 - ConcurrentMarkSweep GC in 11463ms. CMS Old Gen: 3579817392 - 3579838424; Par Eden Space: 503316480 - 408992784; Par Survivor Space: 62896720 - 0 INFO [Service Thread] 2014-12-05 11:30:25,009 GCInspector.java:142 - ConcurrentMarkSweep GC in 9576ms. CMS Old Gen: 3579838424 - 3579816424; Par Eden Space: 503316480 - 438633608; Par Survivor Space: 62914544 - 0 INFO [Service Thread] 2014-12-05 11:30:39,929 GCInspector.java:142 - ConcurrentMarkSweep GC in 11556ms. CMS Old Gen: 3579816424 - 3579785496; Par Eden Space: 503316480 - 441354856; Par Survivor Space: 62889528 - 0 INFO [Service Thread] 2014-12-05 11:30:54,085 GCInspector.java:142 - ConcurrentMarkSweep GC in 12082ms. CMS Old Gen: 3579786592 - 3579814464; Par Eden Space: 503316480 - 448782440; Par Survivor Space: 62914560 - 0 In each time Old Gen reduce only a little, Survivor Space will be clear but the heap is still full so there will be another full gc very soon then the node will down. If I restart the node, it will be fine without gc trouble. Can anyone help me to find out where is the problem that full gc can't reduce CMS Old Gen? Is it because there are too many objects in heap can't be recycled? I think review the table scheme designing and add new nodes into cluster is a good idea, but I still want to know if there is any other reason causing this trouble. How much total system memory do you have? How much is allocated for heap usage? How big is your working data set? The reason I ask is that I've seen problems with lots of GC with no room gained, and it was memory pressure. Not enough for the heap. We decided that just increasing the heap size was a bad idea, as we did rely on free RAM being used for filesystem caching. So some vertical and horizontal scaling allowed us to give Cass more heap space, as well as distribute the workload to try and avoid further problems. Thanks, Philo Yang Cheers! -Tim
RangeTombstoneList.diff AssertionError in 2.1.0
Hi,all after upgrading to 2.1.0, I found there are many exceptions in system.log. It appears in nodes upgraded from 2.0 as well as in nodes newly added at 2.1.0. When I set the read repair chance to 0.0, it disappears. ERROR [SharedPool-Worker-8] 2014-09-27 16:44:50,188 ErrorMessage.java:218 - Unexpected exception during request java.lang.AssertionError: null at org.apache.cassandra.db.RangeTombstoneList.diff(RangeTombstoneList.java:424) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.db.DeletionInfo.diff(DeletionInfo.java:189) ~ [apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.db.ColumnFamily.diff(ColumnFamily.java:311) ~ [apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.db.ColumnFamily.diff(ColumnFamily.java:394) ~ [apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.service.RowDataResolver.scheduleRepairs(RowDataResolver.java:114) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.service.RowDataResolver.resolve(RowDataResolver.java:91) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.service.RowDataResolver.resolve(RowDataResolver.java:37) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:110) ~ [apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1300) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1153) ~ [apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.service.pager.SliceQueryPager.queryNextPage(SliceQueryPager.java:83) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:88) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.service.pager.SliceQueryPager.fetchPage(SliceQueryPager.java:36) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:60) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:187) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:206) ~ [apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:118) ~[apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:422) [apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:318) [apache-cassandra-2.1.0.jar:2.1.0] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:103) [netty-all-4.0.20.Final.jar:4.0.20.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332) [netty-all-4.0.20.Final.jar:4.0.20.Final] at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:31) [netty-all-4.0.20.Final.jar:4.0.20.Final] at io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:323) [netty-all-4.0.20.Final.jar:4.0.20.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_51] at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:163) [apache-cassandra-2.1.0.jar:2.1.0] at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103) [apache-cassandra-2.1.0.jar:2.1.0] at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51] I have also posted this issue on JIRA https://issues.apache.org/jira/browse/CASSANDRA-8013 Thanks, Philo Yang
Re: why bloom filter is only for row key?
Thanks Rob Thanks, Philo Yang 2014-09-16 2:12 GMT+08:00 DuyHai Doan doanduy...@gmail.com: Nice catch Rob On Mon, Sep 15, 2014 at 8:04 PM, Robert Coli rc...@eventbrite.com wrote: On Sun, Sep 14, 2014 at 11:22 AM, Philo Yang ud1...@gmail.com wrote: After reading some docs, I find that bloom filter is built on row keys, not on column key. Can anyone tell me what is considered for not building bloom filter on column key? Is it a good idea to offer a table property option between row key and primary key for what boolm filter is built on? Here's the nitty gritty of the process which removed the row-level bloom filter on column keys. https://issues.apache.org/jira/browse/CASSANDRA-4885 - Remove or rework per-row bloom filters =Rob http://twitter.com/rcolidba
Re: why bloom filter is only for row key?
Thanks DuyHai, I think the trouble of bloom filter on all row keys column names is memory usage. However, if a CF has only hundreds of columns per row, the number of total columns will be much fewer, so the bloom filter is possible for this condition, right? Is there a good way to adjust bloom filter's property between row keys and row keys+column names automatically or by user's config? Thanks, Philo Yang 2014-09-15 2:45 GMT+08:00 DuyHai Doan doanduy...@gmail.com: Hello Philo Building bloom filter for column names (what you call column key) is technically possible but very expensive in term of memory usage. The approximate formula to calculate space required by bloom filter can be found on slide 27 here: http://fr.slideshare.net/quipo/modern-algorithms-and-data-structures-1-bloom-filters-merkle-trees false positive chance = 0.6185 * m/n where m = number of bits for the filter and n = number of distinct keys For example, if you want to index 1 million of rows, each having 100 000 columns on average, it will end up indexing 100 billions of keys (row keys column names) with bloom filter. By applying the above formula, m ≈ 4.8 * 10^11 bits ≈ 60Gb to allocate in RAM just for bloom filter on all row keys column names ... Regards Duy Hai DOAN On Sun, Sep 14, 2014 at 11:22 AM, Philo Yang ud1...@gmail.com wrote: Hi all, After reading some docs, I find that bloom filter is built on row keys, not on column key. Can anyone tell me what is considered for not building bloom filter on column key? Is it a good idea to offer a table property option between row key and primary key for what boolm filter is built on? Thanks, Philo Yang
why bloom filter is only for row key?
Hi all, After reading some docs, I find that bloom filter is built on row keys, not on column key. Can anyone tell me what is considered for not building bloom filter on column key? Is it a good idea to offer a table property option between row key and primary key for what boolm filter is built on? Thanks, Philo Yang
Re: Best practices for frequently updated columns
The write performance of INSERT or UPDATE is very high in C*, but if you update too often the row you update frequently will be in many SSTables so the read latency and system load will be increased until these SSTables are compacted into one single file. I think you can use redis (or memcache) to cache the read request. Write into C* and redis both and read only from redis for the latest bar. Read from C* for previous bars if the memory size is bottleneck. Thanks, Philo Yang 2014-08-14 2:13 GMT+08:00 Robert Coli rc...@eventbrite.com: On Wed, Aug 13, 2014 at 8:01 AM, Jeremy Jongsma jer...@barchart.com wrote: I've read comments about frequent column updates causing compaction issues with Cassandra. What is the recommended Cassandra configuration / best practices for usage scenarios like this? If your data is frequently UPDATEd, perhaps a log structured database with immutable data files is not for you? =Rob
select many rows one time or select many times?
Hi all,
I have a cluster of 2.0.6 and one of my tables is like this:
CREATE TABLE word (
user text,
word text,
flag double,
PRIMARY KEY (user, word)
)
each user has about 1 word per node. I have a requirement of
selecting all rows where user='someuser' and word is in a large set whose
size is about 1000 .
In C* document, it is not recommended to use select ... in just like:
select from word where user='someuser' and word in ('a','b','aa','ab',...)
So now I select all rows where user='someuser' and filtrate them via client
rather than via C*. Of course, I use Datastax Java Driver to page the
resultset by setFetchSize(1000). Is it the best way? I found the system's
load is high because of large range query, should I change to select for
only one row each time and select 1000 times?
just like:
select from word where user='someuser' and word = 'a';
select from word where user='someuser' and word = 'b';
select from word where user='someuser' and word = 'c';
.
Which method will cause lower pressure on Cassandra cluster?
Thanks,
Philo Yang
Re: ghost table is breaking compactions and won't go away… even during a drop.
In my experience, SSTable FileNotFoundException, not only caused by recreate a table but also other operations or even bug, cannot be solved by any nodetool command. However, restart the node for more than one time can make this Exception disappear. I don't know the reason but it does work... Thanks, Philo Yang 2014-07-17 10:32 GMT+08:00 Kevin Burton bur...@spinn3r.com: you rock… glad it's fixed in 2.1… :) On Wed, Jul 16, 2014 at 7:05 PM, graham sanderson gra...@vast.com wrote: Known issue deleting and recreating a CF with the same name, fixed in 2.1 (manifests in lots of ways) https://issues.apache.org/jira/browse/CASSANDRA-5202 On Jul 16, 2014, at 8:53 PM, Kevin Burton bur...@spinn3r.com wrote: looks like a restart of cassandra and a nodetool compact fixed this… On Wed, Jul 16, 2014 at 6:45 PM, Kevin Burton bur...@spinn3r.com wrote: this is really troubling… I have a ghost table. I dropped it.. but it's not going away. (Cassandra 2.0.8 btw) I ran a 'drop table' on it.. then a 'describe tables' shows that it's not there. However, when I recreated it, with a new schema, all operations on it failed. Looking at why… it seems that cassandra had some old SSTables that I imagine are no longer being used but are now in an inconsistent state? This is popping up in the system.log: Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: /d0/cassandra/data/blogindex/content_idx_source_hashcode/blogindex-content_idx_source_hashcode-jb-1447-Data.db (No such file or directory) so I think what happened… is that the original drop table, failed, and then left things in an inconsistent state. I tried a nodetool repair and a nodetool compact… those fail on the same java.io.FileNotFoundException … I moved the directories out of the way, same failure issue. … any advice on resolving this? -- Founder/CEO Spinn3r.com http://spinn3r.com/ Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com/ -- Founder/CEO Spinn3r.com http://spinn3r.com/ Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com/ -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Is timestamp a reserved word in CQL?
Hi all, I find in the doc, http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/keywords_r.html , keyword timestamp is not reserved. However, when I create a table with a column named timestamp, it is changed to timestamp which is in double quotation marks automatically. Is timestamp a reserved word in CQL? I'm using Cassandra 2.0.6. Thanks, Philo Yang
How to deal with SSTable FileNotFoundException?
Hi all,
I have a Cassandra 2.0.6 cluster with 12 nodes. I find in some nodes'
system.log, there are many RuntimeException such like:
java.lang.RuntimeException: java.io.FileNotFoundException:
/disk4/cassandra/data/{keyspace}/{cfname}/{keyspace}-{cfname}-jb-87-Data.db
(No such file or directory)
I think the reason is I have dropped this table and recreated it later. And
I find this Exception blocks the stream from these nodes to others so
bootstrap or rebuild can't finish and is stuck in 100% forever.
What should I do to refresh the SSTable list in these nodes?
--
Regards,
Zhe Yang
