Great stuff, Aaron. Thanks for your time

On 20 December 2012 05:10, aaron morton <aa...@thelastpickle.com> wrote:
> Well that was fun https://issues.apache.org/jira/browse/CASSANDRA-5079
>
> Just testing my idea of a fix now.
>
> Cheers
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 20/12/2012, at 10:33 AM, aaron morton <aa...@thelastpickle.com> wrote:
>
> Please try to run Cassandra with -Xms1927M -Xmx1927M -Xmn400M
>
> Done and I now get your repo case…
>
> [default@ks123] get cf1 where 'indexedColumn'='65';
>
> 0 Row Returned.
> Elapsed time: 1.44 msec(s).
>
>
> [default@ks123] get cf1 where 'indexedColumn'='66';
> -------------------
> RowKey: 66
> => (column=1, value=val, timestamp=1355952222439049, ttl=7884000)
> => (column=10, value=val, timestamp=1355952222439269, ttl=7884000)
> ...
> => (column=indexedColumn, value=66, timestamp=1355952223881937, ttl=7887600)
>
> Looking into it now.
>
> Thanks
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 19/12/2012, at 9:56 PM, Roland Gude <roland.g...@ez.no> wrote:
>
> I think this might be https://issues.apache.org/jira/browse/CASSANDRA-4670
> Unfortunately apart from me no one was yet able to reproduce.
>
> Check if data is available before/after compaction
> If you have leveled compaction it is hard to test because you cannot trigger
> compaction manually.
>
> -----Ursprüngliche Nachricht-----
> Von: Alexei Bakanov [mailto:russ...@gmail.com]
> Gesendet: Mittwoch, 19. Dezember 2012 09:35
> An: user@cassandra.apache.org
> Betreff: Re: TTL on SecondaryIndex Columns. A bug?
>
> I'm running on a single node on my laptop.
> It looks like the point when rows dissapear from the index depends on JVM
> memory settings. With more memory it needs more data to feed in before
> things start disappearing.
> Please try to run Cassandra with -Xms1927M -Xmx1927M -Xmn400M
>
> To be sure, try to get rows for 'indexedColumn'='1':
>
> [default@ks123] get cf1 where 'indexedColumn'='1';
>
> 0 Row Returned.
>
> Thanks
>
>
> On 19 December 2012 05:15, aaron morton <aa...@thelastpickle.com> wrote:
>
> 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 Morton
> Freelance Cassandra Developer
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 18/12/2012, at 9:44 PM, Alexei Bakanov <russ...@gmail.com> wrote:
>
> 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 example below we create 70 rows with 45k columns each + one
> indexed column with just the rowkey as value, so we have one row per
> indexed value. When the script is finished the index contains rows
> 66-69. Rows 0-65 are gone from the index.
> Using 'indexedColumn' without TTL fixes the problem.
>
>
> ------------- SCHEMA START ----------------- create keyspace ks123
> with placement_strategy = 'NetworkTopologyStrategy'
> and strategy_options = {datacenter1 : 1}  and durable_writes = true;
>
> use ks123;
>
> create column family cf1
> with column_type = 'Standard'
> and comparator = 'AsciiType'
> and default_validation_class = 'AsciiType'
> and key_validation_class = 'AsciiType'
> and read_repair_chance = 0.1
> and dclocal_read_repair_chance = 0.0
> and gc_grace = 864000
> and min_compaction_threshold = 4
> and max_compaction_threshold = 32
> and replicate_on_write = true
> and compaction_strategy =
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
> and caching = 'KEYS_ONLY'
> and column_metadata = [
>   {column_name : 'indexedColumn',
>   validation_class : AsciiType,
>   index_name : 'INDEX1',
>   index_type : 0}]
> and compression_options = {'sstable_compression' :
> 'org.apache.cassandra.io.compress.SnappyCompressor'};
> ------------- SCHEMA FINISH -----------------
>
> ------------- POPULATE START ----------------- from pycassa.batch
> import Mutator import pycassa
>
> pool = pycassa.ConnectionPool('ks123') cf = pycassa.ColumnFamily(pool,
> 'cf1')
>
> for rowKey in xrange(70):
>   b = Mutator(pool)
>   for datapoint in xrange(1, 45001):
>       b.insert(cf,str(rowKey), {str(datapoint): 'val'}, ttl=7884000);
>   b.insert(cf, str(rowKey), {'indexedColumn': str(rowKey)}, ttl=7887600);
>   print 'row %d' % rowKey
>   b.send()
>   b = Mutator(pool)
>
> pool.dispose()
> ------------- POPULATE FINISH -----------------
>
> ------------- QUERY START ----------------- [default@ks123] get cf1
> where 'indexedColumn'='65';
>
> 0 Row Returned.
> Elapsed time: 2.38 msec(s).
>
> [default@ks123] get cf1 where 'indexedColumn'='66';
> -------------------
> RowKey: 66
> => (column=1, value=val, timestamp=1355818765548964, ttl=7884000) ...
> => (column=10087, value=val, timestamp=1355818766075538, ttl=7884000)
> => (column=indexedColumn, value=66, timestamp=1355818768119334,
> ttl=7887600)
>
> 1 Row Returned.
> Elapsed time: 31 msec(s).
> ------------- QUERY FINISH -----------------
>
> This is all using Cassandra 1.1.7 with default settings.
>
> Best regards,
>
> Alexei Bakanov
>
>
>
>
>
>

Reply via email to