2014-11-04 6 views
0

У меня есть таблица CQL с 4-полевым составным ключом, который я хочу индексировать в Solr. Все 4 составных поля PK являются «текстовыми» типами в CQL и «string» типа в Solr; и 2 из которых могут содержать длинные строки. Когда я инициализировать ядро ​​Solr, я вижу много следующих предупреждающее сообщение в моем system.log:Максимальная длина Solr uniqueKey

pastebin

Фактическое сообщение намного больше, чем (200000+ символов в одной строке), но я усечен это для удобочитаемости. Постоянный поток такого предупреждения наводняет мой файл журнала с момента инициализации ядра до тех пор, пока процесс индексирования не завершится преждевременно (да, Solr не индексирует мои данные)

Исходя из фона MySQL, я знаю, что PK имеют максимальную длину (700 байт в MySQL); поэтому даже если в документации Cassandra или Solr нет упоминания о подобном ограничении, первое, что я сделал, это заменить составной ключ CQL простым текстовым ключом, который содержит хэш-файл sha-1 из 4 полей, которые были ранее часть соединения ПК. Viola - предупреждение исчезло, и Solr смог проиндексировать мои данные. Итак, теперь мой вопрос: у Solr есть ограничение на длину уникального ключа? Кажется, что у Cassandra проблемы с длинными составными PK (поскольку я смог запросить некоторые мои данные через CQL), но у Solr, похоже, есть предел.

UPDATE:

После дальнейшего тестирования я обнаружил, что каким-то образом, она представляет собой смесь соединения ПК и карты CQL в моей схемы таблицы, которая является причиной проблемы индексирования Solr.

  1. Соединение ПК + нет карт (заменено на многих колоннах) =
  2. работает
  3. Простого ПК (SHA-1 хэш соединение PK столбцы) + карты =
  4. работает
  5. Соединение PK + карты = не работает

Я все еще не уверен, связана ли проблема с длиной моих данных.

CQL Таблица схемы:

CREATE TABLE myks.mycf (
    phrase text, 
    host text, 
    domain text, 
    path text, 
    created timestamp, 
    modified timestamp, 

    attr1 int, 
    attr2 bigint, 
    attr3 double, 
    attr4 int, 
    attr5 bigint, 
    attr6 bigint, 
    attr7 double, 
    attr8 double, 

    scores map<text,int>, 
    estimates map<text,bigint>, 
    searches map<text,bigint>, 

    PRIMARY KEY (phrase,domain,host,path), 
) WITH gc_grace_seconds = 1296000 
AND compaction={'class': 'LeveledCompactionStrategy'} 
AND compression={'sstable_compression': 'LZ4Compressor'} 

Solr Схема:

<schema name="myks" version="1.5"> 
    <types> 
    <fieldType name="text" class="solr.TextField"> 
    <analyzer> 
     <tokenizer class="solr.StandardTokenizerFactory"/> 
    </analyzer> 
    </fieldType> 
    <fieldType name="string" class="solr.StrField" omitNorms="true"/> 
    <fieldType name="boolean" class="solr.BoolField" omitNorms="true"/> 
    <fieldtype name="binary" class="solr.BinaryField"/> 
    <fieldType name="int" class="solr.TrieIntField" precisionStep="0" omitNorms="true" positionIncrementGap="0"/> 
    <fieldType name="float" class="solr.TrieFloatField" precisionStep="0" omitNorms="true" positionIncrementGap="0"/> 
    <fieldType name="long" class="solr.TrieLongField" precisionStep="0" omitNorms="true" positionIncrementGap="0"/> 
    <fieldType name="double" class="solr.TrieDoubleField" precisionStep="0" omitNorms="true" positionIncrementGap="0"/> 
    <fieldType name="date" class="solr.TrieDateField" precisionStep="0" omitNorms="true" positionIncrementGap="0"/> 
    </types> 
    <fields> 
    <field name="phrase" type="string" indexed="true" stored="true"/> 
    <field name="host" type="string" indexed="true" stored="true"/> 
    <field name="domain" type="string" indexed="true" stored="true"/> 
    <field name="path" type="string" indexed="true" stored="true"/> 
    <field name="created" type="date" indexed="true" stored="true"/> 
    <field name="modified" type="date" indexed="true" stored="true"/> 

    <field name="attr1" type="int" indexed="true" stored="true"/> 
    <field name="attr2" type="long" indexed="true" stored="true"/> 
    <field name="attr3" type="double" indexed="true" stored="true"/> 
    <field name="attr4" type="int" indexed="true" stored="true"/> 
    <field name="attr5" type="long" indexed="true" stored="true"/> 
    <field name="attr6" type="long" indexed="true" stored="true"/> 
    <field name="attr7" type="double" indexed="true" stored="true"/> 
    <field name="attr8" type="double" indexed="true" stored="true"/> 

    <!-- CQL collection maps --> 
    <dynamicField name="scores*" type="int" indexed="true" stored="true"/> 
    <dynamicField name="estimates*" type="long" indexed="true" stored="true"/> 
    <dynamicField name="searches*" type="long" indexed="true" stored="true"/> 

    <!-- docValues - facet --> 
    <field name="dv__domain" type="string" indexed="true" stored="false" docValues="true" multiValued="true"/> 
    <field name="dv__attr4" type="int" indexed="true" stored="false" docValues="true" multiValued="true"/> 
    <field name="dv__attr8" type="double" indexed="true" stored="false" docValues="true" multiValued="true"/> 

    <!-- docValues - group --> 
    <field name="dv__phrase" type="string" indexed="true" stored="false" docValues="true" multiValued="true"/> 

    <!-- docValues - sort --> 
    <field name="dv__attr2" type="long" indexed="true" stored="false" docValues="true" multiValued="true"/> 
    <field name="dv__attr5" type="long" indexed="true" stored="false" docValues="true" multiValued="true"/> 
    <field name="dv__attr1" type="int" indexed="true" stored="false" docValues="true" multiValued="true"/> 
    </fields> 

    <!-- Why we use copyFields for docValues: http://stackoverflow.com/questions/26495208/solr-docvalues-usage --> 
    <copyField source="domain" dest="dv__domain"/> 
    <copyField source="attr4" dest="dv__attr4"/> 
    <copyField source="attr8" dest="dv__attr8"/> 
    <copyField source="phrase" dest="dv__phrase"/> 
    <copyField source="attr2" dest="dv__attr2"/> 
    <copyField source="attr5" dest="dv__attr5"/> 
    <copyField source="attr1" dest="dv__attr1"/> 

    <defaultSearchField>phrase</defaultSearchField> 
    <uniqueKey>(phrase,domain,host,path)</uniqueKey> 
</schema> 

Я использую CQLSSTableWriter для создания sstables выхода из затопленных из томов CSV MySQL. Для карт CQL я выбрал Java HashMap для представления значений.

Я также узнал сегодня, что даже у Кассандры есть проблема со смесью составных ПК и карт. Когда я посмотрел файловую систему, копия таблицы, использующая составные карты PK +, имеет гораздо меньший размер папки, чем копии, которые используют либо простые карты PK +, либо составные PK + нет карт.

+0

Можете ли вы поделиться ошибкой, которую видите при создании своего ядра? – phact

+0

Ошибка при создании ядра. Проблема возникает при индексировании. Я попробовал два варианта: 1. Создайте таблицу, импортируйте все данные в Cassandra, затем инициализируйте ядро ​​Solr; 2. Создайте таблицу, инициализируйте ядро ​​Solr и импортируйте все данные. Оба из них приводят к одному и тому же сценарию - процесс индексирования в каждом узле достигает не более 2% (обычно 0% или 1%) и выходит без сообщения об ошибке, кроме многих предупреждающих строк, которые заливают system.log. –

+0

Хм, Я спрашивал, потому что ошибки надгробия действительно связаны с кассандрой. Не знаете, как они могут повлиять на индексацию. Вы делаете много удалений? – phact

ответ

0

У Кассандры есть предел 64K для ключей.

Как правило, в Solr «текст» не должен использоваться для ключа, поскольку он обозначен. Вместо этого используйте поле «строка».

В вики примечаний Cassandra FAQ, хэш является лучшим выбором для использования длинных текстовых значений для ключей: http://wiki.apache.org/cassandra/FAQ#max_key_size

В конечном счете, сводится к тому, как вы хотите, чтобы запросить документы Solr.

Общее руководство для «пределов» в Solr - это просто «быть разумным» - большое все, что может вызвать проблемы у вас куда-то.

+0

Спасибо за указание документированного лимита для Cassandra. Что касается моей схемы Solr, я был не очень ясен в своем OP, но мои типы полей на самом деле являются «строками» в Solr. «Текстовые» типы находятся в соответствующей схеме CQL. –

+0

Можете ли вы подтвердить, что это случай, когда я нажимаю предел Solr? Я хотел бы избежать использования простой хэш-PK как можно больше, потому что это помешало бы мне выполнять частичные CQL-фильтры (т. Е. Несколько фильтров на подмножестве составных столбцов PK). Большинство моих операций чтения выполнялись через Solr, но некоторые (например, созданные Spark) были бы CQL. –