Cassandra 3.x 读取性能，每行 100 列

Question

我有以下两种型号：

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 秒

两个表的唯一区别是每行的列数。

问题是：行数如何影响查询？如果查询要求几列，似乎也会读取整行。

我该如何解决这个问题？

Answer 1

这种行为是意料之中的，原因是 C* 必须检查每一行以查看列值是否存在。

在您的示例表中，您可以在任何给定时间填充/插入任何给定列（或一组列）。这意味着您可以只为一列插入值，然后再插入剩余的列。与关系数据库不同的是，这些记录现在不是共存的。因此，在读取期间，属于特定行的所有这些记录都需要合并。

现在这会导致在给出 select 中所需的列之前读取几乎整个列列表。

如果可能的话，在此进行优化的一种方法是将kwh_app_totale 作为聚类键中的最后一列。了解这将更改唯一键组合，但它会表现得更好，因为它不再需要依赖除主键之外的实际列的值来提供输出。