精华内容
下载资源
问答
  • 传统单体应用典型的架构是几点个应用程序服务器, 连接后台的 Oracle 或 MySQL 服务器, 彼此之间也可以使用数据库来共享数据. 随着业务的增长, 后台数据库会变得越来越庞大, 不得已进行分表分库, 不同的租户或应用...

    传统单体应用典型的架构是几点个应用程序服务器, 连接后台的 Oracle 或 MySQL 服务器, 彼此之间也可以使用数据库来共享数据. 随着业务的增长, 后台数据库会变得越来越庞大, 不得已进行分表分库, 不同的租户或应用使用不同的数据库和表. 由于数据共享的要求, 经常还要做一些数据复制.

    比如一些公司都会有一个集中式的系统配置数据库 Config DB, 为了在各个集群中可以就近快速访问, 需要将它复制到各个不同地域中的集群中. 然而不同的微服务可能采用不同的数据库, 这就包括 MySQL 与 Oracle 之间, PostgreSQL 与Oracle 之间, Oracle 数据库之间的数据同步,

    随着业务量不断增长, 数据量从几何级向指数级地增长, 数据库容量频频告急, 几次数据库的单点故障也搞得大家焦头烂额. Oracle 确实很强大和稳定, 但你不能保证你的网络和硬件永远保持健康, 加上 Oracle 的昂贵成本, 越来越多的公司乘着微服务大潮的风起云涌, 将自己的后台存储切换到 NOSQL 上, 只保留一些帐目相关的数据还放在 Oracle 之类的数据库中.

    数据库产品很多, 商业开源的都不少, NOSQL 类产品都更多了, 让人目不睱接, 如何选择呢? 我们需要仔细分析我们的业务需求, 需要什么样的可靠性, 一致性和可用性

    理论回顾

    回顾一下经典的理论, 再结合实际看看我们需要什么样的后台数据存储产品

    CAP

    CAP 是指

    Consistency 一致性, 在分布式系统的各个节点中的数据副本, 在同一时刻具有相同的, 最新的值

    Availability 可用性, 即使是发生故障的时候也能在有限时间内完成任务并及时响应

    Partition Tolerance 分区容忍性, 即使网络被分割成几块, 消息互不连通, 系统仍然可以继续工作

    CAP 原理证明了在任何分布式系统只能同时满足以上三点中的两点, 无法同时兼顾, 在分布式系统中网络总是存在故障可能性, 所能分区容忍性必需满足的

    例如我做套考勤系统, 用户是家小公司, 我就可以不考虑分区容忍性, 在公司门口放套基于关系数据库的考勤系统, 后台使用双机冗余备份,主从数据库,定时冷备, 一致性和高可用性都能保证, 打卡或指纹系统即使断电也还有签字考勤的备份手段

    但是如果是跨国公司, 这套系统就必须容忍网络分区, 在一致性上做出妥协, 从强一致性降级为最终一致性, 也就是说在网络问题解决之后同步考勤数据

    金融业务中有些需要强一致性的系统, 会使用强大的IOE -- IBM 小型机, Oracle 数据库, EMC磁盘阵列, 并且在跨地区结算时容忍网络分区, 不过你会经常在银行碰到网络系统不可用的情况, 原因在于这些系统在高可用性方面做出了妥协

    微服务系统基本都是分布式系统, 分区容忍性当仁不让, 高可用性多数情况下也是要满足的, 所以能做文章的也就是在高可用性与一致性之间做加减法了

    酸碱平衡

    酸 ACID

    Atomicity 原子性

    Consitency 一致性

    Isolation 隔离性

    Durability 持久性

    这四点是传统关系数据库的基本特性, 数据库的每个事务都是原子的, 或者成功或者失败, 事务之间互相隔离,并保证了数据的强一致性. 正因为如此, 关系型数据库才长盛不衰, 生命力如此之强.

    不过这几年在大数据, 分布式系统盛行的大潮中, 数据库在海量数据, 海量并发请求之下也有点力不从心了.

    碱 BASE

    Basic Available 基本可用

    Soft state: 软状态, 对比硬状态, 比喻状态没有那么坚实快速地实现同步

    Eventually consistence 最终一致性, 在一定的时间范围内数据最终达成一致

    这是现在多数分布式系统所采用的模式, 系统的节点之间可能会短时间出现不一致的情况, 不过不要紧, 一会儿就会达到最终的一致

    比如微信, 它满足了高可用性和分区容忍性, 在一致性方面做了妥协, 你和朋友之间的消息可能会暂时不同步, 不过没关系, 过一会儿就好了, 你也能接受.`

    数据存储系统选型

    数据库常见的就有 Oracle, MySQL, PostgreSQL, SQLServer, 等等

    NOSQL 产品就更多了, Cassandra, Redis, HBase, MangoDB, 等等

    类别典型产品用途

    基于键值对Redis, Riak, MemcacheDB, etc.用于缓存, 分布式状态, 指标, 任务和会话存储

    基于列簇Cassandra, HBase, etc.用于海量的非结构化数据存储, 易于扩展

    基于文档MongoDB, Couchbase, etc用于一些深层嵌套, 结构复杂的数据存储

    基于图OrientDB, Neo4J, etc用来存储具有复杂关系的数据, 易于对数据建模和分类

    如何为你的系统选择一款便宜可靠, 满足业务需求的数据存储系统呢

    答案就是各取所需, 分析你的需求, 再对照各个数据存储系统的特点, 寻找与你的需求最匹配的

    1. 业务需求

    你的业务特点决定了你在 CAP 中取哪两个特性为重, 是用 ACID 也是 BASE 模式

    比如我是一个金融交易系统, 那我们选 Oracle + SharePlex (数据库复制工具), 做 Pre-Sharding 预先分区

    如果我是一个游戏平台, 我就选 MySQL 和 Cassandra, 游戏分为多个大区, MySQL 用来记帐, Cassandra 作游戏数据存储

    成本也是不能不考虑的因素, 商业数据库虽然稳定可靠, 不菲的价格也让人咋舌, 财大气粗的银行,保险公司不太在乎, 小公司可用不起. 现在越来越多的公司开始去 IOE 化, 转向便宜好用的开源产品, 付出的代价是雇用高水平的工程师来做好二次开发的运维, 满足日益增长的业务需求

    2. 质量需求

    让我们来看看 "Top Ten" 的非功能性的质量需求

    #特性具体要求

    1高可用性 Availability是否在99.99%的时间内始终可用?

    2可扩展性 Extensibility是否可以灵活适应数据结构和需求的变化?

    3可伸缩性 Scalability是否可以优雅从容地应对用量的增加?

    4安全性 Security是否可以抵御未经授权的使用或行为,同时仍可为合法用户提供服务?

    5健壮性 Robustness是否在发生软硬件错误或不正确地操作的时候依然能工作如常?

    6可度量性 measurability是否易于度量系统的健康状态和各项运行指标?

    7可测试性 Testability是否易于让开发和运维人员跟踪, 检测和诊断系统的行为?

    8可移植性 Portability是否可以移植到不同的操作系统和软硬件环境中?

    9可维护性 Maintainability是否易于更改,归档,维护系统?

    10易用性 Usability用户是否可以容易并有效地使用,学习或控制系统?

    3. 性能需求

    响应时间是一次请求从发送请求到收到响应的总时间,直观的反映系统的快慢。

    吞吐量是单位时间处理的请求数,通常用TPS来表示,是系统容量的直观体现。

    TPS(Transaction Per Second)每秒系统能够处理的交易或事务的数量,它是衡量系统处理能力的重要指标

    并发数是系统同时能处理的请求数,对于同时在线用户数高的,短时间有大量用户使用的,譬如抢购类网站要求高,如果要让用户在短时间内都能访问到系统,需要有极高的并发能力支持

    错误率

    错误率指系统在负载情况下,失败交易的概率。错误率=(失败交易数/交易总数)*100%。稳定性较好的系统,其错误率应该由超时引起,即为超时率。

    不同系统对错误率的要求不同,差的要求两个9, 高的要求999 即99.9%

    数据存储系统选型

    不同的数据库和NOSQL 系统具有不同的特点和属性, 例如以下几种

    数据存储系统处理速度单机吞吐量可扩展性一致性结构灵活性

    Oracle高+高+低强低

    MySQL高-高-低强低

    Redis高有限中强-高

    Cassandra高-(写好读差)大高强-- (最终一致性)高

    HBase高--有限高强-高

    最后, 介绍下我自己总结的在选择开源框架和中间件系统的 4L 原则

    Lots of people use it - 有许多人在使用它

    Lots of learning materials - 有许多学习资料

    Lots of successful case - 有许多成功案例

    License is free - 有免费的许可证

    基于以上功能, 质量和性能的需求, 结合不同数据库和 NOSQL 系统的特点, 遵照 4L 原则, 我想对于微服务的数据库与 NOSQL 选型并不难, 总有一款适合你.

    c8d0b304df1b475f4d70a4b08fd5f8a4.png

    展开全文
  • 2001年7月,联想建成亚洲最大的服务器应用方案中心,全面推动IA服务器的企业级应用,纵深与Intel、Oracle等国际厂商的全面合作,并不断拓展与优秀行业解决方案供应商的合作,为中国客户提供经严格选型、优化的软硬件...
  • 传统单体应用典型的架构是几点个应用程序服务器, 连接后台的 Oracle 或 MySQL 服务器, 彼此之间也可以使用数据库来共享数据. 随着业务的增长, 后台数据库会变得越来越庞大, 不得已进行分表分库, 不同的租户或应用...
        

    传统单体应用典型的架构是几点个应用程序服务器, 连接后台的 Oracle 或 MySQL 服务器, 彼此之间也可以使用数据库来共享数据. 随着业务的增长, 后台数据库会变得越来越庞大, 不得已进行分表分库, 不同的租户或应用使用不同的数据库和表. 由于数据共享的要求, 经常还要做一些数据复制.

    比如一些公司都会有一个集中式的系统配置数据库 Config DB, 为了在各个集群中可以就近快速访问, 需要将它复制到各个不同地域中的集群中. 然而不同的微服务可能采用不同的数据库, 这就包括 MySQL 与 Oracle 之间, PostgreSQL 与Oracle 之间, Oracle 数据库之间的数据同步,

    随着业务量不断增长, 数据量从几何级向指数级地增长, 数据库容量频频告急, 几次数据库的单点故障也搞得大家焦头烂额. Oracle 确实很强大和稳定, 但你不能保证你的网络和硬件永远保持健康, 加上 Oracle 的昂贵成本, 越来越多的公司乘着微服务大潮的风起云涌, 将自己的后台存储切换到 NOSQL 上, 只保留一些帐目相关的数据还放在 Oracle 之类的数据库中.

    数据库产品很多, 商业开源的都不少, NOSQL 类产品都更多了, 让人目不睱接, 如何选择呢? 我们需要仔细分析我们的业务需求, 需要什么样的可靠性, 一致性和可用性

    理论回顾

    回顾一下经典的理论, 再结合实际看看我们需要什么样的后台数据存储产品

    CAP

    CAP 是指

    • Consistency 一致性, 在分布式系统的各个节点中的数据副本, 在同一时刻具有相同的, 最新的值
    • Availability 可用性, 即使是发生故障的时候也能在有限时间内完成任务并及时响应
    • Partition Tolerance 分区容忍性, 即使网络被分割成几块, 消息互不连通, 系统仍然可以继续工作

    CAP 原理证明了在任何分布式系统只能同时满足以上三点中的两点, 无法同时兼顾, 在分布式系统中网络总是存在故障可能性, 所能分区容忍性必需满足的

    例如我做套考勤系统, 用户是家小公司, 我就可以不考虑分区容忍性, 在公司门口放套基于关系数据库的考勤系统, 后台使用双机冗余备份,主从数据库,定时冷备, 一致性和高可用性都能保证, 打卡或指纹系统即使断电也还有签字考勤的备份手段

    但是如果是跨国公司, 这套系统就必须容忍网络分区, 在一致性上做出妥协, 从强一致性降级为最终一致性, 也就是说在网络问题解决之后同步考勤数据

    金融业务中有些需要强一致性的系统, 会使用强大的IOE -- IBM 小型机, Oracle 数据库, EMC磁盘阵列, 并且在跨地区结算时容忍网络分区, 不过你会经常在银行碰到网络系统不可用的情况, 原因在于这些系统在高可用性方面做出了妥协

    微服务系统基本都是分布式系统, 分区容忍性当仁不让, 高可用性多数情况下也是要满足的, 所以能做文章的也就是在高可用性与一致性之间做加减法了

    酸碱平衡

    酸 ACID

    • Atomicity 原子性
    • Consitency 一致性
    • Isolation 隔离性
    • Durability 持久性

    这四点是传统关系数据库的基本特性, 数据库的每个事务都是原子的, 或者成功或者失败, 事务之间互相隔离,并保证了数据的强一致性. 正因为如此, 关系型数据库才长盛不衰, 生命力如此之强.

    不过这几年在大数据, 分布式系统盛行的大潮中, 数据库在海量数据, 海量并发请求之下也有点力不从心了.

    碱 BASE

    • Basic Available 基本可用
    • Soft state: 软状态, 对比硬状态, 比喻状态没有那么坚实快速地实现同步
    • Eventually consistence 最终一致性, 在一定的时间范围内数据最终达成一致

    这是现在多数分布式系统所采用的模式, 系统的节点之间可能会短时间出现不一致的情况, 不过不要紧, 一会儿就会达到最终的一致
    比如微信, 它满足了高可用性和分区容忍性, 在一致性方面做了妥协, 你和朋友之间的消息可能会暂时不同步, 不过没关系, 过一会儿就好了, 你也能接受.`

    数据存储系统选型

    数据库常见的就有 Oracle, MySQL, PostgreSQL, SQLServer, 等等
    NOSQL 产品就更多了, Cassandra, Redis, HBase, MangoDB, 等等

    类别 典型产品 用途
    基于键值对 Redis, Riak, MemcacheDB, etc. 用于缓存, 分布式状态, 指标, 任务和会话存储
    基于列簇 Cassandra, HBase, etc. 用于海量的非结构化数据存储, 易于扩展
    基于文档 MongoDB, Couchbase, etc 用于一些深层嵌套, 结构复杂的数据存储
    基于图 OrientDB, Neo4J, etc 用来存储具有复杂关系的数据, 易于对数据建模和分类

    如何为你的系统选择一款便宜可靠, 满足业务需求的数据存储系统呢

    答案就是各取所需, 分析你的需求, 再对照各个数据存储系统的特点, 寻找与你的需求最匹配的

    1. 业务需求

    你的业务特点决定了你在 CAP 中取哪两个特性为重, 是用 ACID 也是 BASE 模式
    比如我是一个金融交易系统, 那我们选 Oracle + SharePlex (数据库复制工具), 做 Pre-Sharding 预先分区
    如果我是一个游戏平台, 我就选 MySQL 和 Cassandra, 游戏分为多个大区, MySQL 用来记帐, Cassandra 作游戏数据存储

    成本也是不能不考虑的因素, 商业数据库虽然稳定可靠, 不菲的价格也让人咋舌, 财大气粗的银行,保险公司不太在乎, 小公司可用不起. 现在越来越多的公司开始去 IOE 化, 转向便宜好用的开源产品, 付出的代价是雇用高水平的工程师来做好二次开发的运维, 满足日益增长的业务需求

    2. 质量需求

    让我们来看看 "Top Ten" 的非功能性的质量需求

    # 特性 具体要求
    1 高可用性 Availability 是否在99.99%的时间内始终可用?
    2 可扩展性 Extensibility 是否可以灵活适应数据结构和需求的变化?
    3 可伸缩性 Scalability 是否可以优雅从容地应对用量的增加?
    4 安全性 Security 是否可以抵御未经授权的使用或行为,同时仍可为合法用户提供服务?
    5 健壮性 Robustness 是否在发生软硬件错误或不正确地操作的时候依然能工作如常?
    6 可度量性 measurability 是否易于度量系统的健康状态和各项运行指标?
    7 可测试性 Testability 是否易于让开发和运维人员跟踪, 检测和诊断系统的行为?
    8 可移植性 Portability 是否可以移植到不同的操作系统和软硬件环境中?
    9 可维护性 Maintainability 是否易于更改,归档,维护系统?
    10 易用性 Usability 用户是否可以容易并有效地使用,学习或控制系统?

    3. 性能需求

    • 响应时间是一次请求从发送请求到收到响应的总时间,直观的反映系统的快慢。

    • 吞吐量是单位时间处理的请求数,通常用TPS来表示,是系统容量的直观体现。

      • TPS(Transaction Per Second)每秒系统能够处理的交易或事务的数量,它是衡量系统处理能力的重要指标
    • 并发数是系统同时能处理的请求数,对于同时在线用户数高的,短时间有大量用户使用的,譬如抢购类网站要求高,如果要让用户在短时间内都能访问到系统,需要有极高的并发能力支持

    • 错误率
      错误率指系统在负载情况下,失败交易的概率。错误率=(失败交易数/交易总数)*100%。稳定性较好的系统,其错误率应该由超时引起,即为超时率。

    不同系统对错误率的要求不同,差的要求两个9, 高的要求999 即99.9%

    数据存储系统选型

    不同的数据库和NOSQL 系统具有不同的特点和属性, 例如以下几种

    数据存储系统 处理速度 单机吞吐量 可扩展性 一致性 结构灵活性
    Oracle 高+ 高+
    MySQL 高- 高-
    Redis 有限 强-
    Cassandra 高-(写好读差) 强-- (最终一致性)
    HBase 高-- 有限 强-

    最后, 介绍下我自己总结的在选择开源框架和中间件系统的 4L 原则

    1. Lots of people use it - 有许多人在使用它
    2. Lots of learning materials - 有许多学习资料
    3. Lots of successful case - 有许多成功案例
    4. License is free - 有免费的许可证

    基于以上功能, 质量和性能的需求, 结合不同数据库和 NOSQL 系统的特点, 遵照 4L 原则, 我想对于微服务的数据库与 NOSQL 选型并不难, 总有一款适合你.

    参考资料

    展开全文
  • 我们曾经总结一般的数据库服务器在选型时的主要需求(详见:数据库服务器选型原则及实例解说),并探讨了如何选择Oralce数据库服务器(详见:x86渐热 Oracle数据库服务器选型指南)。本期我们将从MySQL数据库对服务器的...

    我们曾经总结一般的数据库服务器在选型时的主要需求(详见:数据库服务器选型原则及实例解说),并探讨了如何选择Oralce数据库服务器(详见:x86渐热 Oracle数据库服务器选型指南)。本期我们将从MySQL数据库对服务器的具体需求出发,分析其对服务器硬件的具体需求以及市面上的解决方案。

    MySQL是一个快速、多线程、多用户的SQL数据库服务器,其出现虽然只有短短的数年时间,但凭借着“开放源代码”的东风,它从众多的数据库中脱颖而出,成为众多DBA的首选。业内开发人员圈子里也把LAMP体系(Linux+Apache+MySQL+PHP/Perl)作为最标准的应用程序开发平台。下面我们来看看MySQL数据库的三个主要特点,以及其对服务器的具体需求。

    16789e48168d62f87ec2a16aa08c4e79.png

    1、 MySQL数据库的三大特性及需求方向

    1998年第一代MySQL关系型数据库诞生之初,就已经在数据库核心层面提供给了对多线程计算机之的完全支持,并且提供了面向C、C++、 Eiffel、Java、Perl、PHP、Python以及Tcl等编程语言的编程接口(APIs),支持多种字段类型并且提供了完整的操作符支持查询中的SELECT和WHERE操作。

    正是基于以上原因,在很多DBA的心目中,只要通过升级服务器CPU和内存,扩容数据库集群就可以提高MySQL数据库性能。而因为MySQL的核心程序采用的是轻量级进程(LWP,也就是说大部分资源和其他进程共用,是一种实现多任务并行的方法),所以其对系统逻辑地址空间和资源的客观理性要求就非常高(这一点后文会解释)。

    由于MySQL提供了多种编程接口,因而在前端应用平台上具有其他数据库无法比拟的优势。与x86服务器日渐风靡相对照,基于C语言、C++语言、甚至是JAVA语言的数据库调用也日益流行。而MySQL被广大DBA用户青睐的一个重要原因就是其开放式架构在x86平台上的优势——例如ODBC for Windows使得MySQL支持所有的ODBC 2.5函数,从而让微软Access直接链接MySQL数据库,其应用得到极大的扩展。

    此外,由于MySQL拥有一个非常快速而且稳定的内存管理系统,因此在大内存环境中性能表现优秀,在不少应用案例中,有DBA甚至直接将扩容内存作为提高系统可靠性和稳定性的手段——事实上,MySql的稳定性足以应付一个超大规模的数据库(后文我们也会有所介绍)。

    综上所述,MySQL数据库三大特性分别是:核心程序支持多核心、多线程的并行计算;x86平台的多应用环境;快速稳定的内存管理系统。相应的,DBA在选择MySQL数据库服务器的时候需要考虑服务器内CPU的并行计算性能(或是多路集群的计算性能),复杂x86环境的支持性(为虚拟化数据库做考虑)和强大的内存拓展性。

    cac7a5d51f2f54c3e6f9924249aa3204.gif

    2、 为MySQL量身打造最合适数据库服务器

    从前文的分析来看,MySQL数据库在性能需求层面主要对处理器提出了要求:并行计算性能强(或多路集群计算性能强),x86平台全兼容,优秀的系统稳定性及内存拓展。随着3月31日英特尔至强7500处理器发布,x86平台的计算性能和可靠性被推至了巅峰,MySQL数据库也迎来了为自己量身打造的处理器。

    至强7500拥有8核16线程,集成了内存控制器,并拥有4条QPI直连总线,使其每个处理器最多支持16条四通道DDR3 1333Mhz内存,这使得一个四路服务器最高支持256GB内存(4G*16条*4路),达到了x86平台有史以来的巅峰——与上一代至强7400处理器(6核6线程)相比,数据库性能提升了2.5倍。此外,基于至强7500的服务器在拓展至8路的情况下不需要第三方节点控制器的支持,并且最高可以扩展到256路服务器系统(需要第三方支持)——充分满足DBA对大规模数据库集群的计算需求。

    071706517d8b7c5ffe2248cc94838a56.png

    这主要得益于至强7500所拥有的4条QPI总线,以及Nehalem-EX架构强大的多路互联技术。此外,对于前文所提的“MySQL轻量级线程”对系统共享资源的依赖,这里要简单介绍一下其工作原理:在数据库计算中,会出现几个计算线程共用一个数据的情况。因此MySQL将这几个计算分割在多个线程中进行,却并不分割所调用的数据,让他们统一访问这一个数据,以达到“最小化存取”的目的,进而将“有限的计算资源”尽可能多的利用到计算中,而不是数据读写中。这种设计的本意是好的,但是早期的x86平台受制于内存控制器在北桥,以及处理器自身缓存不够大(处理器常用的数据通常先存在缓存里,之后才访问内存),因此这种共享数据的访问反而会造成延迟——每个线程都去读一次内存获得要计算的数据,几乎等同于计算线程携带着相同数据所消耗的负载(牵扯较深,请自行理解)。

    总结为一句话,以往DBA们一直都存有质疑,认为MySQL的轻量级线程由于共享数据,实现了较高的并行效率(但只体现在算法层面),因为x86平台存取数据——尤其是访问内存时的低效,使得MySQL的优势很难体现。至强7500凭借多达24MB的三级缓存以及集成在处理器内部的内存控制器,将MySQL数据库频繁调用“相同”系统资源的操作大大降低,可以说充分发挥出了MySQL数据库高效的并行性能。

    对于内存扩展性方面,至强7500历史性的将每颗处理器仅支持8条内存槽拓展到支持16条内存。这给了用户极大的灵活性——有的用户数据库规模大,运算量却并不大,因而仅需要内存多,而并不需要插满四个处理器。Dell前两天新推出的采用至强7500系列处理器的服务器中,创造性的采用Flex Memory Bridge技术,使得一个四路服务器在仅插两个处理器的情况下,每个处理器可以使用另外没插处理器的8条DIMM内存插槽(每个处理器标配了8个DIMM内存插槽),也就是两个处理器可以用全服务器内的32条内存插槽(请自行理解)。

    另一方面,英特尔在至强7500中加入了22条RAS特性,并首次在至强平台上实现了IA64上才有的MCA恢复功能,提供更强的可靠性。因而无论是在性能、可扩展性和可靠性上,都已经逼近RISC,甚至在某些指标上有所超越。而至强7500的x86生态环境更加开放,与MySQL相应的Linux、Unix、Windows环境融合更紧密,成本方面也更加低廉。

    基于以上分析,可以看出至强7500无论是在计算性能上、内存扩展性方面、可靠性方面以及丰富的应用环境充分发挥了MySQL数据库的三大特色。毋庸置疑,至强7500将x86平台带到了一个新的高度,而DBA们也得益于x86平台与MySQL数据库开放式的 “强强联手”,可以将企业MySQL数据库的应用推向新的高度。

    展开全文
  • 通达海在数据库服务器选型中认为,Sun公司已与880多个独立软件公司建立了战略同盟,使Sun公司服务器平台拥有业界最多的一万三千个应用软件。Sun公司通过与这些厂商的紧密合作,使这些软件在Solaris多处理环境下性能...
  • 作为DBA,有时会被挑战类似这样的问题: 如果现有业务规模增加10倍、100倍,数据库是否能够支撑? 下个月我们搞大促,数据库这边没问题吧?...服务器采购选型,到底哪款服务器更适合我们呢? 面对诸...

    作为DBA,有时会被挑战类似这样的问题:

    • 如果现有业务规模增加10倍、100倍,数据库是否能够支撑?
    • 下个月我们搞大促,数据库这边没问题吧?
    • 计划进行去O工作,代码逻辑不变,数据库从Oracle切换到MySQL,MySQL能支撑业务吗?
    • 服务器采购选型,到底哪款服务器更适合我们呢?

    面对诸如上面的这些质疑,DBA应该如何面对?

    身为DBA该如何评估现有资源使用情况?

    如果现有数据库资源确实无法支撑,又该本着什么原则进行改造呢?

    本文是针对上面问题的一些经验总结,供大家参考。

    一、评估工作

    面对这样的问题,首先要进行评估工作,可遵循下面的步骤:

    1、建立性能基线

    针对系统运行现状,建立性能基线。将业务指标与性能指标建立起对应关系。这里所说的性能指标包括CPU、MEM、DISK、NET等。在诸多资源中,肯定存在不均衡的情况,短板的资源最有可能成为业务增长后的瓶颈。在具体操作上,可首先确定一个业务高峰时间段,通过监控平台或监控工具收集系统各资源的使用情况。然后依据收集的信息,分析可能的性能短板在哪里。

    对于DBA来说,对自己掌管系统的性能使用情况要了然于胸。通过对业务的了解,将业务指标映射到性能指标上,就可以很容易地推断出现有系统可承载的最大业务量。此外,对于可能影响承载业务增长的短板,也会有比较清晰的认识。

    一般来说,数据库类的应用是重资源消耗类的应用。对CPU、MEM、DISK、NET等,均有较大的消耗。但由于不同硬件发展水平不均衡,各数据库资源消耗特点也不同,因此需要具体问题具体分析。

    下面谈谈我对硬件发展及与数据库关系的一点个人观点:

    • CPU

    相对于其他硬件而言,CPU技术发展较快。随着CPU主频提高及多核CPU技术的发展,CPU提供的计算能力往往不会成为系统的性能瓶颈。但我们需要注意的是,有些数据库是无法完全利用CPU的能力(例如MySQL就是这样)。此时,为了充分利用CPU的资源,可以考虑诸如"多实例混跑"的方案,提高CPU利用率。

    • MEM

    随着内存技术的发挥,内存的价格越来越便宜。现在我们在生产环境中,可以见到128、256GB,甚至TB级的内存也不罕见。一般来说,数据库通常会利用内存作为缓冲区,大内存的配置对数据库的性能有着比较明显的提升。此外,数据库自身技术也在适应着大内存的场景,通常采用的策略是划分子池。将管理的单位进一步细分,例如Oracle中的Sub Pool、MySQL中的多instance buffer pool。

    • NET

    随着GigE、10GbE、InfiniBand技术的飞速发展,低延迟、高带宽的服务品质给数据库乃至整个IT系统带来了很多变化。常见的应用领域有:

    • 加速分布式数据库,例如Oracle RAC。

    • 加速大数据处理,例如提升Hadoop MapReduce处理。

    • 存储架构的变革,从Scale-Up向Scale-Out演变。

    • 容灾方案,主备策略…

    • DISK

    相对于其他硬件技术发展而言,传统的机械式磁盘是相对而言发展最慢的,其往往也是最容易成为数据库的性能瓶颈。随着闪存技术的横空出世,为存储技术带来的一种变革。下面我们来看看主要性能指标的对比:

    从上述指标来看,使用闪存技术后,存储能力大大提高,消除了系统最大的瓶颈。这也是为什么很多DBA都在不同场合,大力推荐使用闪存,其对于数据库性能的提升会带来质的飞跃。但与此同时,我们也应该注意到,传统关系型数据库是按照磁盘IO模型设计的,没有考虑到闪存技术,现在属于软件落后于硬件的阶段;相对而言,闪存技术对于非关系型模型更有优势。

    很多基于传统设计的优化理论发生了变化,例如: 索引聚簇因子的问题。这一点是需要我们在考虑数据库优化时,主要注意的。此外,NoSQL的性能优势因为传统数据库结合闪存技术,而变得不明显。需要在架构选择时加以分析。

    2、建立业务压力模型

    根据业务特征,建立业务压力模型。简单理解就是将业务模拟抽象出来,便于后面进行压力放大测试。要做到这一步,需要对业务有着充分的了解和评估。

    下面通过一个小例子说明一下:

    这个表格模拟了某个类电商的业务,其包含的主要模块及模块中的主要操作。针对不同的操作其交易复杂度不同 (交易复杂度可理解为执行SQL语句的个数)。根据不同的读写情况,区分是数据读还是数据写。在估算了业务总量(交易量)的情况下,很容易推算出数据操作的量。通过这种方式将业务压力模型转化为数据压力模型。此处的难点在于对业务逻辑的抽象能力及对模块业务量的比例评估。

    有了上述概览的表格后,针对每一种业务操作,可细化其操作。最终将其抽象成SQL语句及对应的访问特征。其伪代码可描述为

    可依据上述伪代码,编制压力测试代码。通过一些工具调用测试代码,产生模拟测试的压力。例如我经常使用的oradbtest/mydbtest(原阿里楼方鑫的一个测试工具)或sysbench等,都是不错的压力测试工具。

    建议企业根据自身情况,整理出自己的业务压力模型。这在系统改造、升级、扩容评估、新硬件选型等多种场合都很有用处。它要比厂商提供的类似TPCC测试报告,更有意义。据我了解,很多规模较大的公司都有比较成熟的压力模型。

    3、模拟压力测试

    要想考察现有数据库能否承载增长后的业务压力,最好的方式就是模拟压力测试。观察在近似真实的压力下,数据库的表现。重点观察,数据库的承载力变化、主要性能瓶颈等。通常可以有两种方式,一种是从真实环境导流(并可根据需要放大流量,可利用类似TCPCOPY等工具);一种是根据前面整理的业务压力模型,通过压力工具模拟压力。前者适用于已有项目的扩容评估、系统改造评估等,后者适用于新上项目原型方案评估、性能基准测试等场景。

    上述模拟压力测试结果中,暴露出的性能瓶颈点,就是我们后面需要着重改进、优化的方向。

    二、优化层次及步骤

    针对上面的评估结果,来确定后面的改进、优化方案。可遵循如下一些步骤:

    1、分析瓶颈点

    根据上面的评测结果,分析性能瓶颈点。针对不同瓶颈点,可采取不同的一些策略。有时候性能测试时全流程的,对于一个复杂系统来说,要明确定位到性能瓶颈点比较困难。此时,可借助一些APM工具,量化整个访问路径,协助找到瓶颈。也可以类似上面的做法,做好抽象工作,只对数据库端施加压力,观察数据库行为,判读数据库是否为瓶颈。如判断就是数据库的承载能力不够,可按照不同层次进行考虑。

    在整个评估数据库承载能力中,这一步骤是最复杂的、也是最难的一部分。要区分清楚是否是数据库承载能力不足,还是其他组件的问题。即使明确是数据库的问题,也要分清楚是整体or局部的问题;是单一业务功能慢,还是整体都比较慢;是偶尔会慢,还是一直都很慢等等。这些问题的界定有助于后面明确问题层次,采取不同的策略进行解决。

    针对数据库承载能力不足,我将常见出现问题进行了层次划分,可简单分为语句级、对象级、数据库级、数据库架构级、应用架构级、业务架构级。不同层次采取的方式也有所不同,下面分别描述一下。

    2、层次-语句级

    如性能核心问题,只是某条SQL语句的问题,可有针对性地进行优化。这种方式是侵入性比较小的一种优化方式,其影响范围也比较小。下面对比常见的语句级优化方法。说明一下,下面方法已经排除了诸如统计信息不准确等其他因素,仅从SQL语句本身优化方式考虑。

    • 改写SQL

    通过改写语句,达到调整执行计划,提高运行效率的目的。这种方式的缺点是需要研发人员修改原代码,然后再进行部署上线的过程。此外,有些使用O/R Mapping工具产生的SQL,无法直接修改语句,也无法使用此方法。

    • 使用Hint

    很多种数据库都提供了提示(Hint)的功能。通过这种方式来指定语句的执行过程。这种方式同样需要修改源代码,经历部署上线的过程。此外,这种修改方式还存在适应性较差的问题。因为其指定了特有的执行过程,随着数据规模、数据特征的变化,固化的执行过程可能不是最佳方式了。这种方式实际上是放弃了优化器可能产生的最优路径。

    • 存储概要、SQL概要、计划基线

    在Oracle中还内置了一些功能,它们可以固化某一条语句的执行方式,从本质上来讲,其原理和上面使用Hint差不多。其缺点也类似上面。

    • 调整参数

    有时也可通过调整某些参数,进而改变语句的执行计划。但是这种方式要注意适用范围,不要在全局使用,避免影响较多的语句。在会话级使用也要控制范围,避免产生较大影响。

    3、层次-对象级

    如性能核心问题,在SQL层面无法解决,需要考虑对象层面的调整。这种情况要比较慎重,需要充分评估可能带来的风险及收益。一个对象的结构修改,可以涉及到数百条、甚至数千条和此相关语句的执行计划变更。如不做充分测试的情况下,很难保证不出问题。如果是Oracle数据库,可考虑使用SPA评估一下。其他数据库的话,可提前手工收集一下相关语句,模拟修改后重放上述语句,评估性能变化。

    1)影响因素

    在对象级进行调整,除了考虑对其他语句的性能影响外,还需要考虑其他因素。常见的以下这些:

    • 数据库维护成本

    常见的例如索引。通过添加索引,往往可以起到加速查询的目的;但是增加索引,会导致数据DML成本的增加。

    • 运维成本

    常见的例如全局分区索引。全局分区索引在进行分区维护动作后,会导致索引失效,需要自动或手动进行维护索引动作。

    • 存储成本

    常见的索引,索引结构是数据库中真实占据空间的结构。在以往的一些案例中,甚至出现过索引总大小超过表大小的情况,因此新增时要评估其空间使用。

    2)全生命周期管理

    这里还有另外一个很重要的概念——“对象全生命周期管理”,简单来说就是对象的生老病死。在很多系统中,对象从新建开始,数据不断增加、膨胀,当数据规模达到一定量级后,各种性能问题就出现了。对一个百万级的表和亿万级的表,其查询性能肯定不能同日而语。因此,在对象设计初期,就要考虑相关的归档、清理、转储、压缩策略,将存储空间的评估与生命周期管理一起考虑。

    很多性能问题,在做了数据清理后都迎刃而解。但数据清理往往是需要代价的,必须在设计之初就考虑这个问题。在做数据库评审的时候,除了常规的结构评审、语句评审外,也要考虑这部分因素。

    4、层次-数据库级

    到了这个层面,问题往往已经比较严重了。一般情况下,数据库的初始配置都是基于其上面运行系统的负载类型进行专门配置的。如果运行一段时间后,出现性能问题,经评估是属于全局性问题的,可以考虑进行数据库级别的调整。但是这种配置往往代价也比较大,例如需要专门的停机窗口操作等。而且这种操作的风险性也比较大,有可能会带来很多不确定因素,因此要慎而又慎。

    5、层次-数据库架构级

    如性能核心问题,无法在上述层面解决,可能就需要调整数据库架构。常见的例如采取读写分离的访问方式、分库分表存储方式等。这种对应用的侵入性很强了,有些情况下甚至不亚于重构整个系统。

    例如,随着业务的发展,系统的数据量或访问量超出了预期,通过单一数据库无法满足空间或性能要求。此时,可能就需要考虑采用一种分库分表策略,来满足这部分的需求。但其改造难度,往往比重新开发一套系统还要大。

    比如,我们可能需要一个数据中间层,来屏蔽后面的分库分表细节。这个中间层可能需要完成语句解析、访问路由、数据聚合、事务处理等一系列功能。即使使用了中间层产品,对于应用来说,数据库的功能也会相对“弱化”,应用级代码不得不进行很多的调整来适应这种变化。此外,如何把一个线上正在运行的系统,顺利平稳地迁移到新的结构下,这无疑又是一个给飞驰的跑车换轮胎的问题等等。

    如果项目在运行中,出现了数据库架构级的调整,很有可能说明在前期项目设计规划阶段出现了失误,或者对项目的业务预期出现了偏差。因此,这两点一定在初始阶段进行充分的评估,并在设计上保留有充分的“弹性”。

    6、层次-应用架构级

    有些情况下,单纯依靠数据库是无法解决的,需要综合考虑整个应用架构。在整个系统架构中,数据库往往处于系统的最末端,其扩展性是最差的。因此,在应用架构设计初期,就应该本着尽量不要对数据库产生压力的原则进行设计。或者即使有大的压力,系统可以采取自动降级等方式保证数据库的平稳运行。

    常见的例如增加缓存、通过MQ实现削峰填谷等。通过增加缓存,可以大幅度减少对数据库的访问压力,提高整体系统的吞吐能力。引入MQ,则可以将对数据库的压力以“稳态”的形式,向数据库持续施压,而不至于被某个异常高峰压死。

    7、层次-业务架构级

    最后一种情况是从业务角度进行一些调整。这往往是一种妥协,通过做适当的减法保证系统的整体运行。甚至不排除牺牲一部分用户体验等方式,来满足大部分用户的可用性。这就需要我们的架构师对系统能提供的能力要很清楚,对业务也要有充分的了解。对于承载什么样的业务,及为了承载业务所需要花费的代价成本有充分的认知,才可以做出一些取舍。

    这里要避免一些误区,认为技术是“万能”的。技术可以解决一定的问题,但不能解决所有问题,或者解决所有问题的成本代价是难以接受的。这个时候,从业务角度稍作调整,就可以达到“退一步海阔天空”的结果。

    作者:韩锋

    来源:宜信技术学院

    转载于:https://my.oschina.net/u/4007037/blog/3066688

    展开全文
  • 东莞市公安局信息中心采用了基于Unix+Oracle平台的RISC架构小型机来运行应用系统, 考虑到采购及升级成本高、系统扩展难度大和维护费用等问题, 东莞市公安局考虑使用运行LINUX的Intel IA架构服务器作为选型平台, ...
  • 目前系统架构如下: 1.web层采用struts+tomcat实现,整个系统采用20多台web服务器,其负载均衡采用硬件F5来实现;...数据库层的操作是自己写的通用类实现的,两台ORACLE数据库服务器,分别存放用户信息和业务数据;一台S...
  • 项目描述本项目采用B/S架构实现微博原有基本功能的基础上...后台使用Java语言开发,基于Spring+SpringMvc+Mybatis三大框架实现具体功能,服务器采用Tomcat服务器部署,在数据库存储方面选型采用Oracle数据库保存微博...
  • 对于这样的应用如果技术选型是Solr,就需要把数据从关系型数据库导入到solr服务器,为了解决这个问题,Apache提供了DataImportHandler,所谓的DataImportHandler就是提供一种可配置的方式向solr导入数据,可以一...
  • 1. 概述  大多数的应用程序将数据存储在关系数据库(例如oracle、mysql、sql service等等...对于这样的应用如果技术选型是Solr,就需要把数据从关系型数据库导入到solr服务器,为了解决这个问题,Apache提供了DataI
  • 一个项目,开发环境是win7 ultimate x64, visual studio ultimate 2012,Oracle10g的数据库 技术选型有:.net framework4.5, Mvc4, entity framework 5, simpleinjector 再没有别的新货了,开发阶段倒是顺顺利利,...
  • 后台服务程序框架技术选型方案

    千次阅读 2017-03-27 11:27:20
    1.硬件环境 公司服务器 2.软件环境 2.1 操作系统 CentOS 7 ...mysql or oracle mysqloracle 现在公司系统中都有用到不做过多介绍。 2.5 缓存 Redis(Codis) or MemcachedRedis 现在公司系统有用到
  • 在互联网应用中,数据爆发式的增长,实际上软件架构的本质就是对数据的维护。对数据的操作可以归纳为三类:读、写和检索。  随着网站的流量越来越大,数据量也爆发式的增长,...有关系型数据库:mysql,oracle,sqls
  • 开源监控系统介绍-Zabbix & nightingale zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。...数据库: MySQL,MariaDB,Oracle,SQL 应用软件:Nginx,Apache,PHP,Tomca
  • 在互联网应用中,数据爆发式的增长,实际上软件架构的本质就是对数据的维护。对数据的操作可以归纳为三类:读、写和检索。 随着网站的流量越来越大,数据量也爆发式...有关系型数据库:mysql,oracle,sqlserver,postgr...
  • 参数类调优 这一般包括JDK选型、JVM参数优化、中间件参数优化、数据库参数优化、服务器操作系统优化。 此类优化收益高(工作量很小但收效甚大)。2.SQL优化 这一般包括适当设立索引及调整SQL语句。 此类优
  • 代码架构(一)

    2021-03-13 22:20:33
    一个项目可能需要使用多台服务器,eg:web服务器、数据库服务器、文件服务器、CDN....... 如何针对不同的要求对服务器进行选型,这是架构;如何统一管理这些服务器,这是架构;如何让这些服务器平稳运行,这是架构...
  • mysql

    2020-10-22 10:52:11
    互联网早期的选型【IOE】:IBM的服务器Oracle数据库、EMC的存储设备,都是有钱的公司采用,例如银行、电信、石油、证券等 Mysql:互联网高速发展,互联网企业使用第一。 Oracle:互联网之外使用第一,传统软件...
  • 开发环境:MyEclipse8.5 数据库Oracle 应用服务器:Apache Server +Tomcat 7 技术选型:Spring3.0,Struts2.3.4,Hibernate3.5 技术描述:  1. View层技术: Ext,jquery 、JavaScript丰富界面。  ...
  • 内容是关于游戏服务器选型相关的内容。 服务器 分布式、架构 比如: 1. 哪些业务是需要水平扩展,哪些数据是全局的(用户信息),哪些又是局部的(游戏区数据),尽量用成熟的产品避免单点 2. 数据存储:文件...
  • 电力行业选用Oracle 作为业务的重要后台数据库,用户多、并发访问量大、数据增长迅速的特点。 考虑以上特点,方案里整体购置DELL 服务器与DELL 磁盘阵列,在选型服务器选择使用Dell PowerEdge作为热备用服务器,...
  • 3.5.1 本地Oracle业务数据库破坏而需要恢复时。 11 3.5.2 本地邮件系统破坏而需要恢复时。 12 3.5.3 本地非数据库文件破坏而需要恢复时。 12 3.5.4 操作系统的恢复: 13 3.5.5 本地OPENVIEW DATA PROTECTOR服务器...
  • 在数据库处理方面,不需要在数据层借助存储过程及数据库服务器端函数封装过多的业务逻辑,因此数据库系统采用相对精巧的MySQL[6]。 该在线博客系统服务器端如果需要布置到其他主机上,则该主机必备条件如下: 1. ...
  • 概要设计说明书模板

    热门讨论 2011-10-25 12:55:15
    例如:Oracle数据库服务 器1台,位于局信息中心,用于支撑征管业务信息处理、领导决策辅助支持、各征管业务科室的信息采集、查询及统计工作。它安装在IBM RS6000小型机上,操作系统是AIX 3.2。 说明拟采取的网络...

空空如也

空空如也

1 2
收藏数 35
精华内容 14
关键字:

oracle数据库服务器选型