oracle 数据移植如何保证顺序一样_微服务数据库与 NOSQL 选型

传统单体应用典型的架构是几点个应用程序服务器, 连接后台的 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 选型并不难, 总有一款适合你.