You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Sasha Dolgy <sd...@gmail.com> on 2011/04/12 19:46:41 UTC

forced index creation?

hi, just deployed a new keyspace on 0.7.4 and added the following column family:

create column family applications with comparator=UTF8Type and column_metadata=[
    {column_name: app_name, validation_class: UTF8Type},
    {column_name: app_uri, validation_class: UTF8Type,index_type: KEYS},
    {column_name: app_id, validation_class: UTF8Type}
];

I then proceeded to add two new rows of data to it.  When i try and
query the secondary index on app_uri, my query with phpcassa fails.
on the same CF in a different cluster, it works fine.  when comparing
the CF between clusters, see there's a difference: ---  Built indexes:
--- shows up when i run --> describe keyspace foobar;



      Column Metadata:
        Column Name: app_name (app_name)
          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
        Column Name: app_id (app_id)
          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
        Column Name: app_uri (app_uri)
          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
          Index Type: KEYS

Checking out a bit further:

get applications where 'app_uri' = 'get-test';
-------------------
RowKey: 9d699733-9afe-4a41-83ca-c60d040dacc0


get applications where 'app_id' = '9d699733-9afe-4a41-83ca-c60d040dacc0';
No indexed columns present in index clause with operator EQ

So .. I can see that the secondary indexes are working.

Question 1:  Has "Built indexes" been removed from the "describe
keyspace" output?  Or have i done something ....
Question 2:  Is there a way to force secondary index creation?





-- 
Sasha Dolgy
sasha.dolgy@gmail.com

Re: forced index creation?

Posted by Sasha Dolgy <sd...@gmail.com>.
Aha.  that would be it.  cheers
On Apr 14, 2011 11:47 AM, "aaron morton" <aa...@thelastpickle.com> wrote:
> Checked the code, build_indexes comes from the JMX services and is only
shown if the client can connect to JMX.
>
> It is cannot connect it should print "WARNING: Could not connect to the
JMX on %s:%d, information won't be shown.%n%n"
>
> If you are using a non default JMX port use --jmxport when starting the
CLI.
>
> Hope that helps.
> Aaron
>
> On 14 Apr 2011, at 07:12, Sasha Dolgy wrote:
>
>> odd ... checked again today. still not there. will dig around the
>> logs a bit. my indexes work ... just not seeing anything in the CLI
>> ... are you also on 0.7.4 ?
>>
>> ColumnFamily: applications
>> Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
>> Row cache size / save period: 0.0/0
>> Key cache size / save period: 200000.0/14400
>> Memtable thresholds: 0.24843749999999998/53/1440
>> GC grace seconds: 864000
>> Compaction min/max thresholds: 4/32
>> Read repair chance: 1.0
>> Column Metadata:
>> Column Name: app_name (app_name)
>> Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>> Column Name: app_id (app_id)
>> Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>> Column Name: app_uri (app_uri)
>> Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>> Index Type: KEYS
>>
>>
>> On Wed, Apr 13, 2011 at 4:35 AM, aaron morton <aa...@thelastpickle.com>
wrote:
>>> Built indexes are there for me
>>>
>>> [default@unknown] describe keyspace Keyspace1;
>>> Keyspace: Keyspace1:
>>> Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>>> Replication Factor: 1
>>> Column Families:
>>> ColumnFamily: Indexed1
>>> default_validation_class: org.apache.cassandra.db.marshal.LongType
>>> Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
>>> Row cache size / save period in seconds: 0.0/0
>>> Key cache size / save period in seconds: 200000.0/14400
>>> Memtable thresholds: 0.14531249999999998/31/1440 (millions of
ops/minutes/MB)
>>> GC grace seconds: 864000
>>> Compaction min/max thresholds: 4/32
>>> Read repair chance: 1.0
>>> Built indexes: [Indexed1.birthdate_idx]
>>> Column Metadata:
>>> Column Name: birthdate
>>> Validation Class: org.apache.cassandra.db.marshal.LongType
>>> Index Name: birthdate_idx
>>> Index Type: KEYS
>>>
>>> When the index is created existing data is indexed async, and any new
data is indexed as part of the write. Not sure how to force/check things
though.
>>>
>>> Can you turn logging up to DEBUG and compare the requests between the
two clusters ?
>>>
>>> Aaron
>>>
>>> On 13 Apr 2011, at 05:46, Sasha Dolgy wrote:
>>>
>>>> hi, just deployed a new keyspace on 0.7.4 and added the following
column family:
>>>>
>>>> create column family applications with comparator=UTF8Type and
column_metadata=[
>>>> {column_name: app_name, validation_class: UTF8Type},
>>>> {column_name: app_uri, validation_class: UTF8Type,index_type: KEYS},
>>>> {column_name: app_id, validation_class: UTF8Type}
>>>> ];
>>>>
>>>> I then proceeded to add two new rows of data to it. When i try and
>>>> query the secondary index on app_uri, my query with phpcassa fails.
>>>> on the same CF in a different cluster, it works fine. when comparing
>>>> the CF between clusters, see there's a difference: --- Built indexes:
>>>> --- shows up when i run --> describe keyspace foobar;
>>>>
>>>>
>>>>
>>>> Column Metadata:
>>>> Column Name: app_name (app_name)
>>>> Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>>>> Column Name: app_id (app_id)
>>>> Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>>>> Column Name: app_uri (app_uri)
>>>> Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>>>> Index Type: KEYS
>>>>
>>>> Checking out a bit further:
>>>>
>>>> get applications where 'app_uri' = 'get-test';
>>>> -------------------
>>>> RowKey: 9d699733-9afe-4a41-83ca-c60d040dacc0
>>>>
>>>>
>>>> get applications where 'app_id' =
'9d699733-9afe-4a41-83ca-c60d040dacc0';
>>>> No indexed columns present in index clause with operator EQ
>>>>
>>>> So .. I can see that the secondary indexes are working.
>>>>
>>>> Question 1: Has "Built indexes" been removed from the "describe
>>>> keyspace" output? Or have i done something ....
>>>> Question 2: Is there a way to force secondary index creation?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sasha Dolgy
>>>> sasha.dolgy@gmail.com
>>>
>>>
>>
>>
>>
>> --
>> Sasha Dolgy
>> sasha.dolgy@gmail.com
>

Re: forced index creation?

Posted by aaron morton <aa...@thelastpickle.com>.
Checked the code, build_indexes comes from the JMX services and is only shown if the client can connect to JMX. 

It is cannot connect it should print "WARNING: Could not connect to the JMX on %s:%d, information won't be shown.%n%n"

If you are using a non default JMX port use --jmxport when starting the CLI.  

Hope that helps. 
Aaron

On 14 Apr 2011, at 07:12, Sasha Dolgy wrote:

> odd ... checked again today.   still not there.  will dig around the
> logs a bit.  my indexes work ... just not seeing anything in the CLI
> ... are you also on 0.7.4 ?
> 
>    ColumnFamily: applications
>      Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
>      Row cache size / save period: 0.0/0
>      Key cache size / save period: 200000.0/14400
>      Memtable thresholds: 0.24843749999999998/53/1440
>      GC grace seconds: 864000
>      Compaction min/max thresholds: 4/32
>      Read repair chance: 1.0
>      Column Metadata:
>        Column Name: app_name (app_name)
>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>        Column Name: app_id (app_id)
>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>        Column Name: app_uri (app_uri)
>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>          Index Type: KEYS
> 
> 
> On Wed, Apr 13, 2011 at 4:35 AM, aaron morton <aa...@thelastpickle.com> wrote:
>> Built indexes are there for me
>> 
>> [default@unknown] describe keyspace Keyspace1;
>> Keyspace: Keyspace1:
>>  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>>    Replication Factor: 1
>>  Column Families:
>>    ColumnFamily: Indexed1
>>      default_validation_class: org.apache.cassandra.db.marshal.LongType
>>      Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
>>      Row cache size / save period in seconds: 0.0/0
>>      Key cache size / save period in seconds: 200000.0/14400
>>      Memtable thresholds: 0.14531249999999998/31/1440 (millions of ops/minutes/MB)
>>      GC grace seconds: 864000
>>      Compaction min/max thresholds: 4/32
>>      Read repair chance: 1.0
>>      Built indexes: [Indexed1.birthdate_idx]
>>      Column Metadata:
>>        Column Name: birthdate
>>          Validation Class: org.apache.cassandra.db.marshal.LongType
>>          Index Name: birthdate_idx
>>          Index Type: KEYS
>> 
>> When the index is created existing data is indexed async, and any new data is indexed as part of the write. Not sure how to force/check things though.
>> 
>> Can you turn logging up to DEBUG and compare the requests between the two clusters ?
>> 
>> Aaron
>> 
>> On 13 Apr 2011, at 05:46, Sasha Dolgy wrote:
>> 
>>> hi, just deployed a new keyspace on 0.7.4 and added the following column family:
>>> 
>>> create column family applications with comparator=UTF8Type and column_metadata=[
>>>    {column_name: app_name, validation_class: UTF8Type},
>>>    {column_name: app_uri, validation_class: UTF8Type,index_type: KEYS},
>>>    {column_name: app_id, validation_class: UTF8Type}
>>> ];
>>> 
>>> I then proceeded to add two new rows of data to it.  When i try and
>>> query the secondary index on app_uri, my query with phpcassa fails.
>>> on the same CF in a different cluster, it works fine.  when comparing
>>> the CF between clusters, see there's a difference: ---  Built indexes:
>>> --- shows up when i run --> describe keyspace foobar;
>>> 
>>> 
>>> 
>>>      Column Metadata:
>>>        Column Name: app_name (app_name)
>>>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>>>        Column Name: app_id (app_id)
>>>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>>>        Column Name: app_uri (app_uri)
>>>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>>>          Index Type: KEYS
>>> 
>>> Checking out a bit further:
>>> 
>>> get applications where 'app_uri' = 'get-test';
>>> -------------------
>>> RowKey: 9d699733-9afe-4a41-83ca-c60d040dacc0
>>> 
>>> 
>>> get applications where 'app_id' = '9d699733-9afe-4a41-83ca-c60d040dacc0';
>>> No indexed columns present in index clause with operator EQ
>>> 
>>> So .. I can see that the secondary indexes are working.
>>> 
>>> Question 1:  Has "Built indexes" been removed from the "describe
>>> keyspace" output?  Or have i done something ....
>>> Question 2:  Is there a way to force secondary index creation?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sasha Dolgy
>>> sasha.dolgy@gmail.com
>> 
>> 
> 
> 
> 
> -- 
> Sasha Dolgy
> sasha.dolgy@gmail.com


Re: forced index creation?

Posted by Sasha Dolgy <sd...@gmail.com>.
odd ... checked again today.   still not there.  will dig around the
logs a bit.  my indexes work ... just not seeing anything in the CLI
... are you also on 0.7.4 ?

    ColumnFamily: applications
      Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
      Row cache size / save period: 0.0/0
      Key cache size / save period: 200000.0/14400
      Memtable thresholds: 0.24843749999999998/53/1440
      GC grace seconds: 864000
      Compaction min/max thresholds: 4/32
      Read repair chance: 1.0
      Column Metadata:
        Column Name: app_name (app_name)
          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
        Column Name: app_id (app_id)
          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
        Column Name: app_uri (app_uri)
          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
          Index Type: KEYS


On Wed, Apr 13, 2011 at 4:35 AM, aaron morton <aa...@thelastpickle.com> wrote:
> Built indexes are there for me
>
> [default@unknown] describe keyspace Keyspace1;
> Keyspace: Keyspace1:
>  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>    Replication Factor: 1
>  Column Families:
>    ColumnFamily: Indexed1
>      default_validation_class: org.apache.cassandra.db.marshal.LongType
>      Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
>      Row cache size / save period in seconds: 0.0/0
>      Key cache size / save period in seconds: 200000.0/14400
>      Memtable thresholds: 0.14531249999999998/31/1440 (millions of ops/minutes/MB)
>      GC grace seconds: 864000
>      Compaction min/max thresholds: 4/32
>      Read repair chance: 1.0
>      Built indexes: [Indexed1.birthdate_idx]
>      Column Metadata:
>        Column Name: birthdate
>          Validation Class: org.apache.cassandra.db.marshal.LongType
>          Index Name: birthdate_idx
>          Index Type: KEYS
>
> When the index is created existing data is indexed async, and any new data is indexed as part of the write. Not sure how to force/check things though.
>
> Can you turn logging up to DEBUG and compare the requests between the two clusters ?
>
> Aaron
>
> On 13 Apr 2011, at 05:46, Sasha Dolgy wrote:
>
>> hi, just deployed a new keyspace on 0.7.4 and added the following column family:
>>
>> create column family applications with comparator=UTF8Type and column_metadata=[
>>    {column_name: app_name, validation_class: UTF8Type},
>>    {column_name: app_uri, validation_class: UTF8Type,index_type: KEYS},
>>    {column_name: app_id, validation_class: UTF8Type}
>> ];
>>
>> I then proceeded to add two new rows of data to it.  When i try and
>> query the secondary index on app_uri, my query with phpcassa fails.
>> on the same CF in a different cluster, it works fine.  when comparing
>> the CF between clusters, see there's a difference: ---  Built indexes:
>> --- shows up when i run --> describe keyspace foobar;
>>
>>
>>
>>      Column Metadata:
>>        Column Name: app_name (app_name)
>>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>>        Column Name: app_id (app_id)
>>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>>        Column Name: app_uri (app_uri)
>>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>>          Index Type: KEYS
>>
>> Checking out a bit further:
>>
>> get applications where 'app_uri' = 'get-test';
>> -------------------
>> RowKey: 9d699733-9afe-4a41-83ca-c60d040dacc0
>>
>>
>> get applications where 'app_id' = '9d699733-9afe-4a41-83ca-c60d040dacc0';
>> No indexed columns present in index clause with operator EQ
>>
>> So .. I can see that the secondary indexes are working.
>>
>> Question 1:  Has "Built indexes" been removed from the "describe
>> keyspace" output?  Or have i done something ....
>> Question 2:  Is there a way to force secondary index creation?
>>
>>
>>
>>
>>
>> --
>> Sasha Dolgy
>> sasha.dolgy@gmail.com
>
>



-- 
Sasha Dolgy
sasha.dolgy@gmail.com

Re: forced index creation?

Posted by aaron morton <aa...@thelastpickle.com>.
Built indexes are there for me

[default@unknown] describe keyspace Keyspace1;
Keyspace: Keyspace1:
  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
    Replication Factor: 1
  Column Families:
    ColumnFamily: Indexed1
      default_validation_class: org.apache.cassandra.db.marshal.LongType
      Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
      Row cache size / save period in seconds: 0.0/0
      Key cache size / save period in seconds: 200000.0/14400
      Memtable thresholds: 0.14531249999999998/31/1440 (millions of ops/minutes/MB)
      GC grace seconds: 864000
      Compaction min/max thresholds: 4/32
      Read repair chance: 1.0
      Built indexes: [Indexed1.birthdate_idx]
      Column Metadata:
        Column Name: birthdate
          Validation Class: org.apache.cassandra.db.marshal.LongType
          Index Name: birthdate_idx
          Index Type: KEYS

When the index is created existing data is indexed async, and any new data is indexed as part of the write. Not sure how to force/check things though. 

Can you turn logging up to DEBUG and compare the requests between the two clusters ? 

Aaron

On 13 Apr 2011, at 05:46, Sasha Dolgy wrote:

> hi, just deployed a new keyspace on 0.7.4 and added the following column family:
> 
> create column family applications with comparator=UTF8Type and column_metadata=[
>    {column_name: app_name, validation_class: UTF8Type},
>    {column_name: app_uri, validation_class: UTF8Type,index_type: KEYS},
>    {column_name: app_id, validation_class: UTF8Type}
> ];
> 
> I then proceeded to add two new rows of data to it.  When i try and
> query the secondary index on app_uri, my query with phpcassa fails.
> on the same CF in a different cluster, it works fine.  when comparing
> the CF between clusters, see there's a difference: ---  Built indexes:
> --- shows up when i run --> describe keyspace foobar;
> 
> 
> 
>      Column Metadata:
>        Column Name: app_name (app_name)
>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>        Column Name: app_id (app_id)
>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>        Column Name: app_uri (app_uri)
>          Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>          Index Type: KEYS
> 
> Checking out a bit further:
> 
> get applications where 'app_uri' = 'get-test';
> -------------------
> RowKey: 9d699733-9afe-4a41-83ca-c60d040dacc0
> 
> 
> get applications where 'app_id' = '9d699733-9afe-4a41-83ca-c60d040dacc0';
> No indexed columns present in index clause with operator EQ
> 
> So .. I can see that the secondary indexes are working.
> 
> Question 1:  Has "Built indexes" been removed from the "describe
> keyspace" output?  Or have i done something ....
> Question 2:  Is there a way to force secondary index creation?
> 
> 
> 
> 
> 
> -- 
> Sasha Dolgy
> sasha.dolgy@gmail.com