1、数据表 collect ( id, title ,info ,vtype) 就这4个字段,其中 title 用定长,info 用text, id 是逐渐,vtype是tinyint,vtype是索引。这是一个基本的新闻系统的简单模型。现在往里面填充数据,填充10万篇新闻。
2、最后collect 为 10万条记录,数据库表占用硬盘1.6G。OK ,看下面这条sql语句:select id,title from collect limit 1000,10很快;基本上0.01秒就OK,再看下面的select id,title from collect limit 90000,10从9万条开始分页。
3、8-9秒完成。
4、看下面一条语句:select id from collect order by id limit 90000,10很快,0.04秒就OK。因为用了id主键做索引当然快。
可以直接使用 rpm -qal |grep mysql查看mysql所有安装包的文件存储位置。
首先我们需要查看软件是否已经安装,或者说查看安装的软件包名称。如查找是否安装mysql接着根据 rpm -ql 列出软件包安装的文件。
综合上述以上的问题,可以直接使用 rpm -qal |grep mysql 查看mysql所有安装包的文件存储位置Yum查找除了rpm 查询还可以通过yum search 查找对应可以安装的软件包。
优势功能:
支持百亿边+快速导入,支持横向扩容。HugeGraph针对百亿级数据场景进行定制化优化,实现大数据环境下的快速导入和高效查询,同时能够对接Hadoop和Spark GraphX等已有大数据平台。
支持Gremlin图查询语言,Gremlin提供了标准、灵活、丰富的图查询语法。
支持多后端存储引擎,后端存储引擎可配置,可插件式扩展新的后端存储引擎。
支持快速的批量导入、批量导出功能,同时用户可灵活定义导入导出格式,支持CSV、TXT、JSON等格式,支持从HDFS、MySQL、SQL Server、Oracle、PostgreSQL等数据源直接导入数据。
mysql分库分表一般有如下场景
其中1,2相对较容易实现,本文重点讲讲水平拆表和水平拆库,以及基于mybatis插件方式实现水平拆分方案落地。
在 《聊一聊扩展字段设计》 一文中有讲解到基于KV水平存储扩展字段方案,这就是非常典型的可以水平分表的场景。主表和kv表是一对N关系,随着主表数据量增长,KV表最大N倍线性增长。
这里我们以分KV表水平拆分为场景
对于kv扩展字段查询,只会根据id + key 或者 id 为条件的方式查询,所以这里我们可以按照id 分片即可
分512张表(实际场景具体分多少表还得根据字段增加的频次而定)
分表后表名为kv_000 ~ kv_511
id % 512 = 1 .... 分到 kv_001,
id % 512 = 2 .... 分到 kv_002
依次类推!
水平分表相对比较容易,后面会讲到基于mybatis插件实现方案
场景:以下我们基于博客文章表分库场景来分析
目标:
表结构如下(节选部分字段):
按照user_id sharding
假如分1024个库,按照user_id % 1024 hash
user_id % 1024 = 1 分到db_001库
user_id % 1024 = 2 分到db_002库
依次类推
目前是2个节点,假如后期达到瓶颈,我们可以增加至4个节点
最多可以增加只1024个节点,性能线性增长
对于水平分表/分库后,非shardingKey查询首先得考虑到
基于mybatis分库分表,一般常用的一种是基于spring AOP方式, 另外一种基于mybatis插件。其实两种方式思路差不多。
为了比较直观解决这个问题,我分别在Executor 和StatementHandler阶段2个拦截器
实现动态数据源获取接口
测试结果如下
由此可知,我们需要在Executor阶段 切换数据源
对于分库:
原始sql:
目标sql:
其中定义了三个注解
@useMaster 是否强制读主
@shardingBy 分片标识
@DB 定义逻辑表名 库名以及分片策略
1)编写entity
Insert
select
以上顺利实现mysql分库,同样的道理实现同时分库分表也很容易实现。
此插件具体实现方案已开源: https://github.com/bytearch/mybatis-sharding
目录如下:
mysql分库分表,首先得找到瓶颈在哪里(IO or CPU),是分库还是分表,分多少?不能为了分库分表而拆分。
原则上是尽量先垂直拆分 后 水平拆分。
以上基于mybatis插件分库分表是一种实现思路,还有很多不完善的地方,
例如:
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)