 |
在专场1(数据库架构设计)上，第一位技术大咖是来自云和恩墨CTO杨廷琨，他分享了《从传统银行到互联网金融--Oracle数据库架构设计实践》，主要是随着互联网+的深入影响，传统行业的业务模式发生了深刻变革，在高并发整合模式下，数据库需要从架构到体系的优化，而互联网金融的很多核心系统，也坚定的运行在Oracle数据库之上，在这个主题中，和大家分享从传统银行到互联网金融的架构规划实践案例。
 |
金融行业数据库要求，数据安全——事务性，包括了源子性，一致性、持久性、隔离性。系统可用——高可用，包括了双机、集群、容灾。客户感知——高性能，主要表现在硬件包括CPU、内存、IO;架构包括集群、读写分离、双活，建模包括物理、逻辑;开发包括访问、SQL。容量增长——扩展性，对于客户不断增多，企业就必须考虑可拓展性，数据库的扩展性，包括了SCALE UP、SCALE OUT、SHANGDING。
金融行业对于数据库的稳定性、安全性都是最高的行业，因此在数据库架构设计上，要明确业务增长预期并转换为数据库指标，深入分析发现当前系统瓶颈，综合考虑可用性、性能和扩展性，根据业务预期和瓶颈进行容量预测。
在专场1(数据库架构设计)上，第二位技术大咖是来自武汉达梦数据库有限公司副总经理付铨，他分享了《达梦数据库技术新特性及国产化推进实践》，主要DM数据库近年来深度参与了政务、公安、大型央企等行业领域的自主可控信息化建设，并得到了较广泛的应用。针对建设过程中出现的问题，DM开发了诸如共享存储集群、读写分离集群、ORACLE兼容等一系列特性以满足用户需求。本主题向大家分享达梦在国产化推进过程中取得的技术成果和典型案例。
 |
随着大数据概念与应用在各行各业的迅速铺开，大数据+正引领着行业变革。在与达梦数据库的付铨老师对话过程中，他谈到最近关注的技术…
分布式关系数据库体系架构。在大数据环境下必须面对如何低成本地实现大数据存储和计算能力，包括分析的效率、高并发的处理能力。目前来看，分布式的数据库架构是有效降低资源投入成本的同时，又能保证数据处理能力的最优选择。现在也涌现了大量采用分布式架构的关系库和NoSQL产品，我们非常关注这些产品技术，并致力于在商用化的产品中提供成熟、优秀的解决方案。
各种NoSQL数据库体系结构及计算框架。作为从关系数据库做起的厂商，我们现在对各类NoSQL DB的体系架构，及其所选用或可适配的计算框架十分关注。关系数据库的优势在于高度的成熟性、受众广泛的SQL语言和开发接口、良好的生态、向开发人员提供的一致性保证等，我们希望在保持上述面向用户和开发人员的良好体验的前提下，今后能够融入更多的NoSQL DB的特性，如更多的数据类型支持，更好的横向扩展能力，更广泛的计算模型支持，使得这些特性能够以灵活、可选、可配置的方式，为不同的用户提供更好的产品支持。
多种不同数据模型的融合管理。大数据的最终形态应该是趋向统一，无论是关系数据，还是图数据，键值数据，最后都会实现融合统一的管理和访问。因此相关的技术和路线是我们所关注的。
 |
在专场1(数据库架构设计)上，第三位技术大咖是来自杭州沃趣高级技术专家杭州沃趣高级技术专家魏兴华，他分享了《云是未来：12C RAC 私有云架构》，主要介绍了ORACLE RAC的架构演变，讲解了12C RAC出现的新技术，以及12C RAC下的私有云解决方案：SERVERPOOL+RAC+INMEMORY，能够给企业带来的业务价值。
 |
魏兴华表示，Oracle能挑起云这个大旗的产品只有RAC，8i版本:动态锁管理出现，内存融合技术以及初具雏形，写写操作需要通过磁盘作为媒介。9i版本:Cache Fusion出现，多实例的内存通过高速私有网络连接在一起。GRD被引入。没有自己的集群件。10G版本：出现自己的集群件，CRS。ASM作为一个可选的存储解决方案。11G版本：ASM整合进了GI，OCR和VOTING也可以存储在ASM里。GI ,IAAS平台。灵活伸缩的问题。
ServerPool的分配规则，按照ServerPool的Importance顺序，依次填充每个ServerPool，填充至Min个服务器。如果还有剩余机器，则进入到下一步。再按照ServerPool的Importace顺序，依次填充每个ServerPool，填充至Max个服务器，如果还有剩余的机器，则进入到下一步。再剩下来的机器进入到Free Pool中。
ServerPool -云时代的 QoS保证，资源随时随地可用，根据DBPool的预定义策略，在主机发生故障后自动完成集群重构，优先把资源分配给重要度高的DBPool;根据业务需要，可以灵活修改DBPool的策略，满足不同业务不同时间段的业务需要;实例与主机不再绑定，实例可以跑在任何主机上。
 |
在专场1(数据库架构设计)上，第四位技术大咖是来自北京新媒传信科技有限公司架构师 黄湘龙，他分享了《飞信数据库访问组件的演进历程》，主要介绍了飞信，在线用户数曾经长期排名全国第二的IM软件，经历了从10万在线用户到400万在线用户的成几何倍数上升的过程，在这个过程中，飞信系统架构不断演进以适应不断增长的业务压力。飞信的数据库访问组件这块也经历了多个版本演进，最终稳定地支持了7亿多注册用户，三个机房的规模。我有幸参与了飞信后端架构演进的整个历程，对于扑面而来的一个一个坑，我们兵来将挡，水来土掩，用最合适的架构设计，动态扩容系统，解决了业务压力带来的系统压力。飞信的数据库访问的形式经历了三个大的阶段，第一阶段是组件形式，简单高效，后来的服务形式，收敛了数据库连接，对数据库进行了保护封装，最终演进到数据库代理形式，解耦了数据库服务和其他服务。
 |
逻辑POOL与物理POOL的优点，能有序地扩张用户;数据迁移的时候，不需要修改用户数据;只需要修改物理;Pool与逻辑Pool的映射即可。能够把逻辑和存储很好地融合起来，比如用来做分省控制用户，减少省间用户跨物理库调用。
第一阶段：通过组件直接读写数据，用户越来越多，物理POOL越来越多;服务越来越多，服务的镜像越来越多，连接数越来越多，数据库不可承受;服务越来越多，都能直接访问数据库将导致权限，引起的安全问题。
第二阶段：通过IBS服务读写数据，服务越来越多，IBS服务几乎和所有服务强耦合。第三阶段：通过组件+DAL服务读写数据，DAL一旦出现问题，所有业务受影响，DAL间接增加了服务间的耦合。第四阶段：SOA服务分层治理。
 |
在专场1(数据库架构设计)上，第五位技术大咖是来自魅族首席DBA左兴宇，他分享了《魅族互联网发展路程之数据库篇》，主要介绍魅族年出货量从400万到2000万，用户数300万增长到4500万的过程中，数据库作为关键存储技术所遇到的问题，以及我们的如何解决这些问题的。内容包括环境标准化，两地三中心，数据库服务高可用，读扩展，数据一致性保证，数据库IO瓶颈解决，数据库分表分库方案，超大数据量的日常运维，缓存技术对关系数据库的补充，应对数据灾难的经验等。
 |
第一阶段[2013]—艰难起跑，单机房，主要痛点来自SQL质量无保证、疲于应付开发人员需求、数据库单点、数据容量无关联单表过亿、磁盘IO瓶颈、重度依赖MySQL。第二阶段[2014]—痛点整改，出现新问题，LVS上DB和业务共用同一套LVS，业务请求大影响DB转发，Slave已经在复制中踢出，但是没有在LVS中剔除，导致LVS拿到错误的数据，为此将LVS拆分，DB独立，规范上线下线流程，同时MHA上主和备主必须同一个网段。要替换一台机器发现IP不够用了，VIP已经漂移到备主，但是数据还没追完全，管理节点和数据节点网络抖动，MHA全切了，为此，IP段规划，每个C段预留50个IP;不用Keepalived做IP漂移，用脚本实现，在追数据流程完成后再做IP漂移;加大监测时长到10秒，从多个节点ping master多点校验。第三阶段[2015]—标准化进程，第四阶段[2016]—自动化+成本控制。
 |
在专场1(数据库架构设计)上，第六位技术大咖是来自58到家技术委员会主席 沈剑，他分享了《数据库一致性架构设计实践》，主要介绍数据库架构设计时会有什么一致性问题;“并发写”一致性问题实践;“伪分布式事务”一致性问题实践;“数据冗余”一致性问题实践;“数据迁移”一致性问题实践;“主从库”一致性问题实践;“数据库与缓存”一致性问题实践;
 |
“并发写”一致性实践： CAS。对于“数据冗余”一致性实践，可以通过(1)扫全库修复法;(2)扫增量修复法;(3)实时修复法。“主从库”一致性实践，可以通过(1)半同步复制;(2)读主库;(3)中间件。“数据库与缓存”一致性实践：双淘汰，通过(1)写阻塞二次淘汰;(2)异步timer二次淘汰;(3)异步esb二次淘汰;(4) binlog异步二次淘汰。
 |
标签：数据库
分享到：
0 个人觉得赞好文章 点个赞您已经赞过了+1
【免责声明】本文仅代表作者个人观点，与中国数码招商网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。您若对该稿件内容有任何疑问或质疑，请联系本网将迅速给您回应并做处理。