TombstoneOverwhelmingException в Cassandra

Question

Так что я получаю это исключение при запросе данных из таблицы. Я много читаю в Интернете и, насколько я понимаю, это происходит потому, что у меня много нулевых строк. Но каков способ решить это? Могу ли я просто избавиться от всех этих нулей?

ОБНОВЛЕНИЕ: Я побежал nodetool compact, а также попытался очистить. В обоих случаях я получаю это.

Exception in thread "main" java.lang.AssertionError: [SSTableReader(path='/var/lib/cassandra/data/bitcoin/okcoin_order_book_btc_usd/bitcoin-okcoin_order_book_btc_usd-jb-538-Data.db'), SSTableReader(path='/var/lib/cassandra/data/bitcoin/okcoin_order_book_btc_usd/bitcoin-okcoin_order_book_btc_usd-jb-710-Data.db'), SSTableReader(path='/var/lib/cassandra/data/bitcoin/okcoin_order_book_btc_usd/bitcoin-okcoin_order_book_btc_usd-jb-627-Data.db'), SSTableReader(path='/var/lib/cassandra/data/bitcoin/okcoin_order_book_btc_usd/bitcoin-okcoin_order_book_btc_usd-jb-437-Data.db')] 
at org.apache.cassandra.db.ColumnFamilyStore$13.call(ColumnFamilyStore.java:2132) 
at org.apache.cassandra.db.ColumnFamilyStore$13.call(ColumnFamilyStore.java:2129) 
at org.apache.cassandra.db.ColumnFamilyStore.runWithCompactionsDisabled(ColumnFamilyStore.java:2111) 
at org.apache.cassandra.db.ColumnFamilyStore.markAllCompacting(ColumnFamilyStore.java:2142) 
at org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getMaximalTask(SizeTieredCompactionStrategy.java:254) 
at org.apache.cassandra.db.compaction.CompactionManager.submitMaximal(CompactionManager.java:290) 
at org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:282) 
at org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1941) 
at org.apache.cassandra.service.StorageService.forceKeyspaceCompaction(StorageService.java:2182) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:606) 
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) 
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:606) 
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) 
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) 
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) 
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) 
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) 
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) 
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) 
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) 
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487) 
at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97) 
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328) 
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420) 
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:606) 
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) 
at sun.rmi.transport.Transport$1.run(Transport.java:177) 
at sun.rmi.transport.Transport$1.run(Transport.java:174) 
at java.security.AccessController.doPrivileged(Native Method) 
at sun.rmi.transport.Transport.serviceCall(Transport.java:173) 
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) 
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811) 
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745) 

И это последние строки из system.log

INFO [CompactionExecutor:1888] 2015-01-03 07:22:54,272 CompactionController.java (line 192) Compacting large row bitcoin/okcoin_trade_btc_cny:1972-05 (225021398 bytes) incrementally 
INFO [CompactionExecutor:1888] 2015-01-03 07:23:07,528 CompactionController.java (line 192) Compacting large row bitcoin/okcoin_trade_btc_cny:1972-06 (217772702 bytes) incrementally 
INFO [CompactionExecutor:1888] 2015-01-03 07:23:20,508 CompactionController.java (line 192) Compacting large row bitcoin/okcoin_trade_btc_cny:2014-05 (121911398 bytes) incrementally 
INFO [ScheduledTasks:1] 2015-01-03 07:23:30,941 GCInspector.java (line 116) GC for ParNew: 223 ms for 1 collections, 5642103584 used; max is 8375238656 
INFO [CompactionExecutor:1888] 2015-01-03 07:23:33,436 CompactionController.java (line 192) Compacting large row bitcoin/okcoin_trade_btc_cny:2014-07 (106408526 bytes) incrementally 
INFO [CompactionExecutor:1888] 2015-01-03 07:23:38,787 CompactionController.java (line 192) Compacting large row bitcoin/okcoin_trade_btc_cny:2014-02 (112031822 bytes) incrementally 
INFO [CompactionExecutor:1888] 2015-01-03 07:23:46,055 ColumnFamilyStore.java (line 794) Enqueuing flush of Memtable-compactions_in_progress@582986122(0/0 serialized/live bytes, 1 ops) 
INFO [FlushWriter:62] 2015-01-03 07:23:46,055 Memtable.java (line 355) Writing Memtable-compactions_in_progress@582986122(0/0 serialized/live bytes, 1 ops) 
INFO [FlushWriter:62] 2015-01-03 07:23:46,268 Memtable.java (line 395) Completed flushing /var/lib/cassandra/data/system/compactions_in_progress/system-compactions_in_progress-jb-22-Data.db (42 bytes) for commitlog position ReplayPosition(segmentId=1420135510457, position=14938165) 
INFO [CompactionExecutor:1888] 2015-01-03 07:23:46,354 CompactionTask.java (line 287) Compacted 2 sstables to [/var/lib/cassandra/data/bitcoin/okcoin_trade_btc_cny/bitcoin-okcoin_trade_btc_cny-jb-554,]. 881,267,752 bytes to 881,266,793 (~99% of original) in 162,878ms = 5.159945MB/s. 24 total partitions merged to 23. Partition merge counts were {1:22, 2:1, } 
WARN [RMI TCP Connection(39)-128.31.5.27] 2015-01-03 07:24:46,452 ColumnFamilyStore.java (line 2103) Unable to cancel in-progress compactions for okcoin_order_book_btc_usd. Probably there is an unusually large row in progress somewhere. It is also possible that buggy code left some sstables compacting after it was done with them 

Я не уверен, что означает, что последняя строка. Кажется, что не очень большие строки (я не знаю, как их найти, если они есть). В качестве примечания есть еще, что уплотнение застряло на 60,33%, и оно застряло на okcoin_order_book_btc_usd. Я бегу Cassandra 2.0.11

Answer 1

Надгробные камни создаются, когда вы удаляете строки или когда они истекли из Кассандры. Они будут удалены при уплотнении SSTables после истечения gc_grace_seconds для этой строки.

Есть несколько вещей, которые я могу думать о том, чтобы помочь облегчить ряд надгробий:

1. установить более низкую gc_grace_seconds для таблицы, которая имеет много надгробных плит - gc_grace_seconds обычно должен быть 1 день больше, как часто вы делаете ремонт. Если вы делаете ремонт чаще, чем это, вы можете рассмотреть вопрос о снижении gc_grace_seconds.
2. Посмотрите, как идут ваши уплотнения. У вас много ожидающих сбоев? (nodetool -h localhost compactionstats на каждом узле покажет это). Возможно, вы отстаете от компромиссов, и данные не очищаются, как только это должно произойти. Возможно, стоит также подумать о том, чтобы изменить стратегию УПАКОВКИ, если это необходимо. Например, если вы используете SizeTieredCompactionStrategy, возможно, стоит взглянуть на LeveledCompactionStrategy, эта стратегия обычно приводит к большей активности уплотнения (поэтому убедитесь, что у вас есть твердотельные накопители), которые могли бы быстрее очистить ваши надгробные плиты.
3. Взгляните на свою модель данных и запросы, которые вы делаете. Вы часто удаляете или истекли данные в разделе, который вы часто читаете? Подумайте об изменении стратегии разбиения на разделы (первичный ключ), чтобы менее вероятные данные о том, что удаленные или истекшие строки попали в ваши «живые» данные. Хорошим примером этого является добавление времени/даты к вашему первичному ключу.
4. Tweak tombstone_failure_threshold в cassandra.yaml - Вероятно, вы бы не подумали об этом, так как это хороший признак того, что вам нужно посмотреть ваши данные.