对于一个正在建设的在线市场产品,我有一个需要实施数据库分片解决方案的情况。我是分片新手,在阅读了这个论坛的帖子后,我觉得使用业务实体的基于目录的分片策略将是合适的。但我仍然不清楚这种分片解决方案采用的非规范化和数据同步最佳实践。将有 3 个核心实体,供应商、客户和订单。我计划根据供应商 ID 对数据库进行分片,因为对订单数据的大部分处理将由供应商管理员执行。这将确保供应商的订单是从单个数据库实例中获取的,从而消除了跨数据库获取。然而,在这种情况下,当客户查看他们的订单信息时,数据将驻留在多个数据库实例中,并且需要多个数据库获取。当此类场景出现在分片解决方案中时,通常会做什么。
4 回答
我认为你有 99.9% 的机会不需要分片。
如果出现以下情况,您需要分片:
- 您的数据库插入/更新率接近或超过您可以经济高效地购买的最高规格服务器的容量并且
- 您已经将大部分读取查询、报告、备份等转移到只读复制的从属服务器上
- 您已完成功能分区以将任何非必要或无关的更新繁重工作负载移出主服务器
如果你不能对以上所有三个都说“是”,你就不需要分片。
读
http://www.mysqlperformanceblog.com/2009/08/06/why-you-dont-want-to-shard/
即使在您的数据库达到多个 TB 大小之前,数据库分片也可以非常有效。我们发现的主要原因是内存/CPU与磁盘的比例发生了显着变化,而MySQL等DBMS产品在将最近使用的索引和数据放入内存方面确实非常出色。
对于您的数据分片问题,此技术可能会有所帮助。
- 并行查询(我们称之为“Go Fish”查询)。有了这个想法,您可以同时从多个分片查询您的客户订单,并合并结果。如果做得对,这将非常有效。
对于变化不大的数据,我们通常建议对常见的查找表进行全局表复制,但这对于像客户订单这样的活动没有多大帮助。
在任何情况下,分片都可以以非常经济高效的方式实现,并且可以线性扩展写入,并且通常比基于上述的读取线性扩展更好。
您可能还想尝试 nosql 数据库,例如 mongodb 或 Cassandra
您还可以使用 memcache 来缓存数据以便快速访问
您还可以查看具有多个从属的主从复制。
对于关系型数据库,Apache ShardingSphere 可以帮助您透明地进行数据分片。
它可以使用开发人员定义的内置分片算法和自定义算法对数据进行分片。
只需CREATE SHARDING RULE TABLE t_order ...
添加分片规则即可,其他SQL与原数据库相同。
仅供参考:https ://shardingsphere.apache.org/document/current/en/features/sharding/