cassandra vs elastic search vs任何其他设计建议

rqdpfwrv  于 2021-06-14  发布在  Cassandra
关注(0)|答案(3)|浏览(347)

我们需要对存储在rds中的数据运行分析查询。由于按查询分组和不断增加的表大小,这变得非常缓慢。例如,我们在rds中有以下3个表:

alm(id,name,cli, group_id, con_id ...)
group(id, type,timestamp ...)
con(id,ip,port ...)

每一个表都有非常高的数据量,并且随着新数据的到来,每分钟更新几次。
现在我们要运行聚合查询,如:

select name from alm, group, con where alm.group_id=group.id and alm.con_id=con.id group by name, group.type, con.ip

我们还希望用户将来运行自定义聚合查询,而不是我们将来提供的修复查询。
到目前为止,我们正在考虑的选择是移动到Cassandra,elasticsearch或迪纳摩数据库,以便聚合将更快。有人能指点一下如何解决这个问题吗?或者有什么经验?有人知道任何技术都比其他技术有很大的优势吗?

fdx2calv

fdx2calv1#

储存在Parquet地板和使用Spark,分区有效

evrscar2

evrscar22#

另外一个选择是面向列的数据库,这种数据库更适合于“分析”的情况,当你有许多数据字段,你想执行聚合或提取一些字段的子集为大量的数据。
最近yandex clickhouse变得非常流行,amazon-redshift提供了面向列的服务。还有其他几种解决方案

dohp0rv5

dohp0rv53#

cassandra和dynamodb与elasticsearch有很大的不同。而且这三个都与关系数据库产品有很大的不同。
对于ad-hoc分析,具有良好设计模式的关系数据库可能非常好,以至于您需要在多个服务器上拆分数据(然后复制问题开始占据优势)。这正是非关系数据库的主要动机。但问题是,为了解决横向扩展问题,它们通常会交换一些特性,如连接和聚合。
ElasticSearch非常擅长回答搜索查询,但并不擅长聚合(除了非常基本的计数、总和及其估计)。它在索引大量数据方面非常出色,但是它不能回答涉及多个索引的查询。
如果您的数据量很大,并且需要聚合,那么您几乎有两种选择:
如果你能摆脱离线分析,那么像spark这样的分布式数据处理框架可以非常有效地为你提供所需的答案
如果您需要在线分析,最常用的方法是预先计算聚合并在获得更多数据时进行更新,这样就可以非常快速地回答查询,而不必为每个查询处理大量数据
不过,不要害怕混搭。关系型数据库和非关系型数据库一样有其用途。不过,没有银弹。

相关问题