加载中…
借SAP ASE 16.0新发布，再谈并未过时的OLTP
(2014-04-18 15:45:34)
标签：
数据库oltp12306ase铁路客票 |
昨天和今天各发了两条微博，一条关于SAP ASE最新的16.0正式发布，另一条是关于富士通与SAP一起发布ASE一体机，加上前一段小圈子里面很热门的一篇文章，是转自西西河的一篇文章，以一个淘宝工程师的角度看铁路客票系统12306的特点和难点，引发很多人热议，也着实勾起我一直想写，一直没有写，一直没有敢写的话题。
今天也只想聊聊这里面的一些纯理念问题，说说OLTP，铁路客票销售的应用里揭示着什么样的OLTP问题，以及当今的OLTP发展的现状及未来的一些看法。
曾几何时，大家（包括我在内）似乎把焦点转移到数据分析，OLAP，BI，内存数据库，现在更是大数据这些“更性感”、更有“价值”、更吸引眼球的内容上，对OLTP的关注有所下降，认为这是一个即将过时的技术话题。但是事实上，OLTP系统一直都是数据的来源所在，原本所在，OLTP问题也是数据库界遇到和解决的第一个大问题，在解决这个问题的过程中，数据库界发现了很多原理，创立了很多规范，也有很多数据库公司因此产生，因此发达。
今天也只想聊聊这里面的一些纯理念问题，说说OLTP，铁路客票销售的应用里揭示着什么样的OLTP问题，以及当今的OLTP发展的现状及未来的一些看法。
曾几何时，大家（包括我在内）似乎把焦点转移到数据分析，OLAP，BI，内存数据库，现在更是大数据这些“更性感”、更有“价值”、更吸引眼球的内容上，对OLTP的关注有所下降，认为这是一个即将过时的技术话题。但是事实上，OLTP系统一直都是数据的来源所在，原本所在，OLTP问题也是数据库界遇到和解决的第一个大问题，在解决这个问题的过程中，数据库界发现了很多原理，创立了很多规范，也有很多数据库公司因此产生，因此发达。
OLTP，最早的概念顾名思义：联机交易处理 -- On-Line Transaction
Processing，其应用背景来源于银行业务，最简单地说，“从账号A给账号B汇款100元”就是一个最最原始、最最经典的交易处理，简单地说这个交易的步骤不管谁先谁后，总是分为两步：
- 账号A取出100元
- 账号B存入100元
然而，这两步必须要么同时发生，要么同时失败，才能成为交易，这个交易的概念，也广泛而深刻地沿用到了数据库领域，在数据库中实现这个交易，也是要实现“交易的原子性”：要么全部完成，要么全部不完成，不会结束在中间某个环节
- Begin Transaction
- A = A - 100
- B = B + 100
- Commit Transaction
两句额外添加的Begin/Commit Transaction就是数据库中保证交易原子性的。
从90年代初开始，过去20年的数据库技术基本上围绕这个OLTP在发展，当然硬件水平的提高，存储技术的发展，使得数据库的能力有了大幅的提升，围绕着OLTP也出现了不少的新技术，也逐步解决了大部分企业业务系统中的OLTP场景，其中有几个场景是在OLTP发展历史上是有标志性意义的，而这两个场景在现今仍然是OLTP中最高级的挑战：
- 订票业务：无论飞机票、还是火车票的订票业务中，任何时间都有多个人并发在抢票，然而同一个座位的票不能同时卖给两个人，这个就是数据库里面的并发处理机制，在任何一个时间点上，该座位的票应该分配给最先发出请求的人。
- 股票交易：对金钱的理解，全世界没有哪个民族比犹太人更深刻，引入价格机制是金融界的创举，从而使得商品和价格挂钩，在股票交易平台上，除了时间优先之外，还有价格优先原则。在数据库的实现上，任何一支股票的“交易”都变得比订票业务更复杂，更细腻，因为同时到达的请求，价格高的排前，这样实际上对交易量（需求）是有一定程度的压制作用的
回过头来说12306，中国的铁路客票系统是一个非常文明、非常人性化的应用，其实简单地从IT系统承受能力的角度来看，解决12306系统压力问题的方法有两个：
- 像全球第二大的铁路客票系统---印度铁路（刚巧也是架构在SAP ASE的技术上），在印度铁路客票系统中，很多次等车厢的车票是不保证座位的，你买到的票只能保证你上车，这样，客票系统的逻辑简单，交易迅速；但是上车之后的场景是这样的：
http://s6/mw690/001ZJbe1ty6IcEwgxa575&690ASE 16.0新发布，再谈并未过时的OLTP" TITLE="借SAP ASE 16.0新发布，再谈并未过时的OLTP" />
另一个解决铁路客票系统拥堵的好办法是学习犹太人，引入价格机制，也就是价格像机票/股票一样随供需关系而波动，按照中国的春运的需求，估计价格上浮10倍可能也一样趋之若鹜，但是毕竟以价控量，IT系统支撑也不难。然而缺陷也是致命的，春运就变成了有钱人的天堂，社会之不稳定因素也像这幅股票价格波动图一样。
http://s13/mw690/001ZJbe1ty6IcFokE20dc&690ASE 16.0新发布，再谈并未过时的OLTP" TITLE="借SAP ASE 16.0新发布，再谈并未过时的OLTP" />
好，说完了政治问题，说说铁路客票的技术挑战，以及OLTP的发展方向，据我的了解，12306现在负担了铁路客票系统一半的业务量，而这一半的售票量产生的访问量峰值达到144亿次，相当于每分钟164万次，每秒钟27397次，虽然这并不是实际意义上的交易，但是这仍然属于数据库访问范畴，是需要通过数据库技术来实现的。
另外，谈到数据库，就一定要谈实际的“Transaction”，因为这通常是衡量数据库好坏的硬指标，虽然铁路客票系统每天的售票量只有1000万左右，但是这1000万张票后面的座/铺位、等级、路局等等各种各样的业务逻辑使得一张票的产生引发多种数据关系的联动及制约，而每一个联动及制约都可能是一个单一的数据库交易，按照我询问到的“不科学”估计，一张票的销售在数据库后台产生的“交易量”可能是几十倍，这样全天全系统的数据库交易量就达到数亿次。而且鉴于铁路客票是全网联网销售，也就是意味着任何一个时间可能出现来自北京、新疆、海南、哈尔滨的多个客人同时抢一个车次的票，而这个“票”或者“铺位”的信息是实时更新，数据上无法进行像淘宝电商那样的简单分割的，而这一个OLTP系统所承担的交易量肯定比任何一台淘宝分布式数据库系统中承担的交易量要大。这也就不能理解以开源数据库思想为起点，以电商系统架构背景的12306ng.org项目最终发现致命的挑战，很快无疾而终了，现在连里面的垃圾贴都没有人去清理。
http://s7/mw690/001ZJbe1ty6IcJiHfzof6&690ASE 16.0新发布，再谈并未过时的OLTP" TITLE="借SAP ASE 16.0新发布，再谈并未过时的OLTP" />
当今的OLTP市场挑战在亚洲，亚洲的OLTP市场挑战在中国、印度，和这两个国家的人口有关，也和他们现在的经济发展现状有关，我在两年前在SAP全球数据库解决方案部工作时就在总部推动了一个观点，如果想要做好数据库，特别是OLTP数据库（ASE），必须以中国的业务场景为模型，解决中国的极端交易系统（XOLTP）场景，才能在全球市场打开局面，今年发布的ASE
16.0也正是在这样的调子下，重点在铁道科学研究院进行了Beta测试，其结果证明在单机扩展到80核的情况下，数据库能够线性提升性能
http://s16/mw690/001ZJbe1ty6IcIT1WTJ4f&690ASE 16.0新发布，再谈并未过时的OLTP" TITLE="借SAP ASE 16.0新发布，再谈并未过时的OLTP" />
OLTP未来解决的极端交易场景包括：
- 极大交易量
- 极高并发量
- 极短交易周期
- 极端硬件配置
等等，SAP
ASE重点发展例如在锁机制的改进，内存结构的进一步压缩（包括数据页的压缩及索引页的压缩），查询优化器的进一步提升，复杂查询的高效处理、简化DBA工作等等方面努力。
未来的OLTP的展望：
- OLTP的路还没有走完，还有很多方面有不少空间可以改进
- 内存技术的普遍接受，价格的下调会使得基于内存的OLTP处理有比较大的想象空间
- 分布式的OLTP，个人并不看好对效率有重要提升，反而是对可靠性，负载均衡等方面有帮助
以上内容仅个人观点，欢迎大家讨论，批评。
喜欢
0
赠金笔
前一篇：放鞭炮的文化