DAY 11 Big Data 5Vs – Velocity(多样性)

另一个常见资料库分类是从「资料处理*」的应用角度来区分：

交易型Transaction: OLTP:
适合较多输入(写入与更新)的应用
记录交易型资料(如银行交易)
资料期间较短(3-6个月)
常见以Row-Based的资料库储存
资料体相对较小
使用者较多

分析型Analytical: OLAP:
适合较多输出(读取)的应用
储存整合後资料
资料期间较长(2-5年)
较适用Columnar indexing 资料库(如 Redshift)可以有更好存取效能
资料体相对较大
使用者较少

这两类型的资料库并不是对立，更像是前後处理阶段之分，常见的应用场景像是银行的资料库：每天频繁的交易产生出一笔笔的交易纪录，各地分行的资料都存在各自的OLTP资料库中。到了晚上，总行统一将分行资料更新至大型的OLAP资料库，以利帐务记录与交易统整；当每日资料累积到月底的时候，资料分析人员便可以利用OLAP资料库帮使用者整理出他的交易行为与提出理财建议。

总结目前为止提到的资料储存型态：
资料仓储 Data warehouses：适合强结构化资料的集中储存中心，适用有复杂查询语句的应用场景
资料湖 Data lakes：适合当资料格式多样的储存中心，要查询资料需较多程序
OLTP资料库：适合结构化且频繁写入或更新的资料，不适合频繁查询
OLAP资料库：适合结有已经过资料清洗的资料，适合快速查询与分析的应用场景

除了目前为止介绍的DB服务外，AWS上还有许多专为其它资料类型而设计的资料库，例如：更快速的记忆体资料库Amazon ElastiCache；图形化资料库Amazon Neptune；为IOT串流应用的时间序列资料库Amazon Timestream；具可靠加密验证功能的总帐资料库Amazon Quantum Ledger Database等。当然以上提到的AWS资料库服务，有些目前还有限制使用区域，但从各种资料库的类型可以看出资料的多样性。

丰富的资料经过时间积累都可能会让使用者面临容量问题，解决资料流中数据「巨量」的问题，增加储存容量是一种方法，而另一种方式就是加速处理。接下来会讨论如何更快速的处理这些使用者辛苦累积下来的巨量资料。

*线上资料处里(https://zh.wikipedia.org/wiki/%E7%B7%9A%E4%B8%8A%E5%88%86%E6%9E%90%E8%99%95%E7%90%86 )