【发布时间】：2023-03-16 03:49:01
【问题描述】：
我想知道分片是否是部分复制的替代名称。我发现——
部分复制。 – 每个数据项仅在某些但不是所有节点上都有副本（“分片”？）
纯部分复制。 – 只有数据项子集的副本，但没有节点包含数据库的完整副本
混合部分复制。 – 一组节点是完整副本，另一组节点是部分副本
【问题讨论】：
标签： replication sharding database-replication distributed-system
【发布时间】：2023-03-16 03:49:01
【问题描述】：
部分复制是一种有趣的方式，您可以通过复制将数据从主服务器分发到从服务器，每个从服务器都包含一部分数据。最终你会得到一组较小的数据库，只读的，每个都包含一部分数据。读取可以很好地分布式和并行化。
但是写入呢？
那些仍然阻塞，在 1 个大胖懒惰的主数据库中，缓冲区管理、锁定、线程锁/信号量和恢复任务之类的任务 - 是 OLTP 的真正瓶颈，它们使写入无法扩展......请参阅更多内容请参见我的博文：http://database-scalability.blogspot.com/2012/08/scale-up-partitioning-scale-out.html。顺便说一句 - 你在这里的主题只是给了我另一个帖子的好主意。我会链接到这个问题并给你信用！ :)
分片是数据在数据库数组中只出现一次的地方。每个数据库都是数据的完整所有者，从那里读取数据，将数据写入那里。这样，读取和写入是分布式和并行化的。可以实现真正的横向扩展。
分片处理和维护都是一团糟，很难。 ScaleBase（我在那里工作），启用自动透明横向扩展，只需将它放在中间，你将在后面有 10 个 DB，它看起来就像你的应用程序中的 1。自动、透明的超级分片——在一个盒子里。
【讨论】：
-
嗨，Doron，感谢您的回复... 只是想根据最近几天阅读的内容再补充几句：分片是将数据库水平或垂直拆分为多个分区的机制可以分散到多个独立节点。我假设如果我们也复制单个分片，我们可以将其视为纯部分复制的示例。如今，许多 NoSQL 系统主要提供基于所选分片键的水平拆分，如果能够相应地设计应用程序逻辑，则旨在提供良好的读写可扩展性。
-
但是，我想管理分片的应用程序逻辑非常困难，因为事务类型和工作负载模式是预先知道的。然后我们必须省略分布式事务，这些事务可能会为单个操作访问不同的分片，并且如果使用异步复制会产生不一致的读取。看起来，在 1) 分片（带有复制 - 纯部分复制）和完全复制之间总是存在一些权衡； 2）异步和同步更新传播。值得一读danweinreb.org/blog/improving-the-pacelc-taxonomy
分片是一种对表进行水平分区的方法。它与复制无关。 传统上，RDBMS 服务器位于系统中心，具有星形拓扑。这就是为什么它变成：
单点故障
系统的性能瓶颈
要解决问题 #1，您可以使用复制：如果原始服务器死机，您将故障转移到副本。
要解决问题 #2，您可以：
-
使用分片
1.1 自己做分片
1.2 使用 RDBMS “开箱即用”的集群机制
迁移到 NoSQL 解决方案
分片允许您通过在多个服务器之间拆分数据来将数据库扩展到多个服务器。然而，分片是一种权衡。它限制了您的数据加入/相交/等。
如果您使用分片，您仍然会遇到问题 #1。所以复制分片节点是一个好习惯。
【讨论】：