我在GreenPlum上创建了下表:
CREATE TABLE data."CDR"
(
mcc text,
mnc text,
lac text,
cell text,
from_number text,
to_number text,
cdr_time timestamp without time zone
)
WITH (
OIDS = FALSE,appendonly=true, orientation=column,compresstype=quicklz, compresslevel=1
)
DISTRIBUTED BY (from_number);
我已经为这个表加载了10亿行,但每个查询的工作都很慢。
我需要对所有字段(不仅是一个)进行查询,
我该怎么做才能加快查询速度?
使用PARTITION?使用索引?
也许使用像Cassandra或Hadoop这样的不同数据库?
答案 0 :(得分:4)
这在很大程度上取决于您正在进行的实际查询以及您的硬件设置。
由于您正在查询所有字段,因此您需要扫描所有数据,因此通过进行柱状定位获得的选择性可能会对您造成伤害,而不是帮助您。我会删除柱状方向。
一般而言,指数对Greenplum系统没有帮助。通常,涉及的硬件数量往往比执行索引查找更快地扫描数据目录。
分区可能是一个很大的帮助,但需要更好地理解数据。您可能正在访问特定的时间间隔,因此围绕cdr_time创建分区方案可以消除对结果不需要的数据的扫描。我担心的最后一件事是索引。
from_number的发布可能会影响查询速度。系统将根据from_number对数据进行散列,因此如果您有选择地查询from_number,数据将仅由具有它的节点返回,您将不会利用系统的并行性质并将请求分散到所有节点。除非您要加入from_number上的其他表,这允许在节点内并置并执行连接,否则我会将其更改为随机分发。
除此之外,还有一个问题是硬件是什么,以及是否有适当数量的网段设置和资源来提供它们。基本上每个细分都是一个数据库。良好的硬件可以处理每个节点的多个段,但如果您在轻型硬件上执行此操作,则需要找到其中段数与底层系统可提供的匹配的最佳位置。
答案 1 :(得分:0)
@Dor,
我有相同类型的数据,其中存储了针对电信公司的CDR信息,并且每天插入了10到12百万行,并且在那些与CDR相关的表上运行了大量查询,去年我也遇到了同样的问题,而且我已在 CDR时序列上的这些表上创建了分区。
根据我的理解,GP为每个分区创建物理表,而在其他RDBMS中创建逻辑表。在此之后,我在这些表上使用所有SELECT获得了更好的性能。另外我认为你应该将text数据类型转换为Character Varying for all columns(如果文本真的不是必需的)我感觉文本字段上的数据库操作非常慢(特别是按顺序排列,分组)
索引将帮助你取决于你的查询在我的情况下我有大量插入所以我没有尝试
如果您选择select中的所有列,则不需要Column Oriented表
此致