如何处理500M +项目的查询

8

我的数据结构如下：

date: <timestamp>
filter_a: <integer> -> range [0, 1000]
filter_b: <integer> -> range [0, 1000]
filter_c: <integer> -> range [0, 86400]
filter_d: <integer> -> range [0, 6]
group: <string>
second_group: <integer>
variable_a: <float>
variable_b: <float>
variable_c: <float>
a couple more no very important

我需要执行以下查询：

第一：

通过筛选数据date，filter_a，filter_b，filter_c和其他人

其次，用过滤后的数据：

计算所有记录
得到平均的variable_a，variable_b并variable_c
得到标准差的variable_a，variable_b并variable_c
拿到四分位数 的variable_a，variable_b而variable_c
按group或second_group汇总数据（计数，平均，标准，..）

该系统的用户数量约为10或15，但是项目数量非常庞大，目前为70M，但在几周内将达到500M，大约一年后将达到1000M。

查询的数量很小，并发用户不超过10个，我的问题是如何使用大量数据处理这些查询。

到目前为止，我尝试了什么？

我从开始就开始mongodb，开始时很快，但是在计算10M +的四分位数时却变慢了。当我添加索引时，它有所改善，但是当我不得不查询所有数据时，它并没有太大帮助。我开始使用mongodb是因为数据非常动态，但是幸运的是数据格式“不会再改变了”。
正如filter_a并且filter_b可以像节点一样，我尝试过neo4j。我非常喜欢neo4j，但是我的图形有很多边，因此查询不是很快。
最后，由于数据格式不会改变，并且它只是一个集合/表，因此不需要在SQL中联接，因此我检查了postgresql。使用postgresql进行测试的速度更快，但我担心将来无法正确扩展。

我需要什么？

在这种情况下，PostgreSQL是一个不错的选择吗？
我可以使用另一种数据库吗？哪种情况最适合这种情况？
我还能做些什么来改善它？

编辑

每天大约插入1M个元素，并且此后“不应更改”。
写入速度并不重要
硬性要求是快速读取/汇总

谢谢！

— 安德烈斯
source

1

SQL Server中的索引视图/ Oracle中的已转换视图怎么样？这些是基表的运行汇总，因此在对基表进行修改时，索引也会被动态修改。然后，您始终可以查询已经为您计算的聚合。

— 阿里·拉泽吉

@AliRazeghi索引视图是个好主意。无论如何，首先我想选择最佳的数据库/设计，然后再优化查询本身

— Andres

1

对于纯粹在Postgres中进行优化，我想说BRIN索引可以在这里提供帮助，但是除了阅读它们之外，我没有做任何其他事情。postgresql.org/docs/9.5/static/brin-intro.html

— Erik Darling

1

我个人在OLTP服务器上继承了数十亿行报告数据库，而没有大量内存。幸运的是，查询最多的部分是滚动的“最近3周”，但并非没有听说过表扫描。老实说，通过使用非常好的压缩，分区，分区消除，分区方案，SAN缓存优化以及删除未使用的索引，我们在MS SQL 2008 Ent上获得了非常好的性能。对于PGSQL来说，十亿不会太难。每行有多少宽度，或者您认为每行将占用多少空间，每个表或输入过程将有多少索引？

— 阿里·拉泽吉

2

@Andres很好，这取决于它所在的数据库引擎以及每行的最大大小，因此我们可以进行计算。例如PostgreSQL有varchar而只有char，char很容易计算，varchar我们必须猜测平均长度。如果我们可以知道它是什么字段类型（除非它是Mongo或某种以其自己的格式存储在文档中的东西），我们期望每个字段中大约有多少个字符以及带有列的索引数。8GB的RAM听起来太低了，无法有效地将其从内存中拉出，特别是如果该RAM与服务器上的其他表和资源共享。

— 阿里·拉泽吉

5

建议您不要依赖关系数据库对时间序列数据执行这些统计计算，而是建议您将数学和后处理工作从数据库外部移至客户端应用程序中。

使用Python或Ruby之类的脚本语言，您可以通过在固定宽度的时间段内查询数据的“块”，计算中间的统计摘要，然后将结果合并为多个块，从而逐步解决问题在整个历史上。一些统计指标很难跨块合并，但是类似Avg（）的每个块只需要sum（）和count（），O（1）与O（chunksize），因此块合并可能会很好地扩展。

— 杰皮尔
source

我尝试使用python / pandas这样的东西。演算速度更快（几秒钟），但检索所有数据的速度很慢。也许更好的方法chunksize会有所帮助。+1

— Andres

1

由于您的数据不会更改，并且只会附加数据，因此我会将数据存储在您喜欢的任何位置；以Amazon S3为例，但是任何快速读取的数据库都可以。没有索引。您选择的数据库/ FS应该可以选择读取存储桶中的数据：例如，每天可能有一个文件，其中包含1M条记录。

然后，我将使用Spark进行过滤/分析。它基于群集，您可以根据需要进行扩展。

— 狮子座
source

我同意，我已经每天分离数据集。我也正在考虑HDFS和HBase

— Andres

0

响应取决于此后您将如何使用数据。如果要更好地处理，请使用Cassandra，如果要更好地进行分析，请使用Hive。

— Artemy原型制作
source

我知道蜂巢并不是最好的选择real time。我错了吗？

— 安德列斯（Andres）2016年

1

是的，HBase用于实时读取/写入。但是卡桑德拉也可以做到。但是我认为HBase更好。

— Artemy原型设计

0

这种情况是使用Ralph Kimball等公司完善的技术在SQL Server等平台（我最熟悉的平台）上进行数据仓库的理想选择。它们是专门为这种情况而设计的：大量相对静态的数据记录，为此您需要计算此类汇总。没有关系技术将适合在此类应用程序中正确实现的数据仓库，尽管如果您的组织根本无法负担实现它们的软件包（如SQL Server Analysis Services）的许可证，则某些技术肯定会比其他技术更好。在实现针对此类数据访问量身定制的MDX之类的语言时，还有一条学习曲线。如果数据仓库对于您的组织来说是可行的选择，那么不要浪费时间寻找关系解决方案；这不是关系数据库问题。如果需要的话，我可以发布一些有关Kimball等的基本参考，以及指向SSAS和MDX的链接（很抱歉，我无法帮助Oracle和我不熟悉的其他竞争对手）文档。希望对您有所帮助。

— SQLServerSteve
source