分片的性能影响是什么？

Question

我是分片的新手，想知道分片对各种查询有什么影响。对于名为“people”的样本数据集：

person_id | person_fname | person_lname | person_dob
----------------------------------------------------
1         | John         | Smith        | 1972-03-04
2         | Sally        | Jones        | 1968-09-14
3         | Phil         | Forrester    | 1976-11-25
4         | Gwen         | Langley      | 1955-04-20
5         | Pedro        | Romero       | 1962-12-21
6         | Gene         | Halford      | 1978-01-11
7         | Juan         | Peza         | 1977-08-07
8         | Pierre       | Henry        | 1980-04-30

通过创建代理身份“id”的散列，数据在四个节点上平均分片。但是，您需要对可能跨越所有节点的记录执行读写操作，例如：

SELECT person_fname, 
       person_lname 
FROM   people 
WHERE  person_dob > '1970-01-01'

或者说您有另一个“订单”表，它在“person_id”列中引用“人员”，并且想要执行连接...

SELECT    order_id,
          order_amount,
          order_date,
          person_fname,
          person_lname
FROM      orders
LEFT JOIN people
WHERE     order_amount > 50

实际上所有节点都会并行运行查询吗？我假设每台服务器的每个步骤都要做更少的工作，而不是一个实例对八个记录运行查询，同时，四个实例将对两个（ish）记录运行查询，如果 DBMS能够执行分片选择，那么其他节点不需要继续执行任何进一步的指令，这个假设是否正确？

分片和复杂连接是否有任何已知的性能影响（除了这个简单的示例）？

Answer 1

它确实允许并行完成。

如果它们必须跨越不同的分片，它确实会使连接变得复杂，因此速度变慢。

但是，对于多对一，如果您有例如orders 以这样的方式分片：orders 表中的所有行与people 表中的相关行在同一分片中，则不会发生这种跨分片问题。

你需要设计你的分片方法，这样你就会得到很多这样的情况，而很少（理想情况下没有）你最终会跨越分片。

您还希望将分片放在您实际寻找最多的键上。例如。如果您通过用户名查找人作为其他一切的起点，那么您希望通过用户名而不是 id 进行分片，因为当您找到他们时，您已经知道要命中哪个单个分片，而不是仅仅为了从大多数取回零行。

Answer 2

是的，分片会导致性能发生重大变化。它从不允许应用程序保持不变。

最明智的分片方式是数据模型是否允许将数据分区为真正独立的。就像在租户根本不交互的多租户情况下一样。在这种情况下，连接永远不会跨越分区，一切都很好。

当使用跨分区交互进行分片时，这会变得非常非常讨厌。编写针对所有分片运行的查询的成本与分区数量呈线性关系。这意味着您可以通过添加节点获得零加速。

Answer 3

免责声明：我为 ScaleBase 工作，这是一个完整的横向扩展解决方案的制造商，如果你喜欢的话，它是一个“自动分片机”，看起来和感觉就像 1 MySQL，代理到“分片”网格，自动化命令路由并并行化跨数据库查询和合并结果 - 您不会看到与来自 1 个数据库的结果有什么不同。支持 ORDER、GROUP、LIMIT、agg 函数！根据命令和参数，路由和并行化在“控制器”内部完成。

从我们客户的经验来看，我们不仅通过并行查询获得了巨大的性能改进，而且还改进了维护，考虑创建索引、向表中添加列 - 这些也是并行化的并且运行速度更快。所有这些都没有或几乎没有对代码进行任何更改。

您的查询示例是“全数据库”执行的经典示例，如果分布式和并行化，它们肯定会运行得更快。索引更高效，使用 RAM 等等...

希望我能帮上忙。