那些成功的数据库公司没有一家是经过功用比竞争对手更快而成功的。
作者：JORDAN TIGANI，DuckDB 公司 MotherDuck 联合创始人&CEO
本文和封面来源：motherduck.com/，爱可生开源社区翻译。
本文约 4500 字，预计阅览需求 15 分钟。
论数据库功用崇拜
从我在西雅图的家到咱们在旧金山的办公室大约需求 4.5 小时。假定您建造了一架高超音速飞机，其最高速度比一般波音 737-MAX 快 10 倍（无论是否有额定的防风靠窗座椅）。当你考虑乘 Uber 去机场、排队安检、登机、在停机坪上滑行、起飞和降落、等候登机口、等候行李以及乘优步去办公室之后，你就现已完结了一些惊人的豪举工程，但或许只缩短了 20% 的总行程时刻。很好，但我依然参加不上上午 10 点的会议。
数据库行业一直专心于制作更快的飞机。与此同时，安检队伍越来越长，行李也常常丢失。假如您的数据坐落有点不稳定的 CSV 文件中，或许您想要提出的问题很难用 SQL 表述，那么或许抱负的查询优化器也无法协助您。
功用是像我这样的数据库迷用来衡量数据库的最常见方针，而且像体育迷相同，咱们倾向于挑选咱们支撑的球队来对立其他球队。假如您最喜欢的数据库赢得了基准功用测验战争，那么您就有了在饮水机旁边吹牛的权利。您能够炫耀那些有博客文章统计支撑的数据，向任何乐意倾听的人证明您最喜欢的数据库是冠军。
一般来说，依据功用（特别是通用基准测验）挑选数据库是一个糟糕的办法。您最好依据易用性、生态体系、更新速度或其与作业流程的集成程度来做出决议方案。最好的状况是，功用是完结某些使命所需时刻的时刻点视图；可是，最坏的状况是，它会导致您针对过错的作业进行优化。
基准大战完毕
2019 年，GigaOm发布了比较云数据仓库的基准测验报告。他们在三大云供货商以及 Snowflake 上运转 TPC-H 和 TPC-DS。成果？Azure 数据仓库是迄今为止最快的，其次是 Redshift。Snowflake 和 BigQuery 远远落后。
其时，我正在研讨 BigQuery，许多人都吓坏了…… 咱们怎样会比 Azure 慢那么多呢？可是，成果与咱们从用户那里得到的形象并不相符。每次客户对咱们与 Azure 进行正面评估时，他们终究都会挑选 BigQuery。其时的市场成果简直与基准相反：Snowflake 和 BigQuery 终究的销量比 Redshift 好得多，而 Redshift 的销量比 Azure 好得多。
假如基准测验与客户体会不匹配，那么要么基准测验做错了，基准测验测验了过错的东西，要么终究证明功用并不那么重要。咱们进行了许多探索，这不是第一次。GigaOm 人员十分擅长运转基准测验，而且办法也很合理。他们运转的基准测验 TPC-H 和 TPC-DS 是行业标准，而且被广泛的引用。它们是咱们自己在内部运转的基准，用于判断功用，虽然人们或许会对数据大小或其与现实国际作业负载的相关性提出异议，但它们是最好的测验报告。
因而，假如基准很好地体现了功用，而客户终究在很大程度上购买了在基准上体现欠安的体系，那么它会让您信任或许还有比功用更重要的作业。
快意味着什么？
在我从事云数据库作业的 15 年中，我留意到整个行业的一种反智方法：构建数据库的人往往十分重视某人单击“运转”按钮和实践运转之间的时刻。很简单了解为什么数据库人员只重视数据库服务器的相应时刻；究竟那是他们能掌控的范围。但真实对用户产生影响的是完结一项使命所需的时刻，这两个时刻这不是一回事。
在 BigQuery 中，咱们将 JDBC 驱动程序的构建外包给了一家专门构建数据库衔接器的公司。假如您不熟悉 JDBC，它们供给了程序员和商业智能工具用来衔接数据库的通用接口。其时让一位闻名专家构建界面是有意义的。
几年后，在无数客户投诉之后，咱们意识到 JDBC 驱动程序中的过错正在影响功用。从咱们的视点来看，查询运转得很快，只需一两秒。可是驱动程序轮询查询完结并提取成果的办法使得查询看起来花费了几秒钟乃至几分钟的时刻。当存在许多查询成果时，这种影响会加剧，由于即便用户不需求检查一切成果，驱动程序通常也会一次一页地拉取一切成果。有时他们乃至会由于内存不足而溃散。
咱们的工程师花了许多年的时刻来提高查询速度，将查询时刻缩短了几分之一秒。但咱们大多数用户运用的衔接器添加的推迟就现已远远超越咱们节省的推迟。更重要的是，咱们对这个事实彻底视若无睹。Google 没有人真实运用 JDBC 驱动程序，虽然咱们每天晚上都在运转着全套基准测验，但这些基准测验实践上并没有反映出咱们的用户所看到的端到端功用。
就像醉汉在路灯下寻找钥匙相同，咱们只重视咱们能够在服务器上测量的功用。用户看到的查询时刻对咱们来说是不可见的，咱们以为这是其他人的问题。要真实解决问题，而不仅仅是处理问题，需求咱们重新构建对功用的观点。
体现是片面的
功用有必要从用户的视点而不是数据库的视点来衡量。这是一个用户体会问题，就像任何用户体会问题相同，不能用一个数字来描绘。这让许多人感到惊讶，由于他们以为功用就像赛车相同是客观的作业。仅仅由于您能够说兰博基尼比普锐斯更快，他们信任您也应该能够说我的数据库比您的数据库更快。但就像兰博基尼或许无法让我比普锐斯（或自行车，假如有交通）更快地作业相同，数据库的实践作业负载将决议哪一个更快。
片面性受到了不好的批判；人们将其与这样的说法联系起来：“好吧，没有办法知道哪一个更好，所以咱们挑选哪一个并不重要。” 但仅仅由于福特 F150 皮卡和特斯拉 Roadster 之间的差异是片面的，并不意味着我对两者的体会是相同的。数据库也是同样的道理；假如咱们说 Clickhouse 和 Redshift 之间的功用差异是片面的，并不意味着它们是等效的。这仅仅意味着哪一个更快取决于它们的运用办法。
几年前，Clickhouse 发布了 Clickbench，该基准测验标明 Clickhouse 比他们测验的几十个数据库更快。这让我感到惊讶，由于其时我在 SingleStore 作业，咱们信任咱们的速度比 Clickhouse 快得多。在深入研讨基准之后，咱们发现该基准没有履行任何 JOIN，因而在单个表中进行操作，而且还严重依赖于对不同项目进行计数。
虽然您或许以为发布仅履行单表扫描的基准测验很庸俗，但 Clickbench 实践上在代表许多实践作业负载方面做得相当好。假如您进行许多日志剖析并需求计算网站的不同用户，这或许是功用的杰出代理。也就是说，假如您运用星型方法运转更传统的数据仓库作业负载，Clickbench 将会产生误导。
供货商基准往往重视供货商做得好的作业。下图是来自“公平基准测验被以为很困难” 的图表，描绘了典型的供货商基准测验成果。
数据库基准测验存在许多圈套，经验标明基准测验通常在捕获广泛的用户感知功用方面体现欠安。例如，BigQuery 在基准测验中体现得很差，但许多人的实践体会是功用很奇特。BigQuery 亲身体现得很好，由于它没有任何旋钮，而且在很大程度上是自我调整的。高度调优的 SingleStore 实例在大多数使命中都会压垮 BigQuery，可是您有时刻花在调优架构上吗？当您添加新的作业负载时会产生什么？
DuckDB 网站曾经有一个免责声明，上面写着：“请不要诉苦功用，咱们在努力提高速度之前会先重视正确性。” 并非一切数据库都选用相同的办法。你能够经过去掉安全气囊、牵引力操控、溃缩区、排放操控等安全装置来让轿车跑得更快。但大多数人不想这样驾驭轿车。数据库也不例外；假如删除溢出检查、不改写写入、为某些操作供给近似成果或不供给 ACID 保证，则能够使它们更快。一些在这些基准测验中体现杰出的体系运用了这些捷径，但除非在受控环境下，不然我不想运用它们。
未来的改变
当您挑选数据库时，该数据库在该时刻点并没有冻结。您或许终究会坚持自己的决议数年。从现在到明年，数据库的功用和功用将会产生很大改变，从现在到五年后更是如此。
因而，一个十分重要的变量不仅是数据库现在能够做什么，还在于未来一年能够做什么。假如数据库中的过错导致您挑选竞争对手，那么在短短几周内，假如该过错已被修复，那么这将看起来是一个愚笨的原因。这关于功用来说也是如此。假如两个不同的数据库以不同的速度改善，那么您最好挑选移动速度更快的数据库。未来的你会感谢你。
没有魔豆
假如你选用一堆数据库，一切这些数据库都得到活跃维护，并迭代它们几年，功用将会趋于共同。假如 Clickhouse 正在运用一种能够使其在扫描速度方面具有优势的技能，那么 Snowflake 或许会在一两年内拥有这种优势。假如 Snowflake 添加增量物化视图，BigQuery 很快就会跟进。跟着时刻的推移，重要的功用差异不太或许持续存在。
虽然这些公司的工程师都很聪明，但他们都没有任何魔法或无法在其他当地复制的东西。每个数据库都运用不同的技巧来取得杰出的功用。一种或许将查询编译为机器代码，另一种或许将数据缓存在本地 SSD 上，第三种或许运用专门的网络硬件进行洗牌。只要有时刻，任何人都能够施行一切这些技能。假如它们运作杰出，它们或许会出现在任何当地。
Fivetran 的首席履行官 George Fraser 宣布了一篇风趣的文章，比较了首要数据仓库供货商随时刻的体现；虽然 2020 年的分散程度相当大，但到 2022 年，它们会更加紧密地聚集在一起。2020 年最快 8 秒，最慢 18 秒，2022年有 3 家厂商在 7 秒左右，最慢 9 秒。
当然，这条规矩需求留意的是，架构差异很难克服。与同享磁盘比较，无同享数据库处于劣势，Redshift 花了许多年才切换到首要同享磁盘架构。依赖于将元数据耐久保存到方针存储的 Lakehouse 将很难快速更新；这是内置于模型中的。但这些类型的差异往往会体现在利润率上。例如，从长远来看，Redshift 没有比 Snowflake 更快或更慢的根本原因。
问题出在椅子和键盘之间以及键盘和数据库之间
关于用户来说，衡量功用的重要方针是他们提出问题和得到答案之间的时刻；这或许与数据库运转查询所花费的时刻有很大不同。
假如你退后一步，从他们的视点思考，你能够运用更多的手法来实现最大限度地缩短问题提出和回答之间的时刻的方针。您能够更轻松地提出问题。您能够更轻松地将查询成果转换为他们能够了解的内容。当他们没有提出正确的问题时，您能够协助他们取得反馈。您能够协助他们了解数据何时出现问题。您能够协助他们在正确的方位以正确的方法获取所需的数据，以便能够首要提出问题。虽然这些通常不被以为是功用问题，但与更好的查询方案比较，改善能够在更大程度上加速剖析师和数据工程师的作业流程。
Snowflake 在使编写查询变得更简单方面做得十分超卓。虽然许多 SQL 方言都坚持语法共同，而且应该有“一种办法”来完结一切作业，但 Snowflake 设计者的方针是让用户键入的 SQL “正常作业”。例如，在 Snowflake SQL 中，假如要计算两个日期之间的差异，能够运用 DATEDIFF 或 TIMEDIFF；两者都适用于任何合理的类型。您能够指定粒度，也能够不指定。您能够围绕粒度运用引号，也能够不运用引号。因而，假如您仅仅输入查询，只要能够搜集意图，它就应该“正常作业”。这是剖析师喜欢 Snowflake 的原因之一，由于他们不用花时刻在文档中查找内容。
数据并不总是选用便利查询的格局。国际上许多的数据都存储在 CSV 文件中，其间许多文件的结构很差。虽然如此，大多数数据库供货商并没有认真对待它们。在 BigQuery 中，我编写了第一个 CSV 拆分器，当发现它是一个比预期更棘手的问题时，咱们派了一位新的研讨生工程师来解决这个问题。它历来都不是很好，无法进行推理，而且假如不同的文件具有略微不同的方法，就会感到困惑。事实证明，CSV 解析实践上很困难。
假如运用两个不同数据库的两名工程师需求读取 CSV 数据并计算成果，则能够最轻松地正确提取 CSV 文件的工程师或许会第一个得到答案，无论他们的数据库履行查询的速度有多快。因而，CSV 文件推断能够被视为一项功用功用。
数据库处理成果的办法对用户体会有着巨大的影响。例如，许多时候人们运转“SELECT *”查询来测验了解表中的内容。依据数据库体系的架构办法，此查询能够是瞬时的（返回第一页和游标，如 MySQL），关于大型表或许需求数小时（假如有必要在服务器端复制表，如 BigQuery） ），或许或许会耗尽内存（假如它测验将一切数据拉入客户端）。客户端是否与服务器有长时刻运转的衔接，这或许会出现网络中断的问题？或许它们进行轮询，这或许意味着查询能够在轮询周期之间完结，并使查询显得更慢？
综上所述
最成功的数据库公司没有一家是经过比竞争对手更快而取得成功的。Redshift 曾一度称雄，而让 Snowflake 进入市场的是可维护性，而不是基准测验的功用。以功用为首要卖点的数据库在市场上体现欠安。让作业变得简单完结的数据库体现要好得多。
总结一下：
- 没有魔豆；除非架构存在差异，不然功用将跟着时刻的推移而趋于共同。
- 数据库引擎以截然不同的速度开展；举动最快的人将是最后的胜利者。
- 当心最关怀功用的数据库供货商；从长远来看，这会减慢他们的速度。
- 没有单一的数据库功用方针；“快速”数据库或许会严重影响您的作业负载。
- 数据库的重要特征是从想法到答案的速度，而不是从查询到成果的速度。
更快的查询显然比更慢的查询更可取。但假如您挑选数据库，最好确保您是依据原始速度以外的要素做出决议的。
更多技能文章，请拜访：opensource.actionsky.com/
关于 SQLE
SQLE 是一款全方位的 SQL 质量办理渠道，覆盖开发至出产环境的 SQL 审核和办理。支撑干流的开源、商业、国产数据库，为开发和运维供给流程自动化才能，提高上线功率，提高数据质量。
