Question

这是问题Why doesn't BigQuery perform as well on small data sets的后续行动。

假设我有一个约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

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

典型故事：

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

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

BigQuery：将在几秒钟内回答任意问题，无需准备。

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

Answer 2

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

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

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

Answer 3

我知道SQL Server，所以我的回答是有偏见的。

10M行应该很容易适合内存，因此任何类型的聚合都应该很快，特别是如果你有覆盖索引。如果没有，则可能需要调整服务器配置。此外，SQL Server具有所谓的in-memory tables，这可能非常适合。
SQL Server有一个名为indexed view的功能。您的聚合查询是索引视图的经典用例。索引视图本质上是存储在磁盘上的数据的副本，由服务器自动维护，因为表中的基础数据发生了变化。它会减慢INSERTS，DELETES和UPDATES，但会使SELECT快速，因为摘要总是预先计算的。见：What You Can (and Can’t) Do With Indexed Views。其他DBMS应该具有类似的功能。

Answer 4

如果您不需要并发，多个用户同时连接，并且您的数据可以放在一个磁盘文件中，那么SQLite可能是合适的。

正如他们所说，SQLite不会与客户端/服务器数据库竞争。 SQLite与fopen（）竞争。

http://www.sqlite.org/whentouse.html

Answer 5

我认为Microsoft SQL Server Analysis Services是一个不错的选择，我自己使用，它是PowerBI服务背后的数据库，它有一个非常好的免费层选项。

如果你想要一个免费的内部部署解决方案，你可以随时使用SQL Server express和新的columnstore技术，我自己没有使用它，但我听到了一些非常好的结果

Answer 6

如果这是您唯一的查询，那么这将使其运行得更快：

INDEX(studio, territory)  -- in either order.

如果还有其他变体，请查看它们，再加上SHOW CREATE TABLE。

要检查的另一件事：你有多少RAM，innodb_buffer_pool_size的价值是多少？该设置应该是RAM的70％左右（如果你有超过4GB的RAM）。

Answer 7

请勿使用COUNT(*)。

在单个列上使用COUNT()，最好是PRIMARY KEY之类的索引列。

Answer 8

我的答案：优化查询和表结构，如前所述（1秒或更短）。请继续阅读下面的进一步推理，因为我们都陷入了这个陷阱。注意：以上不一定是大数据集。

一个很好的问题。解读什么是问题以及什么是解决方案是如此艰难。这是来自旧学校的镜头。在过去，我们会说你问硬件，操作系统或开发人员问题/解决方案是什么，你会得到三个不同的答案。

我的理解是这个问题要求解决/比较SQL性能问题与云基础架构解决方案。这个问题将根据背景有许多不同的答案。令人困惑的是，你只有旧的学校数据库安装（Mysql，Oracle，MSsql），数据库即服务（DBAAS），大数据云解决方案，大数据应用解决方案（hadoop）

很容易被所有这些技术纠缠在一起。也许这里有点清晰。

SQL性能问题可以在各种性能点（POP）中解决。

SQL优化和调优（临时表，内存，OLAP函数，Sql计划，并行化，分析）工具（MySql Workbench，cmdline，Toad等）
结构优化（表，索引，分区，预Ag结构）
数据库配置（内存大小，缓存大小，并行化，块大小等..
操作系统内存，页面大小，进程）
硬件和网络 - 现在大部分都是无关紧要的。
服务器配置。
云配置和群集。
基础架构和软件决策。

底线：我会在这里停下来，我们有很多问题的解决方案。在使用更大技术产生成本解决方案之前，尝试从技术的最基本用途开始。希望这将为用户提供一个工作路径的骨架或在提问时使用的术语。如何让x查询在时间t运行？

Answer 9

你不太谈论你所处的问题空间 - 但你有没有考虑过python pandas，或者R？这些是用于数据分析/开发的出色工具。

假设你有python和pandas方便pip install pandas你可以开始这样的事情：

import pandas as pd
import pyodbc

conn = pyodbc.connect(...) # You'll need to figure out the settings for your DB here
# this slow but only needs to be done once:
data = pd.read_sql_query('select * from mytable') # Load everything into memory 

# Now do the query:
data.groupby(['studio', 'territory']).count().sort_values(ascending=False)

我强烈建议您使用Jupyter Notebooks

尝试使用pandas

Answer 10

如果您正在寻找亚秒级OLAP查询结果，那么德鲁伊（http://druid.io/）就是为此目的而构建的。它是一个部署和调整的野兽，但是一旦你为数据正确配置它就会非常快。它具有流媒体支持，因此您可以从Kafka中获取恰好一次的语义，这非常棒。它可以很好地从小型数据扩展到大量数据 - 尽管您将支付预付费的成本，因此如果您有大量维度，则数据大小会爆炸。 SQL支持最近才被添加并且不完整。此外，它不支持连接，因此您必须正确构建数据以获得答案。

Answer 11

BigQuery意味着在大数据管道的最后表现最佳。它的设计是为了能够很好地处理大型数据集，而不是小型数据集，并不是现有技术的替代品，而是在某些情况下的优秀补充。可以在“Google Cloud大数据和机器学习博客”document中阅读一个示例。

BigQuery替代中型数据

11 个答案: