Является ли применение поля состояния is_deleted в качестве составного первичного ключа в таблице cassandra для чтения хорошей практикой? - PullRequest
0 голосов
/ 17 января 2019

Я настраиваю новую реактивную службу отдыха cassandra весной, а затем есть поле «по умолчанию», такое как is_deleted, is_active, storeid и т. Д., Для всех таблиц.

Поскольку предполагается, что is_deleted необходим для запроса where. Он создан как один из составных ПК, так что поиск данных будет быстрее.

Проблема в том, что первичный ключ очень толстый, а поисковый запрос становится настолько длинным, что ему нужно упомянуть все ключи по умолчанию.

Является ли хорошей практикой иметь такой толстый составной ПК на кассандре?

@PrimaryKeyColumn(name = BaseCassandraFields.STORE_ID, type = PrimaryKeyType.PARTITIONED)
  protected String storeId;

@PrimaryKeyColumn(name = BaseCassandraFields.IS_DELETED, type = 
PrimaryKeyType.PARTITIONED)
  protected Boolean isDeleted = false;

Пример таблицы

Также вот DDL

1 Ответ

0 голосов
/ 18 января 2019

Это не влияет на Cassandra внутри, но если вам не нужны все эти ключи, вы напрасно делаете акцент на части разработки. Лично я нахожу странным иметь булевы значения в PK, но ваш вариант использования может оправдать это.
Можно утверждать, что, возможно, у Кассандры есть некоторые дополнительные затраты на вычисление хэша для ключа из-за большего количества столбцов, но я сомневаюсь, что это важно, поскольку хэш-функции обычно имеют высокую производительность.

...