有没有网站专门做cnc招聘,华夏人寿保险公司官网,泉州网站建设哪家好,织梦cms sql注入破解网站后台管理员账号密码文章目录 0. 前言1. 垂直分库分表2. 水平分库分表 1. 理解过程及实现方案问题讨论衍生出分库分表策略借助成熟组件使用分库分表阶段完成后面临的问题1. 异地多活问题2. 数据迁移问题3. 分布式事务问题4. join查询的问题 分库分表的策略实现示例 2. 参考文档 0. 前言
假设有一个… 文章目录 0. 前言1. 垂直分库分表2. 水平分库分表 1. 理解过程及实现方案问题讨论衍生出分库分表策略借助成熟组件使用分库分表阶段完成后面临的问题1. 异地多活问题2. 数据迁移问题3. 分布式事务问题4. join查询的问题 分库分表的策略实现示例 2. 参考文档 0. 前言
假设有一个电商网站随着用户量和订单量的增加单一数据库难以承载如此庞大的数据量查询速度也逐渐降低这时就需要进行分库分表。
1. 垂直分库分表
电商网站有用户模块和订单模块可以将用户表和订单表拆分到不同的数据库中。例如原本在同一个数据库中的用户表包含用户基础信息和用户扩展信息和订单表可以拆分为两个数据库一个数据库存储用户的基础信息另一个数据库存储用户的扩展信息和订单信息。
最常见的博客文章都是以电商系统作为案例因为他是最具备代表性电商网站的用户模块和订单模块是可以拆分到不同的数据库中的。这种拆分方式可以提高系统的可扩展性和性能。
假设有一个电商网站它有一个数据库其中包含两个表用户表User和订单表Order。用户表包含用户的基础信息如用户名、密码等和用户的扩展信息如用户的购物偏好、历史订单等。订单表包含订单的详细信息如订单号、购买的商品、数量、价格等。
原始结构可能如下
Database: EcommerceDBTable: User- UserID- Username- Password- Preferences- HistoryOrdersTable: Order- OrderID- UserID- Product- Quantity- Price可以将这个数据库拆分为两个数据库一个数据库UserDB存储用户的基础信息另一个数据库OrderDB存储用户的扩展信息和订单信息。
拆分后的结构可能如下
Database: UserDBTable: UserBasic- UserID- Username- PasswordDatabase: OrderDBTable: UserExtension- UserID- Preferences- HistoryOrdersTable: Order- OrderID- UserID- Product- Quantity- Price这样当用户的基础信息和订单信息需要进行大量的读写操作时这两个操作可以在不同的数据库上并行进行从而提高系统的性能。同时由于用户的基础信息和订单信息被存储在不同的数据库中因此如果其中一个数据库出现问题也不会影响到另一个数据库的正常运行从而提高了系统的可用性。
2. 水平分库分表
假设订单表中有上百万条数据查询和写入速度逐渐下降。此时可以根据订单ID进行水平分表比如订单ID为奇数的存入订单表1订单ID为偶数的存入订单表2。这样原本一个表需要处理的数据量就减半了可以提高查询和写入速度。
在进行分库分表后对于程序查询也需要做相应的调整。例如在进行水平分表后查询某个订单信息时需要先判断订单ID是奇数还是偶数然后再决定查询哪个表。
Database: OrderDBTable: Order- OrderID- UserID- Product- Quantity- PriceDatabase: OrderDBTable: Order0- OrderID- UserID- Product- Quantity- PriceTable: Order1- OrderID- UserID- Product- Quantity- Price在这种情况下Order0用于存储ID为偶数的订单Order1用于存储ID为奇数的订单。
查询和写入的伪代码可能如下所示
def get_order(order_id):if order_id % 2 0:# Query Order0 tablereturn query_order_0(order_id)else:# Query Order1 tablereturn query_order_1(order_id)这样我们可以根据订单ID的奇偶性来决定查询或写入哪个表从而将原本一个表需要处理的数据量减半提高查询和写入速度。
实际的分库分表会更复杂。同时分库分表也可能会带来一些问题如数据一致性问题、跨库事务问题等。因此在设计分库分表方案时需要进行充分的考虑并可能需要引入其他的技术如分布式事务来解决这些问题。 那么让一起深入了解一下数据库知识应用实践之分库分表。 1. 理解过程及实现方案
记住一句话不是所有系统一上来就搞分库分表包括淘宝京东。尤其这种超前设计对小公司来说就是累赘甚至隐患。不仅人才成本资源成本运维成本。甚至学习成本都不容小觑。所以基本上都是不断衍生到分库分表才算是中小公司正确的技术路线和最优实践。
我们以一个场景例如有一个电子商务网站随着业务的发展用户数量、商品数量和交易数量都在快速增长。原来单一的数据库已经无法满足需求查询速度慢系统负载高甚至出现宕机情况。这样的情况下为了提高系统的性能和稳定性就需要进行数据库的分库分表。
问题讨论
分库分表的目的是为了解决单个数据库无法承受大量数据和高并发的问题。但是分库分表也会带来一些问题例如数据一致性问题、分布式事务问题、跨库跨表查询问题、数据迁移问题等。
衍生出分库分表策略 垂直分库分表按业务模块进行分库将大表按照字段进行分表例如用户库、商品库等。 水平分库分表将数据按一定的规则分散到不同的数据库或表中例如按用户ID的hash值分库按订单时间分表等。
借助成熟组件使用
常见框架
MyCat一个开源的分库分表中间件支持自定义分片规则可以实现读写分离、事务和SQL的完全透明。Sharding-JDBC一款轻量级的Java框架提供了强大的分库分表、读写分离、分布式事务和分布式序列等功能。Shardingsphere包含了Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar这三款独立的产品可以满足不同场景下的数据分片需求。 分库分表的复杂问题
分库分表阶段完成后面临的问题
当技术演进到我们已经解决了分库分表基本问题解决了并发问题解决性能问题接下来我们基本上面临如下几个问题。关于这些问题又需要我们继续去学习和研究尝试更多方案。此处我们不做展开。
1. 异地多活问题
在数据库地理分布、灾备等问题上如果是多库多表的情况数据同步和备份的复杂度将会增加。
2. 数据迁移问题
.在分库分表后如何对旧数据进行迁移以及如何在迁移过程中保证业务的正常运行是个大问题。
3. 分布式事务问题
在传统的单体数据库中事务是保证数据一致性的重要手段。但在分库分表的环境下原有的事务机制不能再使用需要引入新的分布式事务解决方案。
4. join查询的问题
在分库分表后原本在一个库或一个表中可以做的join查询就变得困难需要通过应用层去做关联和组合。
分库分表的策略实现示例
函数法哈希、取模等根据某个字段比如用户ID的函数结果进行分库分表。范围法枚举、区间比如根据日期范围订单ID范围等进行分库分表。一致性哈希在新增或减少数据库节点的时候能够最小化数据的迁移。
我们用Java写一些伪代码方便大家理解。 假设我们有多种根据某个值如用户ID或订单ID来确定应将数据存储在哪个数据库的方式。我们分别用函数法范围法和一致性哈希法三种方法模拟一下。
函数法我们可以将用户ID除以数据库数量的余数作为数据库的索引。
public String getDatabase(int userId) {int dbCount 2; // 假设我们有2个数据库int dbIndex userId % dbCount;return db dbIndex;
}范围法我们可以使用订单ID作为范围进行划分比如订单ID小于10000的存储在一个数据库大于等于10000的存储在另一个数据库。
public String getDatabase(int orderId) {if (orderId 10000) {return db0;} else {return db1;}
}一致性哈希这种方法需要使用到特殊的数据结构例如TreeMap。首先我们将每个数据库称为节点添加到一个TreeMap中然后计算键如用户ID的哈希值并在TreeMap中找到该哈希值对应的数据库。如果没有找到则返回哈希值最接近的数据库。
public class ConsistentHashing {private TreeMapInteger, String nodes new TreeMap();public void addNode(String nodeName) {int hash nodeName.hashCode();nodes.put(hash, nodeName);}public void removeNode(String nodeName) {int hash nodeName.hashCode();nodes.remove(hash);}public String getDatabase(String key) {if (nodes.isEmpty()) {return null;}int hash key.hashCode();if (!nodes.containsKey(hash)) {SortedMapInteger, String tailMap nodes.tailMap(hash);hash tailMap.isEmpty() ? nodes.firstKey() : tailMap.firstKey();}return nodes.get(hash);}
}其实真实场景中我们大多都使用分库分表组件或者中间件最著名的和大家最常用的sharding-jdbc就是解决这类场景的一个优秀的轻量级的分库分表组件虽然有很多bug或者不足但是足以解决我们90%的问题了。后面有一个章节我会写一个详细教程关于sharding-jdbc使用详解。除了它还有一些国产的中间件也不错。如下
TDDL阿里巴巴开源的分库分表中间件支持复杂的分库分表策略。Oceanus网易云数据库的分库分表解决方案支持自动分库分表、读写分离、分布式事务等功能。
2. 参考文档 “MySQL分库分表方案” - InfoQ。介绍了 MySQL 的分库分表方案并对实施这种方案的步骤进行了详细的讨论。链接https://www.infoq.cn/article/solution-of-mysql-sub-database-and-sub-table “MySQL 分库分表实践” - 阿里云社区的一篇文章也可以参考学习。介绍了 MySQL 分库分表的实践和经验。链接https://developer.aliyun.com/article/776687 “分库分表架构设计” 详细介绍了分库分表架构的设计和实施。链接https://www.jianshu.com/p/d7f3d3808f25 ShardingSphere 是 Apache 的一个开源项目包包含了我上面说的sharding-jdbc提供了分库分表的解决方案。链接https://shardingsphere.apache.org/document/current/cn/overview/
