Как лучше всего объединить счетчики Cassandra и индексы Solr в DSE

Согласно документации DSE, поиск DSE не поддерживает счетчик столбцы.

У меня есть базовый CF с (ckey, count), где count — счетчик.

create table change_count ( ckey text, count counter) primary key (ckey)

Естественно, dsetool create_core ks.change_count не работает на этом CF, потому что есть счетчик, с "Индексы Solr не поддерживаются на счетчиках!" ошибка.

Итак, я создаю документ схемы Solr вручную:

<?xml version="1.0" encoding="UTF-8"?>
<schema name="autoSolrSchema" version="1.5">
   <types>
      <fieldType class="org.apache.solr.schema.StrField" name="StrField" />
   </types>
   <fields>
      <field indexed="true" multiValued="false" name="ckey" stored="true" type="StrField" />
   </fields>
   <uniqueKey>(ckey)</uniqueKey>
</schema>

, сохраните его в файл и используйте dsetool create_core ks.change_count schema=/tmp/1.xml, но я все равно получаю то же самое «Индексы Solr не поддерживаются на счетчиках!» ошибка.

Итак, первый вопрос: есть ли способ усилить DSE и иметь CF со счетчиком и индексы solr для столбцов, которые не являются счетчиками.

Если это невозможно, то я хотел бы иметь какие-либо предложения о том, как решить проблему представления данных. Допустим, «ckey» — это «час эпохи», а count — просто счетчик некоторых событий, которые произошли в течение этого часа. Тип счетчика для атомарных приращений, конкуренция на этом CF будет очень высока, даже если я использовал легковесные транзакции. Индекс Solr существует, потому что я хочу выполнять поиск по диапазону и так далее.

Я могу создать 2 CF:

create table change_count ( ckey text, count counter) primary key (ckey)
create table change_count_idx ( ckey text ) primary key (ckey)

Затем я могу индексировать Solr change_count_idx, но считать в таблице change_count, убедившись, что у меня есть одинаковые ключи в обоих. Затем я могу получить совпадающие ключи с помощью Solr и фактические данные с помощью Cassandra, выполняя соединение на стороне клиента. Но потенциально это могут быть тысячи поисковых запросов PK, и я не думаю, что производительность выдержит большие диапазоны.


cassandra datastax datastax-enterprise
person Pawel Veselov    schedule 22.03.2016    source источник
comment
В таблице со столбцами-счетчиками все столбцы не-счетчики должны быть частью первичного ключа.   -  person Caleb Rackliffe    schedule 31.03.2016
comment
Это не должно быть ответом на ваш вопрос на уровне решения, поэтому я переместил его сюда. Это просто напоминание для читателей. Проверка в DSE выполняется по метаданным таблицы и предполагает, что вы не хотите индексировать только первичный ключ.   -  person Caleb Rackliffe    schedule 31.03.2016
comment
@CalebRackliffe Но я мог бы захотеть проиндексировать только свой первичный ключ и использовать Solr для выполнения сумасшедших запросов, которые иначе не поддерживаются в Cassandra. Это идея, стоящая за этой конкретной таблицей.   -  person Pawel Veselov    schedule 31.03.2016
comment
Если все, что вы хотите сделать, это поиск по первичному ключу, я не уверен, зачем вам вообще нужен Solr. Возможно, я что-то упустил при чтении...   -  person Caleb Rackliffe    schedule 01.04.2016
comment
@CalebRackliffe Я не хочу выполнять поиск (это единственное, что Cassandra поддерживает в PK), я хочу выполнять запросы диапазона, неточные запросы и т. д.   -  person Pawel Veselov    schedule 01.04.2016
comment
Понял. В этом случае отдельная таблица, вероятно, лучшее, что вы можете сделать на данный момент. Cassandra 2.1 (и, кажется, 3.0) даже не поддерживает стандартные вторичные индексы для таблиц счетчиков. Вы можете упростить свои вставки с помощью триггера, который добавляет мутации для вашей таблицы change_count_idx.   -  person Caleb Rackliffe    schedule 01.04.2016

Ответы (1)


arrow_upward
0
arrow_downward

То, что вы описываете, строго невозможно с поиском DSE.

Это может быть хрупким, но если вы действительно хотите искать эти счетчики, вы можете подумать о создании «зеркальной» версии change_count, которая использует bigint вместо counter. Затем вы можете периодически считывать данные из change_count в «зеркальную» таблицу и выполнять запросы непосредственно к ней.

person Caleb Rackliffe    schedule 31.03.2016