不管是对于传统行业还是对于互联网行业，交易订单数据的存储需求由来已久，比如笔者最初所处的民航业，其CRS系统（代理人机票售票系统）存储了旅客的订座记录；又如各类银行需要存储广大储户在其系统内的支取和存入的流水记录；再如电子商务/第三方支付平台，广大网民的网购、缴费、理财、充值等交易行为的记录也需要保存。
交易性质的数据往往有较强的事务需求，比如电商系统中交易数据的存储会有多张表，表与表之间的数据需要保证强一致性。基于这样的要求，CRS系统最初选择了专业性较强的Unisys大型机系统及其数据库；银行的选择则是大家较为熟悉的IBM DB2；而淘宝/支付宝这样的电子商务的领头羊，最初的选择则是Oracle，在Oracle时代往往是一个业务一套数据库，不同业务做垂直隔离，其架构如下图所示：
![图片]( "image.png")
如前所述，对于第三方支付场景，交易系统主要面向接单，操作以写入为主。但是，随着其业务场景的不断丰富，从最初只有网上购物，之后涌现出转账、公共事业缴费、话费充值等等越来越多的场景，而这些系统因其业务特征的不同，往往是相互垂直，相对独立的交易系统。这样一来，对于一个普通网民而言产生了一个朴素而基本的需求，有一个统一的账单查询入口，毕竟普通老板姓的钱不是大风刮来的。因此，账单系统应运而生。
二.互联网账单系统的架构演进
互联网账单系统，从诞生的第一天起附带了一些天然的属性。
只读性：账单的数据来自于上游各个交易系统，通过可靠消息进行数据同步，提供统一的查询入口给最终用户。
高增长：互联网的一个非常典型的特征就是超乎想象的高速增长，特别是处于风口的猪，是真的会被吹起来的。
低成本：账单系统不像交易系统，不直接产生经济效益，总有一种庶出的感觉。因此，期望重金投入那是绝对不可能的。
高可用：账单系统是面向客户，对交易系统的延伸，是客户对交易数据的查询入口，对C端客户而言，其实并存在交易系统和账单系统的区分。因此，这两个系统的可用性要求是一致的。
多维度查询：对于C端用户而言，往往会从不同角度对账单进行分类、标记以及查看和过滤自己的账单。
2.1一代架构
2.1.1 基于MySQL的分库分表
基于上述的特征，在IOE还处于统治地位的时代，支付账单系统最初拥抱的并不是交易系统使用的、成本高昂的Oracle数据库，而是开源世界里最流行的、基于PC服务器的MySQL数据库，并且因为规模的原因，往往需要引入相对更加复杂的分表、分库方案，其架构如下图所示(图中省略了MySQL Slave集群及Master、Slave间的复制关系)：
![图片]( "image.png")
然而，如前所述，业务的快速增长带来数据的极速膨胀，需要不断的增加分表、分库的数量，否则就会达到MySQL单实例的瓶颈，而拆分为更大规模的分表、分库的运维代价是极其巨大的。基于此原因，账单系统的存储演变到了下一代架构。
2.2 二代架构
上文描述到，随着业务的不断增长，由于MySQL自身容量的天花板，第一代架构面临的问题无法解决，单纯依赖MySQL的架构已经不再是账单业务的合适选择。
因此，不同的用户做出了不同的选择。
2.2.1 MySQL热数据+HBase全量的混布架构
做为架构演进的一种选择，有一部分用户的选择是仍然依赖MySQL，但会将通过消息系统过来的数据同时写入到MySQL的分表和HBase集群中的单表。MySQL做为主存储，承担“热”数据的读请求，而HBase做为备存储，仅承担历史数据的读请求。这种架构下MySQL仅需要保存业务定义的指定周期内的热数据，因此，在演变到该架构的初期，极大的缓解了数据增长带来的压力。
但是，随着时间的推移，业务的飞速发展，热数据的量不断变大，因此仍然面临继续做拆分的需求；而且需要每天起定时任务进行历史数据的删除，大规模的数据删除引起了集群负载的升高，对集群稳定性产生了严重的隐患；
另一方面，业务形态也在发生变化，比如：出现了最典型的“双十一”，这样超级的业务大热点，这就迫使需要对MySQL做更细粒度的拆分，并且每年大促前要大量扩容节点，大促后还原到原有规模，这对于存储系统提出了极致的弹性扩缩容需求，而这样的要求对于存储计算一体化的架构而言是非常大的挑战。
同时，双十一带来的不仅仅是业务量上的一个巨大尖刺，也带来了一些其他的不稳定因素，比如：会随时奔出来一个大卖家，这样的大热点往往导致单个MySQL实例容量不足，在计算存储一体化的架构下，应对这样的问题总是显得有点力不从心。
2.2.2 基于Share Nothing架构的分布式关系型数据库
做为架构演进的另一种选择，其他一部分用户则抛弃了MySQL，选择新的市面上比较流行的分布式关系型数据库。分布式关系型数据库通过其内置的数据分片的能力，很好的避免了业务增长、新业务场景(双十一)带来的分库、分表的需求；通过其自动化的扩容/缩容能力，相比MySQL架构下的运维成本也有大幅度的降低。
但是，这种架构下也面临着一些问题：
2.3 三代架构
因此，势必需要有一种新的更完善的数据库产品来满足账单场景的需求。
首先，我们简单回顾一下一、二代架构下面临的最核心的业务痛点，也是三代架构下必须要着重面对并且解决的问题。
那么，市面上是否存在这样的一款数据库产品“恰好” 能解决账单场景在一、二代架构下遇到的问题，同时又能很好的满足账单系统对可用性，对多维度查询的要求？答案是肯定的。Lindorm正是这样一个合适的数据库选型。
三.基于Lindorm的架构
Lindorm是诞生于大数据时代的一款NoSQL数据库，低成本解决海量大数据的高效存、取是根植于其体内的基因。Lindorm在阿里内部历经十年的技术积淀，目前是阿里内部使用最为广泛的、数据体量最大的核心数据库产品。这一切归功于Lindorm拥有众多的核心技术和功能特性。
那么，面向账单场景的业务痛点，Lindorm有哪些重要的抓手呢？
3.1 低成本
对于账单这样的海量数据场景，数据有着非常典型的访问特征，近期数据访问频率较高，请求的响应延迟要求也较高，随着时间的推移访问频率会逐步降低，甚至仅作为历史数据存在，而只有极少量的访问，但另一方面业务要求数据永久保留的特性，导致其在线数据体量非常大。Lindorm的冷热分离和压缩优化则可以非常有效的解决这个问题。
3.1.1 冷热分离
Lindorm具备在单一个存储架构下的“一张表”内实现数据的冷热分离，系统会自动根据用户设置的冷热分界线，自动将表中的冷数据归档到冷存储中。在用户的访问方式上和普通表几乎没有任何差异，在查询的过程中，用户只需配置查询Hint或者Time Range，系统根据条件自动地判断查询应该落在热数据区还是冷数据区。对用户而言始终是一张表，对用户几乎做到完全的透明。
![图片]( "冷热分离.png")
3.1.2 压缩优化
存储成本最低的系统是没有数据需要存储的系统，但这点显然是不现实的，现实可行的方案是将需要存储的数据降到合理的最低点。
为了降低存储开销，Lindorm引入了一种新的无损压缩算法，旨在提供快速压缩，并实现高压缩比。它既不像LZMA和ZPAQ那样追求尽可能高的压缩比，也不像LZ4那样追求极致的压缩速度。这种算法的压缩速度超过200MB/s, 解压速度超过400MB/s（实验室数据），很好的满足Lindorm对吞吐量的需求。经实际场景验证，新的压缩优化下，压缩比相对于LZO有非常显著的提高，存储节省可以达到50%～100%，对于存储型业务，这就意味着最高可以达到50%的成本减少。
3.2 极致弹性
互联网世界总是以超乎想象的速度在飞速增长。账单的峰值读&写请求量、需要存储数据量会伴随着业务飞速的增长，每年都会是上一年的翻倍甚至数倍，因此需要存储系统具备良好的扩展能力。
双十一这样的业务场景，则会瞬间带来数十倍甚至百倍的峰值读写量，为了满足这样的场景，就需要存储系统具备更加极致的弹性扩、缩容的能力。
如前所述，低成本解决海量大数据的高效存、取是根植于Lindorm体内的基因。因此，Lindorm天然就具备了良好的线性扩展能力，可以很好的支撑每秒亿级别请求，PB级数据量，而且在大数据量、高并发下仍然能提供稳定的毫秒级的平均响应。
Lindorm原生支持存储计算分离架构( 其架构如下图)，这样的架构设计使得集群扩容、缩容都变得非常的轻量，说简单一点就是“起个进程+数据分片balance”这点事，新节点接收业务请求并不需要等待历史数据的搬迁，而缩容刚刚好是逆向的过程。因此，对于Lindorm而言弹性扩缩容当然是分分钟搞定咯！
![图片]( "Lindormarch.png")
3.3 热点问题
3.3.1 高效热点响应
交易分为买家和卖家两个对手方，账单数据也往往会按照这两个用户维度进行组织。从单个买家角度看往往交易量较低，不至于形成热点。但是卖家却可能是一个大的焦点，特别是在双十一这样的大压力下，单个UID的交易量尖刺往往会更高。
热点对于任何一个存储系统而言都是灾难性的，但Lindorm天然的读写分离架构在应对热点方面会有更大的优势。
Lindorm分为存储和计算两层，LDserver负责数据分片的组织和读写访问，Lindorm Store负责文件的存储和访问。数据分片在不同LDserver之间的移动并不需要考虑Lindorm Store层存储位置。因此，当读写出现热点时，Lindorm可以通过快速移动数据分片到空闲节点，即可秒级完成热点数据分片的隔离，达到提升抗热点的能力。
3.3.2 存储水位不均问题
如前所述，Lindorm采用存储计算分离的架构，数据按region进行分片，其大小在GB级别，通常指定为8G，16G，超过阈值会自动进行split，数据分片会自动在不同节点间进行balance。因此，这样的架构设计使得Lindorm可以很好的保持不同节点间数据量的均衡。从而很好的避免了Share Nothing架构下热点账号带来的“不必要”的运维工作。
3.4 其他必要特性
Lindorm的上述几个特性很好的解决了账单系统在一、二代架构中难于解决的问题，但是账单场景对存储系统基本要求：可用性、多维度查询，在三代架构下也是必须要满足的，否则就是顾此失彼，甚至得不偿失了。
3.4.1 高可用
Lindorm的表数据通过自动balance策略分散到集群中的多台服务器上，每一个数据分片可以拥有1至N个副本，这N个副本拥有主、从两种角色，主从副本可以加载在不同的Zone，从而保障集群的高可用和强一致。针对不同的一致性模式，主从副本之间的数据同步和读写模式如下：
强一致模式：只有主副本提供读写，数据会异步回放到从副本,主副本所在节点故障，从副本晋升为主(晋升之前会保障数据同步完成，从副本拥有所有最新数据，整体过程由Master协调负责)
最终一致模式：主从副本都提供读写，数据会相互同步，保证副本之间的数据最终一致。
![图片]( "LindormHA.png")
通过这样的高可用机制，Lindorm可以很好的保障账单这样的对数据强一致性和可用性需求都非常高的业务。
3.4.2 多维度查询
为了解决业务基于非主键列的查询问题，Lindorm内置原生的全局二级索引功能，对于列较少且有固定查询模式的场景来说，高性能二级索引方案能够完美解决此类问题，同时仍保持强大的吞吐与性能。
![图片]( "LindormIndex.png")
当面对更加复杂的查询，比如模糊查找、随机条件组合查询等等，二级索引方案会显得力不从心，这时候Lindorm搜索引擎LSearch就有其用武之地。LSearch是面向海量数据设计的分布式搜索引擎，兼容开源Solr标准接口，同时可无缝作为宽表、时序引擎的索引存储，加速检索查询。其整体架构与宽表引擎一致，基于数据自动分区+分区多副本+Lucene的结构设计，具备全文检索、聚合计算、复杂多维查询等能力，支持水平扩展、一写多读、跨机房容灾、TTL等，满足海量数据下的高效检索需求。
![图片]( "画像8.png")
四.Lindorm核心能力概述
Lindorm通过全方位多角度的能力提升，充分满足了账单场景的高可用、高吞吐、低延迟、低成本、多维度及可能的突发热点请求等等一系列的需求。
当然，Lindorm的能力还远不止于此，Lindorm具备了大数据背景下，面向海量数据的存储系统应该具备的一系列的能力：
是一款支持宽表、时序、搜索、文件的多模数据库
是一款基于存储计算分离架构的数据库，提供极致的计算、存储弹性伸缩能力，并将全新提供Serverless服务，实现按需即时弹性、按使用量付费的能力
是一款支持冷热分离、、追求更优压缩优化方案的极具性价比的数据库
是一款具备全局二级索引、多维检索、时序索引等功能的数据库
提供具备智能化服务能力的LDInsight工具，白屏化完成系统管理、数据访问及故障诊断
提供LTS(Lindorm Tunnel Service，原BDS)，支持简单易用的数据交换、处理、订阅等能力，满足用户的数据迁移、实时订阅、数湖转存、数仓回流、单元化多活、备份恢复等需求
5、账单场景客户案例
第三方支付账单
某国内领先的第三方支付平台，致力于提供“简单、安全、快速”的支付解决方案。自2014年第二季度开始成为当前全球最大的移动支付厂商。
自从2013年起，该第三方支付平台已经将其全量的在线交易、线下交易、缴费、转账等等各类交易数据全量存储在Lindorm内，提供实时、在线查询，可以获取账单详情以及通过各类筛选条件满足C端用户的账单筛选需求。
![图片]( "alipay.png")
收钱吧
隶属于上海喔噻互联网科技有限公司，是中国移动支付服务商领军者，致力于用网络和数据的力量服务线下实体商家。收钱吧不仅为商家提供专业移动支付收款工具，同时也是为商家提供金融、广告、营销管理、供应链等多种服务的生意帮手。2014年12月，收钱吧正式上线，开创了中国移动支付市场“一站式收款”时代，并成功研发了“收钱吧扫码王”等全场景智能收款设备，产品获得多项国家专利。目前收钱吧服务超过330万商家，日服务3000万人次。
收钱吧使用Lindorm作为其订单解决方案，成功实现了：
全文索引方案，使得业务高性能实现高维度&随机组合场景下的订单搜索
数据压缩优化及集群内冷热分离，使得业务低成本实现数据永久保留
相比优化前的架构，成本下降77.42%
全托管、免运维及SLA保障，并有专家团队的免费技术支持，使客户能全力以赴聚焦业务侧发展
