1700509183
(4) 文档地址：http://hekad.readthedocs.io/。
1700509184
1700509185
(5) 目前的Fluentd版本默认只在S3为接收端的情况下提供对SSL证书的支持。
1700509186
1700509187
(6) 美国甲骨文公司的数据库拳头产品，8i版本在1998年发布，目前最高版本为12c。
1700509188
1700509189
(7) 主要是指IEEE 802.11x协议族。
1700509190
1700509191
(8) “MIPS”是“Million Instructions Per Second”（单字长定点指令平均执行速度）的缩写，每秒处理的百万级的机器语言指令数。
1700509192
1700509193
1700509194
1700509195
1700509196
数据科学家养成手册 [:1700503615]
1700509197
数据科学家养成手册 第13章 数据存储
1700509198
1700509199
当一台服务器收到由其他服务器传来的日志数据时，一般有两种处理方式：一种是在内存中直接处理，进行流计算，计算完毕后将计算结果保存或者输出到指定位置，原始日志数据直接丢弃；另一种是直接写入持久化存储介质（例如文件、数据库等），以备后续的查询和统计分析等。还有一些场景会将两种方式结合使用，既做流处理用于快速反馈数据，也把日志进行持久化归档处理。
1700509200
1700509201
流处理不属于数据存储的范畴，这里就不多讨论了。我们只需要理解这样一个概念：这种处理就是在内存中留一个池空间，当数据从网络高速写入这个内存池空间的时候，可以根据需要把这个池空间当成磁盘上的文件进行相应的统计计算，然后设置清空策略（可以采用滑动窗口策略，也可以进行固定时长清空）。
1700509202
1700509203
将数据保存到磁盘上是非常讲究的，需要考虑的问题也比较多。对一台服务器来说，当它收到数据准备写入磁盘的时候，会面临很多选择——没错，还是各种矛盾的权衡。
1700509204
1700509205
1700509206
1700509207
1700509208
数据科学家养成手册 [:1700503616]
1700509209
数据科学家养成手册 13.1 读写不对等
1700509210
1700509211
一台服务器的硬件资源确定后，对于存储就有这样一个问题需要考虑——读写场景是什么？
1700509212
1700509213
“读写都少”的情况基本不用考虑对矛盾的权衡，因为此时的磁盘I/O资源非常充分。而在“读多写少”、“读少写多”、“读写都多”这3种场景中，还是要考虑资源怎么分配才能最大化地满足业务需要。
1700509214
1700509215
另外，读写操作涉及的范围是什么形态（I/O模型）也很重要。就拿读来说，读得频繁而每次只读取少量数据是一种情况，即“小I/O频繁读”；读得不频繁而每次需要读取大量数据是另一种情况，即“大I/O低频读”。更有甚者，读得频繁且每次都读取大量数据，这种场合下往往都会使总吞吐量超过磁盘I/O的吞吐上限，处理原则通常是先设法将这个业务分散到多台物理机上，也就是化简这种情况，使之变成前两种情况中的一种再做考虑。遇到任何一种情况都无须惊慌，因为对这些情况都有成熟的解决方案。
1700509216
1700509217
凡是最后要存储在磁盘上的数据，都要使用文件系统作为落地方式。即使是像Oracle裸设备或者Oracle ASM(1)这种不使用Linux系统作为文件分配表的系统，也不过是Oracle自己接管了磁盘，自己编写文件分配算法而已。以CentOS为例，CentOS 6使用ext4作为默认文件系统，CentOS 7则改用XFS作为默认文件分配系统。对于文件系统的选择，我们一般关注读写吞吐速度、可靠性、可扩展性这3点。
1700509218
1700509219
对于磁盘I/O已经确定的情况（传统的机械硬盘取决于磁盘自身接口带宽、主板SATA或SAS总线带宽及磁盘转速等因素），改进吞吐能力的空间通常很小。
1700509220
1700509221
数据科学家养成手册 [:1700503617]
1700509222
13.1.1 读多写少
1700509223
1700509224
“读多写少”是一种在互联网领域很常见的读写模型（如图13-1所示）。在微博、新闻等网站都会有这样的模式：一个进程向磁盘上的某个地方写了一段数据，无论数据载体是数据库还是文件，此后高频次的访问都会扫描磁盘的这块地方。
1700509225
1700509226
1700509227
1700509228
1700509229
图13-1 读多写少
1700509230
1700509231
这种情况下，通常考虑直接把读I/O的部分分摊到多个读I/O单元中去。例如，MySQL的读写分离就是一种典型的应对“读多写少”的方式，先在主库中写一份数据，再同步到N个从库。这样，再从从库中读取数据时，吞吐能力就变成了原来的N倍。这种方式在其他类似的场景中同样适用。
1700509232