作者:张子良
版权所有,转载请注明出处
1.1 引子:文件OR数据库
历史期次的双色球选注数据的存储,采用什么样的格式比较好呢?这需要重点从三个方面考虑,一、文件访问方便吗?二、文件服务器空间够用吗?三、软硬件故障环境下,如何保障数据的可用性。基于这几个方面的考虑,到底是采用文件存储还是采用数据库存储呢?本文,从传统和前沿技术两个角度给出了两种相应的解决方案。
1.2 文件存储
1.2.1 三大问题
根据上一篇《大数据应用之双色球算奖平台总体设计数据规模估算篇》分析,双色球单期次数据的存储规模在7G左右,记录数在2亿条左右。可以考虑以文本文件的方式进行存储,这里面面临三大问题,一、单个文件过大的问题,访问不便,文本文件一般来讲超过200M,使用常规文本文件阅读器打开,都会成为问题,各位可以自行尝试。二、历史期次存储空间问题,技术总是在发展的,目前一般的服务器存储空间,单台服务器硬盘配置个NT,从技术和成本角度,都不会成为障碍,双色球每周三期,考虑到节假日的因素,每年约156期,156*7=1092,所需空间约1T。三、数据高可用性问题,传统单点存储方式的缺点,不做说明,考虑一个极端,硬盘坏了,或者服务器宕机,数据怎么访问?
1.2.2 传统方案
问题的存在,不代表没有解决的方法,一切软件问题的技术解决方案,其实都是在各种妥协中寻求平衡点而已。当然总有无法平衡的时候,而这时总会有技术方面的突破,有需求才有动力。传统的方式,针对问题一,可以按照地域或者期次进行文件夹组织,按照投注站进行文件命名,不同投注站的单独期次的文件存放到同一个文件中,这样做的好处是单个文件的大小变小了,读取成为可能,缺点是你要去管理大量的小文件。针对问题二、如果考虑一台主机就能存个三年五载的数据,不妨搞个磁盘阵列,或者多加几块T级的存储硬盘。这么做的好处是空间问题得到解决了,缺点是仍然面临IO读取速度的问题。针对问题三、可以采用磁带机,或者物理隔离的冗余备份,考虑到数据的特点,数据一次写入,不会发生变更,所以即使是刻盘的方式都是能够解决问题的,这么做自然能做到保障数据的可用性,但是同样的存在问题,那就是即时可用性,无论什么原因,我必须停下当前的工作,重新进行数据的导入和加载。
1.2.3 前沿技术
如果双色球历史数据存储的问题,结合最新的分布式存储(HDFS),会得到怎么样的效果呢?我们不妨仔细的考虑一下。如果采用分布式单文件存储,每一期作为一个文件,可以很好的解决存储空间和高可用性的问题,但是分段读取还是一个障碍,除非你一次想使用整个文件。所以还是要妥协,那就是把文件按照上一节中提到的方式进行切分。只是考虑业务分析的需求,粒度可以控制在以地域为单位或者以投注站为单位,粒度过细则会涉及到HDFS文件分块的问题(64M)。
1.3 数据库存储
1.3.1 核心问题
考虑到双色球投注数据的特点,每一个选注为一个独立的数据单元,一条记录。采用关系型数据库进行存储的好处很明显,就是结构清晰,访问方便。但是由于数据规模的问题,单表存储2亿条记录,如果采用传统关系型数据库,面临的核心问题就是单表记录数过大的问题。
1.3.2 传统技术-分区&分表
历史的因素,关系型数据一致面临大数据应用领域的挑战,当然也衍生出来许多的解决办法,比如说分区,比如说分表。分区的核心思想在于增加单表的空间,而分表的核心思想则在于分而治之。但是都无法逃避单点访问受限的问题,再怎么变,也要受控于RDMS服务器的性能。
1.3.3 前沿技术-NoSQL
如果采用No-SQL技术(Hbase)又会是怎么样的情形呢?我们以期次为单位组织表结构,每期一个文件,以投注站编号和流水号为rowkey,以红球为family1,以篮球为family2。根据Hbase的特点,则既可以解决记录数的问题,也可以解决访问并发访问性能的问题(Hbase文件存储采用HDFS)。同时Hbase基础之上有很多分布式并行计算的工具可用,可以很好的协调多服务器的并行计算。
1.4 对比分析
前文已述,很喜欢No-SQL方式的实现,个人认为是目前最为恰当的方式。引玉抛砖,还是多听听各位大牛的意见吧。