Почему вторичные индексы Cassandra так медленны всего на 350 тыс. строк?

У меня есть семейство столбцов с вторичным индексом. Вторичный индекс в основном представляет собой двоичное поле, но я использую для него строку. Поле называется is_exported и может принимать значения true или false. После запроса все загруженные строки обновляются с помощью is_exported = 'false'.

Я опрашиваю эту таблицу столбцов каждые десять минут и экспортирую новые строки по мере их появления.

Но вот проблема: я вижу, что время для этого запроса растет довольно линейно с объемом данных в таблице столбцов, и в настоящее время требуется от 12 до 20 секунд (!!!), чтобы найти 5000 строк . Насколько я понимаю, индексированный запрос должен зависеть не от количества строк в CF, а от количества строк на одно значение индекса (кардинальность), так как это просто еще один скрытый CF, например:

    "true" : rowKey1 rowKey2 rowKey3 ...
    "false": rowKey1 rowKey2 rowKey3 ...

Я использую Pycassa для запроса данных, вот код, который я использую:

    column_family = pycassa.ColumnFamily(cassandra_pool, column_family_name, read_consistency_level=2)
    is_exported_expr = create_index_expression('is_exported', 'false')
    clause = create_index_clause([is_exported_expr], count = 5000)
    column_family.get_indexed_slices(clause)

Я делаю что-то не так, но я ожидаю, что эта операция будет работать НАМНОГО быстрее.

Любые идеи или предложения?

Некоторая информация о конфигурации:

  • Кассандра 1.1.0
  • СлучайныйРазделитель
  • У меня 2 узла и replication_factor = 2 (на каждом сервере есть полная копия данных)
  • Использование AWS EC2, большие экземпляры
  • Программный raid0 на эфемерных дисках

Заранее спасибо!


cassandra performance indexing pycassa
person bigdatarefiner    schedule 28.08.2012    source источник
comment
Вы пробовали 1.2.x? Они внесли улучшения в поддержку вторичного индекса.   -  person Aaron    schedule 03.07.2013

Ответы (1)


arrow_upward
1
arrow_downward

Я не знаю внутренностей индексации в Cassandra, но я предполагаю, что она ведет себя аналогично PostgreSQL/MySQL, индексируя логические значения, столбцы true/false избыточны во многих сценариях. Если кардинальность низкая (true & false = 2 уникальных значения) и данные распределены довольно равномерно, например. ~50% true и ~50% false, тогда механизм базы данных, скорее всего, выполнит полное сканирование таблицы (которое не использует индексы).

Линейная зависимость между выполнением запроса и размером набора данных дополнительно подтверждает, что Cassandra выполняет полное сканирование таблицы (пространства ключей).

person Martin Gallagher    schedule 28.08.2012
comment
Спасибо за ответ, но Cassandra - это хранилище NoSQL, а индексы строятся совершенно иначе, чем двоичные деревья в СУБД. Индексы Cassandra построены на фильтрах Блума, как и все другие семейства столбцов. У меня также очень предвзятая кардинальность, поэтому всегда 98-100% записей имеют значение false, и только 2% записей могут иметь значение true, которое я меняю на false после каждой итерации экспорта. - person bigdatarefiner; 29.08.2012
comment
Я не уверен, что в этой ситуации фильтры Блума + хеш-ковши будут более производительными по сравнению с B-деревьями. Но вы правы, проверка на истину, где истина покрывает 2% набора данных, должна выиграть от сканирования индекса, но опять же, из-за взаимосвязи между размером набора данных и временем запроса я думаю, что Cassandra выполняет полное сканирование (его оптимизатор, вероятно, более примитивен, чем установленная СУБД). Кроме того, вы пытались изменить строку true|false на логический примитив? - person Martin Gallagher; 29.08.2012