search 2013 adfgs

为了对核心技术拥有更多的自主控制能力,为了解决数据库的线性扩展问题,为了尽量减少对商业软件的依赖,为了摆脱对高端硬件的依赖,为了… 基于以上多种原因,2年前,我们计划将公司某核心应用平台进行大手术:数据库平台从软件到硬件全部重构。当然,这其中应用架构的改造也不可避免的进行了大换血。 这个项目无论是从技术角度还是是业务角度来说,都对我们有着非常大的价值,也必定会带来非常深远的影响。项目历时2年多,分4个阶段才完成: 应用接口统一 这一阶段主要是为了后面真正迁移的时候做准备工作,将该核心应用系统的所有数据访问入口统一到一起,全部以服务化的接口方式呈现给其他有需要的系统,一来方便后续变更的控制,二来也推进了服务化的进程。 Oracle数据库中拆分(1拆16) 这个阶段本不是必要的,但是由于项目启动稍微晚了点,数据出现了爆发性增长,导致该系统的数据表太大(单表不带索引过500GB),原 Oracle 数据库已经快撑不住了。为了安全起见,先在 Oracle 中从一个主表以会员ID进行 hash 运算后再进行水平拆分,从1个表分拆成了16个。附表由于访问量稍小,而且全部是根据主键访问,暂时保留原样。 当然,这样的水平拆分,必然会带来数据访问路由以及数据合并的问题。我们专门为此开发了具有分布式数据库路由/数据合并,数据库读写分离,数据库链接管理等功能的数据访问中间层,专门解决拆分后给应用服务器带来的影响,使得应用服务器完全感受不到后端数据库的变化。 这个数据访问中间层,对前端应用服务器来说,就是一个完整的数据库,所有数据请求都从这里实现,以协议的方式和前端应用服务器的jdbc驱动进行交互,以便让数据库对应用服务器彻底透明。 Oracle迁移至 MySQL(16拆128) 这个阶段是整个阶段中历时最长,复杂度最高,风险系数最高的,未知因素也最多的一个阶段。虽然 MySQL 数据库已经在互联网行业占据了大片江山,但是对于阿里巴巴来说,却仍然是一个新鲜玩意儿,因为之前我们一直都用 Oracle 来提供所有的业务系统的数据库服务。 在此之前,我们从来没有在如此核心业务系统的数据库上使用过 PC Server 和本地硬盘来承载数据库,一直是使用 IBM 小型机和中高端存储设备来解决高性能和高可靠的问题。在更换成 PC Server 和本地硬盘来承载数据库之后,我们就必须面对 PC Server 本身硬件可能存在的不可靠性所带来的 Crash,所以我们必须有一套完善的 HA 切换机制,要比小型机厂商所提供的商业 HA 管理软件更加高效更加自动化更加可控,才能我们降低了设备本身可靠性之后达到原有的可用性要求。 对于一个需要满足 365 * 24 * 7 的核心业务系统来说,肯定是不可能给我们太多时间来进行数据迁移的,所以我们不得不设计出一个对现有系统影响尽可能小的迁移方案,这势必会造成方案的高度复杂化,带来更多的风险。最后的迁移方案要经历如下4个阶段: 1. Oracle 读/写;;MySQL 初始化并增量写 2. Oracle 读/写; MySQL 写 […]

, , ,

受博文视点所邀,最近正开始编写一本关于MySQL性能优化与架构设计方面的技术书籍(书名暂时还未确定),考虑到MySQL数据库其入门简单的特点和基本的用户操作手册中英文版本都有的情况,这本书的内容将定位在MySQL中高级技术,适合于对MySQL已经有一个基本了解的读者,或者软件系统架构师,新技术选型决策者等,当然对专职/兼职的Database Administrator来说自然是更合适不过的了。 基于我个人自身的技术特长以及博文视点和各互联网公司相关技术人员以及博文的广大读者沟通调研结果,本书目前暂定大纲如下: 一、基础篇 1、 MySQL 基本介绍 1.1 MySQL Server简介 1.2 MySQL 与其他数据库简单比较 1.3 MySQL 主要适用场景 1.4 小结 2、 MySQL 架构组成 2.1 MySQL 物理文件组成 2.2 MySQL Server 系统架构 2.3 MySQL 自带工具使用介绍 2.4 第三方MySQL工具简介 2.5 小结 3、MySQL 存储引擎介绍 3.1 MyISAM 介绍 3.2 Innodb 介绍 3.3 NDB Cluster 介绍 3.4 其他存储引擎 3.5 小结二、维护篇 4、 MySQL 安全策略管理 4.1 […]

, , , , ,