扩展数据库会遭遇挑战, 本文提供了五种数据库分片 Sharding 策略供参考
当然, 除了分片策略以外, 最简单办法是扩展硬件, 另外是删除可能不需要的数据, 或尝试使用微服务解决
下面着重谈谈五种分片策略:
一根据客户或租户进行切片
SaaS 应用程序通常为许多客户 (称为租户) 服务, 这就是为什么我们经常将这些应用程序称为 多租户应用程序如果您是 SaaS 业务, 客户们的数据通常不会相互影响而社交网络应用则与此不同, 社交网络应用中不同用户生成的数据之间存在很多相互依存关系
使用多租户的 SaaS 应用程序, 数据通常应该是事务性的如果您丢失了一些数据, 付费客户会抗议投诉由于许多这些事务型多租户 SaaS 应用程序 (比如: CRM 软件, 营销操作, 网络分析) 的性质, 当数据保存到数据库时, 您需要强有力的保证数据能确实保存下来了客户希望您执行引用完整性
多租户应用程序另一个有趣的事情是, 他们的数据模型随着时间的推移而发展, 提供越来越多的功能不同于 C2C 是受益于网络效应而扩展规模, B2B 应用程序是通过为客户添加新的 (粘性) 功能而不断增长扩展新功能意味着新的数据模型最终的结果是从 10 个表到 100 个表, 有时是复杂的 join 如果这听起来和你一样, 按租户分割是一种安全 (推荐) 的分片方法
二按地理划分
近年来兴起一种基于地理位置的应用程序, 这些应用程序关键是地理位置: 感谢 iPhone 无论是 Lyft,Instacart 还是 Postmate, 这些应用程序都与位置有重要的联系
但是, 只是因为你有一个注重地理的应用程序, 这并不意味着地理是正确的分片 key 按区域划分的关键是您的特定地理位置中的数据不与另一个地理位置进行交互并不是所有具有地理数据的应用程序进行地理分片是有道理的
与上述多租户应用程序类似, 依赖于地理位置的应用程序的数据模型往往更加演变随着应用程序依赖于位置, 你有一些表之间存在外键依赖关系, 并经常在他们的查询之间相互联系如果您能够将查询限制在单个地理位置, 并且数据很少跨越地理边界, 则按地理划分可能是一个很好的方法
三按实体 ID 分片(随机分布数据)
这种模型切分方法可以适用于许多不同的数据库系统, 这种方法的前提条件是数据模型之间没有强大的相互依赖关系, 也就是没有 Join, 也没有因 Join 发生事务机制的需要, 在这样前提下, 如果你面临有一个单节点 (或核心节点) 的数据库中数据太多, 导致无法快速处理, 就可以使用本策略
当通过实体 id 分片时, 我们希望尽可能均匀地分布数据, 以最大限度地提高系统中的并行性为了能完全均匀分布, 需要通过随机 ID 进行分片, 采用类似负载平衡策略 round-robin 方式轮询数据
如果您的查询根本没有 Join, 那么使用一个 uuid 来分割数据可能会很有意义如果您有几个与会话相关的 join, 则可以使用相同的分片 key 来分割相关表(根据会话分片)
四根据 graph 分片
现在我们来看看最独特的方法在查看图 graph 数据模型时, w 为了分析方便, 会看到不同的扩展方法和不同的意见图模型在流行的 B2C 应用程序 (如 Facebook 和 Instagram) 中是最常见的, 这些应用程序会使用图数据库 graph database
使用图数据库, 有两个关键点, 对象代表有类型的节点, 而关联代表它们之间的连接比如张三订阅关注了李四, 对象就是李四经常发生的更新, 关联就是谁订阅了这些更新
使用此模型, 数据通常以几种不同的形式进行复制 (主从复制) 那么应用程序的责任是映射到最有用的能获取数据的数据表表这样就有多种以不同方式切分过的数据副本, 它们是最终实现数据的一致性, 然后必须将一些应用程序逻辑映射到分片策略, 对于像 Facebook 和 Reddit 这样的应用, 除了采取这种方法之外别无选择, 但它确实有一定的代价
五时间划分
分片的最终方法是顺应某些应用程序自然而然的倾向如果您正在处理时间为主轴的数据, 则按日, 周, 小时, 月份分区是正确的查看某种形式的事件数据时, 时间分割是非常常见的事件数据可能包括广告的点击次数 / 展示次数, 可能是网络事件数据, 或者来自系统监控的数据
下面情况您将需要使用基于时间的方法进行分区:
(1)通过对数据进行分析, 以时间为横轴, 生成报告 / 警报
(2)你会经常来回翻阅历史数据, 因此在时间上你需要保留一定历史数据
时间分区上有意义的一个例子是, 当您是仅输出 30 天广告数据时或者: 您正在监控网络日志, 但是仅需要查看最近 7 天如果一年前的时间里混合了最近的数据 (最近 7 天) 和历史数据时, 实现这些功能就会出现了困难
分片的正确方法取决于您的应用程序
与许多关于架构和基础设施的决策一样, 必须适时做出折衷, 最好方法是将分片策略与您的应用程序的需求 (以及您的客户的需求) 相匹配在分片的情况下, 将分片类型与您的应用程序是能够实现有效扩展的关键当您将数据模型和用例与正确类型的分片相匹配时, 许多重要的问题: 如重新投入重写应用程序如何确保数据一致性在 6 个月后更新时遇到问题等可能会自然消失
Five sharding data models and which is right
来源: http://www.jdon.com/49066