;
> ERROR [CompactionExecutor:188] 2014-02-12 04:15:53,232
> CassandraDaemon.java (line 192) Exception in thread
> Thread[CompactionExecutor:188,1,main]
>
> org.apache.cassandra.io.sstable.CorruptSSTableException:
> java.io.IOException: Corrupted Index File -jb-48064-Compression
hread[CompactionExecutor:188,1,main]
org.apache.cassandra.io.sstable.CorruptSSTableException: java.io.IOException:
Corrupted Index File -jb-48064-CompressionInfo.db: read 20252 but
expected 20253 chunks.
Thanks, Don
Donald A. Smith | Senior Software Engineer
P: 425.201.3900 x 3866
C: (206) 819-5965
F: (646
This webinar I did a few months ago goes through the read and write path
http://www.youtube.com/watch?v=zFCjekgK7ZY
I get to that about 29 minutes in.
slides
http://www.slideshare.net/aaronmorton/cassandra-community-webinar-introduction-to-apache-cassandra-12-20353118
Cheers
---
Thanks! :-)
M.
W dniu 18.07.2013 08:42, Jean-Armel Luce pisze:
@Michal : look a this for the improvement of read performance :
https://issues.apache.org/jira/browse/CASSANDRA-2498
Best regards.
Jean Armel
2013/7/18 Michał Michalski
SSTables are immutable - once they're written to disk, t
@Michal : look a this for the improvement of read performance :
https://issues.apache.org/jira/browse/CASSANDRA-2498
Best regards.
Jean Armel
2013/7/18 Michał Michalski
> SSTables are immutable - once they're written to disk, they cannot be
> changed.
>
> On read C* checks *all* SSTables [1],
SSTables are immutable - once they're written to disk, they cannot be
changed.
On read C* checks *all* SSTables [1], but to make it faster, it uses
Bloom Filters, that can tell you if a row is *not* in a specific
SSTable, so you don't have to read it at all. However, *if* you read it
in case
On Wed, Jul 17, 2013 at 1:53 PM, S Ahmed wrote:
> So is there an index of key's to sstables, and there can be 1 or more
> sstables per key?
>
There are bloom filters, which answer the question "is my row key
definitely not in this SSTable"?
There is also the Key Cache, which is a list of SSTabl
Yes..Multiple SSTables can have same key and only after compaction the keys are
merged reflect the latest value..
From: S Ahmed [mailto:sahmed1...@gmail.com]
Sent: 17 July 2013 15:54
To: cassandra-u...@incubator.apache.org
Subject: is there a key to sstable index file?
Since SSTables are
Since SSTables are mutable, and they are ordered, does this mean that there
is a index of key ranges that each SS table holds, and the value could be 1
more sstables that have to be scanned and then the latest one is chosen?
e.g. Say I write a value "abc" to CF1. This gets stored in a sstable.
T
Since SSTables are mutable, and they are ordered, does this mean that there
is a index of key ranges that each SS table holds, and the value could be 1
more sstables that have to be scanned and then the latest one is chosen?
e.g. Say I write a value "abc" to CF1. This gets stored in a sstable.
T
-Index.db components only contain the index.
In v1.2+ -Summary.db contains a sampling of the index read at startup.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 3/02/2013, at 11:03 AM, Kanwar Sangha wrote:
> Hi
Hi - The index files created for the SSTables. Do they contain a sampling or
the complete index ? Cassandra on startup loads these files based on the
sampling rate in Cassandra.yaml ..right ?
4-04 14:50:54,105 CompactionManager.java
> (line 602) Row scrubbed successfully but index file contains a different key
> or row size; consider rebuilding the index as described in
> http://www.mail-archive.com/user@cassandra.apache.org/msg03325.html
> Shimi
>
--
Jonathan Ellis
Project Ch
It make sense to me that compaction should solved this as well since
compaction creates new index files.
Am I missing something here?
WARN [CompactionExecutor:1] 2011-04-04 14:50:54,105 CompactionManager.java
(line 602) Row scrubbed successfully but index file contains a different key
or row size
ven
SStable), it checks this
sample (an offset in the index file to a block of key location), reads
the block of (128) entries
corresponding in the index file on disk, thus finding the actual
offset in the sstable where
the corresponding row start.
The goal of the KeyCache is to avoid this on a cache
so when will index files be in the memory?
At 2010-12-06 00:54:48，"Brandon Williams" wrote:
2010/12/5 魏金仙
for each sstable, there is an index file, which is loaded in memory to locate a
particular key's offset efficiently.
Index files are not held in memory.
and for each
2010/12/5 魏金仙
> for each sstable, there is an index file, which is loaded in memory to
> locate a particular key's offset efficiently.
>
Index files are not held in memory.
> and for each CF, KeysCached can be set to cache keys' location.
> could you pls tell me the d
for each sstable, there is an index file, which is loaded in memory to locate a
particular key's offset efficiently.
and for each CF, KeysCached can be set to cache keys' location.
could you pls tell me the difference between the two?
I'm wondering whether it's necessary to se
18 matches
Mail list logo
