实时查询数十亿条记录

n3h0vuf2  于 2021-06-09  发布在  Hbase
关注(0)|答案(2)|浏览(511)

我正在从事一个数据驱动的分析软件项目,该项目产生关于财务数据(交易)的报告和建议。数据由17亿条记录组成,每天新增20万条记录。每个记录都描述了一个数据非常小的事务(从账户到账户、金额、时间戳等)。
一旦写入,数据就不需要更改(因此本质上它是一个蠕虫范例),但查询可能变得相当复杂。一些查询是aml(反洗钱)逻辑,用于查找账户之间的关系,例如“u形转弯”交易: A->B->C->D->A 我需要运行多个查询来检测这种模式,只要每个帐户有一个“正常”的交易量,查询时间就相当快。如果帐户c(在上面的示例中)突然有数百万个事务,并且查询运行60秒或更长时间,而不是0.5秒,那么问题就会出现。
我倾向于使用neo4j来搜索帐户之间的关系-但我不确定搜索是否足够快。其他的解决方案可以是内存数据库,比如memsql、redis或aerospeck——我也在研究hbase/hadoop或couchdb、mongodb。
哪个堆栈将提供当前可能的最快查询结果?

wgeznvg7

wgeznvg71#

我建议您选择一个基于内存的数据库,使用适当的8或16gigs内存。要实现分析写入,请尝试使用作业队列,例如:rabbitmq,至少达到17亿个记录。redis或memcache可以毫无问题地处理您的每日写入(200k),甚至可以进行调整,特别是在您并不真正需要事务的情况下(阅读有关redis的批处理方法)。
这是一篇有趣的帖子,介绍instagram如何使用redis为每个用户绘制超过3亿张图片。
http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value
http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram
但是请注意,这种内存数据库是一个键值存储,这意味着没有复杂的数据和复杂的查询。
另一种选择是尝试elasticsearch,它有一些好处,可以使任务更容易。verizon用它来存储超过5000亿条记录,这并不意味着每个人都能做到,但至少它显示了这一点
有关elasticsearch,请参见以下链接:
https://sematext.com/blog/2013/07/08/elasticsearch-refresh-interval-vs-indexing-performance/
我听说hbase/hadoop和couchdb在大型集合上运行得很好,但不能提供更多的信息,因为我并不真正使用它。
希望这有帮助!

wb1gzix0

wb1gzix02#

每一类数据库都有它的长处,对于aml用例,您描述的图形数据库(如neo4j)将是正确的选择。?
像couchbase或mongo这样的文档存储没有什么意义,而像aerospike和redis这样的键值存储只有在您感兴趣的恒定路径长度可以预先计算的情况下才有意义。当您尝试查找从给定节点开始并以该节点结束的所有路径时,不管边的数目如何,这是不可能的。

相关问题