数据架构规划方案.docx

数据架构规划方案.docx

《数据架构规划方案.docx》由会员分享，可在线阅读，更多相关《数据架构规划方案.docx（13页珍藏版）》请在冰豆网上搜索。

数据架构规划方案

数据架构规划

一．当前架构

  结合研发二部数据量最大校讯通产品来描述，其她产品在性能上浮现瓶颈，可以向校讯通靠拢。

数据库整体架构：

当前校讯通产品依照顾客量多少以及数据库服务资源繁忙限度，横向采用了历史库+当前库分库架构或者单一当前库架构，其中历史库只作为web平台读数据库，纵向结合了applicationsmemcache+SybaseASE12.5老式永久磁盘化数据库架构。

数据模型架构：

原则上采用了一事一地数据模型（3NF范式），为了性能考虑，某些大数据量表恰当引用了数据冗余，依照业务再结合采用了当前表+历史表数据模型。

如下就用图表来进行当前数据架构阐明：

横向分库数据库架构图：

纵向applayer+memcachelayler+diskdblayer图：

其中web层指是客户端浏览器层，逻辑上：

app层指是应用服务层，mc层指是memcache客户端层，ms层指是memcache服务层，db层指是当前永久磁盘化数据库层，固然在物理机器上也许app层跟mc层，ms层是重叠布置在相似服务器上。

数据模型架构图：

  其中以上数据模型中除了少数几张表外其她均有历史表存在，固然有诸多表是没在这个模型图中，这某些是核心数据模型。

这某些模型对象中也涉及了某些冗余性设计，例如顾客中有真实姓名，特别是不在这个模型内，由模型核心表产生某些记录报表，为了查询性能冗余了合理某些学校名称，地区名称等方面设计。

二．劣势现象

1.流水表性能瓶颈

  当前架构性能瓶颈集中在流水表访问上，最大流水表记录量达到了超5亿级别，这是由于当前外网在用sybase数据库系统版本，没有采用较好关于分区技术。

曾经有过把流水表进行物理水平分割，把不同月份数据分割放在不同物理表上模型改造设想，碍于产生应用程序修改工作量大，老旧数据迁移麻烦，再加上进行了从单库架构改造到分库架构后，数据库性能瓶颈就不是特别突出。

因此模型改造这某些工作没展开。

无论是单库或是分库模式，浮现平台访问数据库性能瓶颈依然集中在大流水表上，在访问高峰高并发量状况下，短信流水表进程堵塞，数据库服务I/O,CPU资源耗费达到顶点，在服务器硬件环境不是特别抱负状况下，浮现了一定概率导致顾客访问缓慢甚至觉得页面无法响应现象，导致了顾客体念不良影响。

2.运营维护难点

  1）历史数据清理运维工作

  为了存储充分运用，为了性能提高，需要定期进行不再使用历史数据清理，

由于清理数据量庞大，老式数据清理办法主线不也许保证一种晚上有效清理完毕，保证平台第二天正常运营。

虽然当前已经实行了比较高效且可行数据清理方法，但是每次实行都需要晚上到彻夜进行解决，使得数据清理运维工作特别劳累，影响到运维人员第二天正常出勤，间接就有也许影响到数据库正常运维监控，导致数据库问题浮现。

  2）防止索引失效而进行记录量更新运维工作

  由于流水表数据变动量大，容易导致流水表索引失效，从而需要定期进行索引甚至整表记录量更新工作，记录量更新时间跟流水表数据总量成正比关系，所以导致记录量更新速度比较慢，不能保证在筹划时间内，记录量更新完全成功，并且当前外网安装sybase12.5版本是最低一种EBF版本，存在较多BUG,在索引记录量更新过程中也许导致数据库浮现病态，进而影响第二天数据库正常运营。

3.运维监控纰漏（此某些非架构因素引起）

  当前数据库监控以及运维维护还存在某些纰漏，浮现了多次数据库设备空间使用完毕，没有及时添加数据库设备空间导致数据库挂起问题，也多次浮现了数据库日志空间占满导致数据库挂起问题。

此类问题还是比较明显，尚有一类问题，不是整库挂起，而是某些业务表访问异常，运维也许监控不到，等顾客访问到了这某些业务功能不正常，由顾客反馈到运维这边。

4.运营记录报表在当前数据模型架构下重用性较低

  由于顾客需求渐进性，导致数据库记录报表在数据模型设计时没有站在至高点，随着顾客需求不断积累，数据库记录报表对象也跟着不断积累，发现当前存在比较大一某些记录报表数据在不同数据库对象之间重复记录，没有充分发挥记录数据重用性。

5.没运用集群技术

  当前数据库架构还没采用成熟集群技术，集群技术并不单单指单一数据库系统集群，可以混合集群，例如内存数据库跟老式永久磁盘化数据库系统集群。

6.分库架构还可完善

  当前分库架构还可以继续完善，引用成熟数据库主从分离，读写分离技术。

7.内存数据库技术还没充分运用

  当前数据库架构虽然在前端使用了memcache技术，但是还可以继续完善使用内存数据库技术再结合异步写技术，使得架构相得益彰。

8.适合海量数据高并发读写，高效率存储非关系型数据库没充分运用

  当前数据库架构还没采用正在兴起NoSql，NewSql技术（当前某些外围系统采用了mongodb来做实验品，而这某些系统数据量并不大，非关系型数据库海量数据高并发访问高效性优势没有体现出来，从而也没掌握真正使用经验），固然这种数据库也有缺陷，就是数据库事务一致性，数据库写实时性和读实时性，复杂SQL查询，特别是多表关联查询是无法满足。

三．改进思路

   在第二某些劣势现象中，总结了当前数据库架构以及数据模型架构缺陷，缺陷还比较多，从此外一种角度也反映了公司产品数据库架构改进和提高空间还比较大，将来随着不断迭代改进，可以承受业务量提高空间也相应比较大。

下面就依照劣势现象进行针对性阐述改进思路：

1.流水表性能瓶颈改进

  Sybase12.5没有较好解决大数据量表性能问题，但是通过数据库转到Oracle后，充分运用Oracle分区表，分区索引特性来提高流水表访问性能，逻辑上表依然是一张完整表，只是将表中数据在物理上存储到各种表空间（物理文献上，这样查询数据时，不至于每次都扫描整张表。

由于逻辑上仍旧一表，使得应用程序不需要修改，也避免了这个劣势点描述带来额外许多开发工作量问题，但是效果几乎等同水平分割数据模型。

2.大流水表运维难改进

  1）历史数据清理运维工作

  在Oracel数库系统中，针对对大流水表每月数据进行分区，这样运维人员在清理历史月份数据时候，只要通过TRUNCATEPARTITION、 DROPPARTITIONOracle自身分区维护命令轻松迅速清理掉分区数据（既指定月份流水数据）

  2）防止索引失效而进行记录量更新运维工作

  同样Oracle也有等同于sybase记录量更新工作，在Oracle中通过对大流水表分区工作后，进行记录量更新工作同样就快捷简易，可以通过ANALYZEPARTITION记录量分析维护命令可以轻松迅速对指定分区记录量进行更新。

3.运维监控纰漏改进

  重要分两个方面：

a）数据库剩余空间方面监控；b）数据库出错日记监控。

这两个监控虽然通过人为积极性查看数据库有关信息可以监控到，但是总归还是会有疏忽漏掉时候，只是出问题几率高低之分。

因此这里再加一道监控，就是通过数据库服务器端监控程序积极发回有问题或者告警信息给运维人员。

这道监控程序可以通过shell程序以及数据库程序，结合数据库日记以及剩余空间信息以短信或者邮件方式发回给运维人员。

在数据库剩余空间方面甚至可以通过数据库自身阀值设立，做到自动截取日记，自动添加设备。

4.运营记录报表数据模型改进

  由于原先某些报表模型存在着数据记录重复性，在晚上定期task中既占用了任务列表总时间，也对其她并行task运营导致了一定资源争用，影响了数据库性能。

因此在这里提出了一种类似蒲公英性质模型，数据通过发散模式，即插即用到不同运营记录报表中，势必须要改进当前接近一事一地3范式模型，把原先数据模型拆散，从纵向和横向都接近最小粒度需求数据模型。

使得记录数据可以重复使用，不同记录报表通过这些原子性记录数据再组合成报表所需要数据，固然这里需要一种平衡，并不完全等同蒲公英模型记录粒度越细越好，由于越细也代表着原始记录数据量越大，一会影响原始记录性能，二会影响组合成报表性能，三会占用更多存储空间。

这个平衡度需要掌控好。

5.运用集群技术

  固然通过了前面4点改进之后，数据库性能会比当前架构提高一定性能，至于集群技术就可以作为前面4点改进后补充和扩展，如果在改进后，依然还存在较大性能瓶颈状况下可以采用OracleRAC技术。

甚至采用基于内存数据库分布式数据库架构混合集群技术。

例如在Oracle数据库及Web服务之间加一层 Ameoba 分布式数据库代理结合内存数据库架构，

6.分库架构完善改进

  当前数据库架构采用了分库方式，但是主库（当前库）读写却是没有分离，纵观淘宝数据库架构演进历程，确是在某个历程碑点做到了较好读写分离，应用到DB数据写入与查询从双向通行变成了单向通行，通行效率更高，大大避免了互相影响。

“借道行驶”状况不再浮现。

淘宝那个碑点做到了如下几点：

1）写库为集中式oracle环境,提供数据安全性保障。

2）读库使用mysql，采用数据分片，分库分表，每台mysql放少量数据,单个数据分片内部采用mysql复制机制。

3）读库超大memory容量，起到了较好cache作用，在内存中数据查询性能远远高于在硬盘上性能

4）oracle到多台mysql按规则复制

结合淘宝架构思考，校讯通大流水也可以做到垂直分割到不同服务器，也可以做到水品分割到不同服务器，通过不同服务器访问不同流水表或者是不同范畴数据流水表，那提高性能是必定。

但是也要平衡考虑到应用程序开发简便性。

7.内存数据库技术运用

  常用内存数据库产品涉及商业版和免费版两类。

商业版如：

Altibase，Timesten，BerkleyDB等。

她们在电信，金融，证券等高性能计算应用中运用较为广泛。

商业版功能强大，然而，价格比较昂贵，不适合当前“便宜PC+免费软件”架构搭建思想。

开源领域产品重要有H2，HsqlDB，Derby，BerkeleyDB 等。

在混合集群架构中，内存数据库将承担OLTP职责，因而除了读写性能外，功能完备，事务等都需要作为优先评估因素。

盛传H2是一种开源高性能内存数据库，可以通过整合 Ameoba 与 H2，夹在applications和老式db层之间来达到内存数据库层架构布置。

Ameoba 是分布式数据库代理，它与 MySQL 整合已经在阿里巴巴核心业务中成功运用。

如果仅将数据库节点看作一种存储，MySQLNode 和 H2Node 并无本质区别。

JDBC驱动，DB切分，路由，皆由Ameoba 统一负责。

8.非关系型数据库使用

  外围非核心数据，但是数据量又是比较大业务系统数据库可以采用非关系型数据库，这是由非关系型数据库某些基本特性决定。

非关系型数据库有满足如下需求长处特性：

1）Highperformance-对数据库高并发读写需求 

2）HugeStorage-对海量数据高效率存储和访问需求

3）HighScalability&&HighAvailability-对数据库高可扩展性和高可用性需求

但同步随着不能满足如下需求缺陷：

1）数据库事务一致性需求 

2）数据库写实时性和读实时性需求

3）对复杂SQL查询，特别是多表关联查询需求

正是由于以上优缺陷也决定了，核心需要保持一致性数据，需要复杂关联数据，需要实时访问数据不要采用关系型数据库，如果通过ETL把关系型数据库流水数据冗余基本信息，构成可以直接查询业务信息数据，导入到非关系型数据库后，那对海量流水数据查询速度提高空间是很大。

其中代表型非关系型数据有Redis，TokyoCabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable，Riak，Tin，Flare，Lightcloud，KiokuDB，Scalaris，Kai，ThruDB等等非常之多。

四．架构筹划

  通过以上当前架构劣势以及改进思路总结，改进架构筹划就比较清晰了，如下还是通过横向整体数据库架构，纵向整体数据库架构，以及数据模型架构改进来做为新架构筹划。

风险最小，改动工作量最小架构就是改进思路中以第4点和第5点之间为分割线。

这条分割线前数据架构基本不需要变动，重要变动就是数据模型架构中流水表对象，以及数据库服务器后台添加监控以及智能解决运维程序工具。

重要改进数据模型流水表对象如下图：

同样进行分区尚有其她某些大流水表，这里不一一详述，这些流水表从sybase进入oracle分区表，在数据库转型升级过程中完毕。

尚有一点就是关于数据库监控工具在架构中布置，如下图所示：

以上架构改进筹划可以在一期中先完毕。

看运营效果状态，第5点之后改进筹划几乎就是架构重构了，因此涉及工作量更大，如果在第1，2，3，4点改进后数据库运营稳定，后续改进，可以通过实验和应用结合逐渐实行起来，作为应付更大型业务应用技术储备。

  下面结合5，6，7，8点改进思路做个架构规划，也就是分布式内存与老式数据库结合混合集群架构模式，再加上外围产品非关系型数据库，如下图所示（服务器和db合为同个节点阐明，否则图片篇幅占用过大）：

  上面架构图中，application（应用服务层），datacache层，diskdblayer层已经实现，但是diskdbLayer层多数据库集群技术还没不能说正式实现，虽然分库技术有类似集群嫌疑，asyncwrite（异步写）听开发人员也已经涉及使用。

那么此新架构图针对原架构改进就是MemoryDBLayer层以及类似Ameoba （可以使用其她代理）分布式数据库代理还没实现。

MemoryDBLayer集群加上每个逻辑分区有两个内存库是为了其中一种内存数据库一旦崩溃，同一逻辑分区中替补节点及时顶替工作，做到健壮容错和Failover机制。

这个架构明显比校讯通当前在使用架构要复杂诸多，稳定性以及性能提高均有待实际验证，虽然单单从架构上来讲融合了当前诸多技术长处（集群，内存数据库等）。