Cassandra 3.x производительность чтения со 100 столбцами в строке - PullRequest
Новая
       0

Cassandra 3.x производительность чтения со 100 столбцами в строке

0 голосов
/ 17 марта 2020

У меня есть следующие 2 модели: 

CREATE TABLE easyprofit.test2 (
plug int,
day int,
hour int,
created timestamp,
created_sampled_3 text,
kwh_app_totale decimal,
PRIMARY KEY ((plug, day, hour), created)) WITH CLUSTERING ORDER BY (created DESC)
AND read_repair_chance = 0.0
AND dclocal_read_repair_chance = 0.1
AND gc_grace_seconds = 864000
AND bloom_filter_fp_chance = 0.01
AND caching = { 'keys' : 'ALL', 'rows_per_partition' : 'NONE' }
AND comment = ''
AND compaction = { 'class' : 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy', 'compaction_window_size' : 1, 'compaction_window_unit' : 'DAYS', 'max_threshold' : 32, 'min_threshold' : 4 }
AND compression = { 'chunk_length_in_kb' : 64, 'class' : 'org.apache.cassandra.io.compress.LZ4Compressor' }
AND default_time_to_live = 0
AND speculative_retry = '99PERCENTILE'
AND min_index_interval = 128
AND max_index_interval = 2048
AND crc_check_chance = 1.0
AND cdc = false;

CREATE TABLE easyprofit.test3 (
plug int,
day int,
hour int,
created timestamp,
acqua_app_totale double,
acqua_giornaliero_locale double,
acqua_giornaliero_locale_1000 double,
acqua_lt_totali_app_gg double,
acqua_totale_locale double,
acqua_totale_locale_1000 double,
allarme_cos_fi_down double,
allarme_frequenza_down double,
allarme_frequenza_up double,
allarme_i1_up double,
allarme_i2_up double,
allarme_i3_up double,
allarme_v1_down double,
allarme_v1_up double,
allarme_v2_down double,
allarme_v2_up double,
allarme_v3_down double,
allarme_v3_up double,
corrente_fase_1 double,
corrente_fase_1_generale double,
corrente_fase_2 double,
corrente_fase_2_generale double,
corrente_fase_3 double,
corrente_fase_3_generale double,
corrente_nominale double,
corrente_nominale_i1 double,
corrente_nominale_i2 double,
corrente_nominale_i3 double,
cos_fi double,
created_sampled_12 int,
created_sampled_3 int,
created_sampled_60 int,
delivery_off_time timestamp,
delivery_on_time timestamp,
delivery_status int,
euro_acqua_app_totale double,
euro_acqua_lt_totali_app_gg double,
euro_gas_app_totale double,
euro_gas_sm3_totali_app_gg double,
euro_kvarh_app_totale double,
euro_kvarh_gg double,
euro_kwh_app_totale double,
euro_kwh_gg double,
euro_totale_app_totale double,
fattore_potenza_cos_fi double,
force_off_time timestamp,
force_on_time timestamp,
force_status int,
frequenza double,
frequenza_hz_10 double,
gas_app_totale double,
gas_giornaliero_locale double,
gas_giornaliero_locale_1000 double,
gas_sm3_totali_app_gg double,
gas_totale_locale double,
gas_totale_locale_1000 double,
inutilizzata double,
kvarh_app_totale double,
kvarh_giornaliero_locale double,
kvarh_giornaliero_locale_1000 double,
kvarh_totale_locale double,
kvarh_totale_locale_1000 double,
kwh_app_totale double,
kwh_giornaliero_locale double,
kwh_giornaliero_locale_1000 double,
kwh_totale_locale double,
kwh_totale_locale_1000 double,
letture_nel_periodo int,
min_sec_taglio_picchi_presa_1 double,
min_sec_taglio_picchi_presa_10 double,
min_sec_taglio_picchi_presa_11 double,
min_sec_taglio_picchi_presa_12 double,
min_sec_taglio_picchi_presa_13 double,
min_sec_taglio_picchi_presa_14 double,
min_sec_taglio_picchi_presa_15 double,
min_sec_taglio_picchi_presa_16 double,
min_sec_taglio_picchi_presa_17 double,
min_sec_taglio_picchi_presa_18 double,
min_sec_taglio_picchi_presa_19 double,
min_sec_taglio_picchi_presa_2 double,
min_sec_taglio_picchi_presa_3 double,
min_sec_taglio_picchi_presa_4 double,
min_sec_taglio_picchi_presa_5 double,
min_sec_taglio_picchi_presa_6 double,
min_sec_taglio_picchi_presa_7 double,
min_sec_taglio_picchi_presa_8 double,
min_sec_taglio_picchi_presa_9 double,
orario_app_totale text,
orario_forzatura_off double,
orario_forzatura_on double,
orario_prima_forzatura double,
orario_quarta_forzatura double,
orario_quinta_forzatura double,
orario_seconda_forzatura double,
orario_sesta_forzatura double,
orario_terza_forzatura double,
picco_massimo_richiesto_w_100 double,
picco_massimo_richiesto_w_100_generale double,
potenza_attiva_istantanea double,
potenza_attiva_istantanea_minuto_1 double,
potenza_attiva_istantanea_minuto_2 double,
potenza_attiva_istantanea_minuto_3 double,
potenza_attiva_istantanea_w_100 double,
potenza_attiva_kwh_gg_app double,
potenza_reattiva_istantanea double,
potenza_reattiva_istantanea_var_100 double,
potenza_reattiva_kvarh_gg_app double,
rele_forced_status int,
serial_off int,
switch_on int,
switch_on_time text,
temperatura_1 double,
temperatura_10 double,
temperatura_2 double,
temperatura_3 double,
temperatura_4 double,
temperatura_5 double,
temperatura_6 double,
temperatura_7 double,
temperatura_8 double,
temperatura_9 double,
tempo_giornaliero_locale double,
tempo_prima_forzatura double,
tempo_quarta_forzatura double,
tempo_quinta_forzatura double,
tempo_seconda_forzatura double,
tempo_sesta_forzatura double,
tempo_terza_forzatura double,
tempo_totale_locale double,
tensione_concatenata_v1_2 double,
tensione_concatenata_v2_3 double,
tensione_concatenata_v3_1 double,
tensione_v1_2 double,
tensione_v2_3 double,
tensione_v3_1 double,
totale_giornaliero_locale_1000 double,
totale_locale_1000 double,
totale_potenza_attiva double,
totale_potenza_attiva_kwh_100 double,
totale_potenza_reattiva double,
totale_potenza_reattiva_kvarh_100 double,
tp_off_time timestamp,
tp_on_time timestamp,
tp_status int,
PRIMARY KEY ((plug, day, hour), created)) WITH CLUSTERING ORDER BY (created DESC)
AND read_repair_chance = 0.0
AND dclocal_read_repair_chance = 0.1
AND gc_grace_seconds = 864000
AND bloom_filter_fp_chance = 0.01
AND caching = { 'keys' : 'ALL', 'rows_per_partition' : 'NONE' }
AND comment = ''
AND compaction = { 'class' : 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy', 'compaction_window_size' : 1, 'compaction_window_unit' : 'DAYS', 'max_threshold' : 32, 'min_threshold' : 4 }
AND compression = { 'chunk_length_in_kb' : 64, 'class' : 'org.apache.cassandra.io.compress.LZ4Compressor' }
AND default_time_to_live = 0
AND speculative_retry = '99PERCENTILE'
AND min_index_interval = 128
AND max_index_interval = 2048
AND crc_check_chance = 1.0
AND cdc = false;

В две таблицы загружен один и тот же набор данных. Каждая строка содержит данные от разных датчиков на основе отметки времени. Короче говоря, это временные ряды.

Запрос, который я выполняю для каждой таблицы (используя драйвер python datastax): 

SELECT plug, created, kwh_app_totale FROM test3/test2 WHERE plug = 70 AND day = ? AND hour = ? ORDER BY created ASC
  • в таблице test2 запроса тукс 20с
  • в таблице test3 запрос тукс 90с

Единственная разница между двумя таблицами заключается в количестве столбцов в строке.

Вопрос заключается в следующем: Как количество строк влияет на запрос? Кажется, что вся строка читается также, если запрос запрашивает несколько столбцов.

Как мне решить эту проблему?

1 Ответ

0 голосов
/ 19 марта 2020

Такое поведение ожидается, и причина в том, что C* должен проверять каждую строку, чтобы увидеть, существует ли значение столбца.

Из таблицы вашего примера в любой момент времени вы можете заполнить / вставить любой данный столбец (или набор столбцов). Это означает, что вы можете вставить значение только для одного столбца, а позже вставить остальные столбцы. В отличие от реляционной базы данных, эти записи в настоящее время не размещены. Поэтому во время чтения все эти записи, принадлежащие определенной строке, должны быть объединены.

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

Одним из способов оптимизации, если это возможно, является включение kwh_app_totale в качестве последнего столбца в ключе кластеризации. Понимание того, что это изменит уникальную комбинацию клавиш, но будет работать лучше, так как больше не придется полагаться на значения фактических столбцов, кроме первичного ключа, для обслуживания вывода.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...