BigQuery替代中型数据

Question

这是为什么BigQuery在小数据集上表现不佳的问题的后续问题.

假设我有一个大约1M行的数据集.在我们正在使用的当前数据库(mysql)中,聚合查询运行速度很慢,可能需要大约10秒左右的复杂聚合.在BigQuery上,所需的初始化时间可能会使这个查询花费大约3秒,比在mysql中更好,但是如果我们需要在1s或更低版本中返回查询,那么该工作的工具是错误的.

那么我的问题是,使用BigQuery对中等大小的数据集(例如1-10M行)进行聚合查询会有什么好的选择？示例查询可能是:

SELECT studio, territory, count(*)
FROM mytable
GROUP BY studio, territory
ORDER BY count(*) DESC

我想到的可能解决方案是ElasticSearch(https://github.com/NLPchina/elasticsearch-sql)和Redshift(postgres太慢).什么是可以通过SQL查询的好选择？

注意:我不是在寻找为什么或如何使用 BQ,我正在寻找10M行以下数据集的替代方案,其中查询可以在~1s内返回.

Answer 1

如果您在不到一秒的时间内需要答案,则需要考虑索引.

典型故事:

1. MySQL(或此处提出的任何其他数据库)很快,直到......
2. 有一天,你的一些聚合查询开始运行缓慢.分钟,小时,天等
3. 步骤2的典型解决方案是索引和预聚合.如果您想在某种类型的问题中在不到一秒的时间内得到答案,那么您需要投入时间和优化周期来回答这类问题.
4. BigQuery的美妙之处在于您可以跳过第3步.将这些分钟/小时/天带到秒,只需最少的投资 - 任何查询,随时.

BigQuery很棒,因为它给你4.但是你要求3,MySQL就可以了,Elasticsearch也很好,任何索引数据库都会在不到一秒的时间内为你带来结果 - 只要你花时间优化你的系统对于某些类型的问题.然后,在不投入任何优化时间的情况下获得任意问题的答案,请使用BigQuery.

BigQuery:将在几秒钟内回答任意问题,无需准备.

MySQL和替代方案:将在不到一秒的时间内回答某些类型的问题,但需要花费一些时间才能实现.

Answer 2

以下是此尺寸数据的一些替代方案:

1. 单个Redshift小型SSD节点
   • 没有设置.在1s以下轻松返回这么多数据的答案. 
2. Greenplum在一个小T2实例上
   • Postgres的样.与Redshift相似的性能.不支付存储费用,你不需要.从他们的单节点"沙盒"AMI开始.
3. MariaDB Columnstore
   • 类似MySQL的.曾经被称为InfiniDB.非常好的表现.由MariaDB(公司)提供支持.
4. Apache Drill
   • Drill与BiqQuery有着非常相似的理念,但可以用于任何地方(它只是一个罐子).此大小数据的查询速度很快.

如果低管理/快速启动很关键,请使用Redshift.如果金钱/灵活性至关重要,请从Drill开始.如果您更喜欢MySQL,请使用MariaDB Columnstore.

Answer 3

我知道SQL Server,所以我的答案是有偏见的.

1. 10M行应该很容易适合内存,因此任何类型的聚合都应该很快,特别是如果你有覆盖索引.如果没有,则可能需要调整服务器配置.此外,SQL Server具有所谓的内存表,这可能非常适合这里.

2. SQL Server有一个称为索引视图的功能.您的聚合查询是索引视图的经典用例.索引视图本质上是存储在磁盘上的数据的副本,由服务器自动维护,因为表中的基础数据发生了变化.它会减慢INSERTS,DELETES和UPDATES,但会使SELECT快速,因为摘要总是预先计算的.请参阅:索引视图可以(而且不能)执行的操作.其他DBMS应该具有类似的功能.