s
Druid is a high-performance, column-oriented, distributed data store.
Introduction and comparison of OLAP and OLTP
http://76287.blog.51cto.com/66287/885475
http://blog.csdn.net/zhangzheng0413/article/details/8271322/
Introduction to OLTP and OLAP
Data processing can be roughly divided into two categories: online transaction processing OLTP (on-line transaction processing), online analytical processing OLAP (On-Line Analytical Processing). OLTP is the main application of traditional relational databases, mainly for basic, daily transaction processing, such as bank transactions. OLAP is the main application of data warehouse systems, supporting complex analysis operations, focusing on decision support, and providing intuitive and easy-to-understand query results.
The OLTP system emphasizes the efficiency of database memory, the command rate of various memory indicators, the binding variables, and the concurrent operation; the
OLAP system emphasizes data analysis, the SQL execution market, the disk I/O, and the partitioning.
Comparison between OLTP and OLAP :
OLTP, also called Online Transaction Processing (Online Transaction Processing) , represents a system with a very high transactional nature, generally a highly available online system, mainly small transactions and small queries. When evaluating its system, it is generally based on its The number of Transactions and Execute SQLs executed per second. In such a system, a single database often processes more than hundreds or thousands of transactions per second, and the execution volume of Select statements is thousands or even tens of thousands per second. Typical OLTP systems include e-commerce systems, banks, securities, etc., such as the business database of eBay in the United States, which is a typical OLTP database.
The most likely bottleneck in OLTP systems is the CPU and disk subsystems.
(1) The bottleneck of the CPU is often manifested in the total amount of logical reads and computational functions or processes. The total amount of logical reads is equal to the logical reads of a single statement multiplied by the number of executions. If a single statement executes quickly, the number of executions is very high. More, then, may also lead to a large total logical read. The design method and optimization method is to reduce the logical read of a single statement, or to reduce their execution times. In addition, the frequent use of some computational functions, such as custom functions, decode, etc., will also consume a lot of CPU time, resulting in increased system load. The correct design method or optimization method needs to avoid the calculation process as much as possible, such as It is a good way to save the calculation results to the statistics table.
(2) In the OLTP environment, the carrying capacity of the disk subsystem generally depends on its IOPS processing capacity. Because in the OLTP environment, the physical read of the disk is generally db file sequential read, that is, a single block read, but this read is very frequent. If the disk subsystem can't handle its IOPS frequently enough, there will be a big performance problem.
OLTP比较常用的设计与优化方式为Cache技术与B-tree索引技术，Cache决定了很多语句不需要从磁盘子系统获得数据，所以，Web cache与Oracle data buffer对OLTP系统是很重要的。另外，在索引使用方面，语句越简单越好，这样执行计划也稳定，而且一定要使用绑定变量，减少语句解析，尽量减少表关联，尽量减少分布式事务，基本不使用分区技术、MV技术、并行技术及位图索引。因为并发量很高，批量更新时要分批快速提交，以避免阻塞的发生。
OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的系统。 对于数据块来说，应尽可能让数据块保存在内存当中，对于SQL来说，尽可能使用变量绑定技术来达到SQL重用，减少物理I/O 和重复的SQL 解析，从而极大的改善数据库的性能。
这里影响性能除了绑定变量，还有可能是热快（hot block）。 当一个块被多个用户同时读取时，Oracle 为了维护数据的一致性，需要使用Latch来串行化用户的操作。当一个用户获得了latch后，其他用户就只能等待，获取这个数据块的用户越多，等待就越明显。 这就是热快的问题。 这种热快可能是数据块，也可能是回滚端块。 对于数据块来讲，通常是数据库的数据分布不均匀导致，如果是索引的数据块，可以考虑创建反向索引来达到重新分布数据的目的，对于回滚段数据块，可以适当多增加几个回滚段来避免这种争用。
OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。
在OLAP系统中，常使用分区技术、并行技术。
分区技术在OLAP系统中的重要性主要体现在数据库管理上，比如数据库加载，可以通过分区交换的方式实现，备份可以通过备份分区表空间实现，删除数据可以通过分区进行删除，至于分区在性能上的影响，它可以使得一些大表的扫描变得很快（只扫描单个分区）。另外，如果分区结合并行的话，也可以使得整个表的扫描会变得很快。总之，分区主要的功能是管理上的方便性，它并不能绝对保证查询性能的提高，有时候分区会带来性能上的提高，有时候会降低。
并行技术除了与分区技术结合外，在Oracle 10g中，与RAC结合实现多节点的同时扫描，效果也非常不错，可把一个任务，如select的全表扫描，平均地分派到多个RAC的节点上去。
在OLAP系统中，不需要使用绑定（BIND）变量，因为整个系统的执行量很小，分析时间对于执行时间来说，可以忽略，而且可避免出现错误的执行计划。但是OLAP中可以大量使用位图索引，物化视图，对于大的事务，尽量寻求速度上的优化，没有必要像OLTP要求快速提交，甚至要刻意减慢执行的速度。
绑定变量真正的用途是在OLTP系统中，这个系统通常有这样的特点，用户并发数很大，用户的请求十分密集，并且这些请求的SQL 大多数是可以重复使用的。
对于OLAP系统来说，绝大多数时候数据库上运行着的是报表作业，执行基本上是聚合类的SQL 操作，比如group by，这时候，把优化器模式设置为all_rows是恰当的。 而对于一些分页操作比较多的网站类数据库，设置为first_rows会更好一些。 但有时候对于OLAP 系统，我们又有分页的情况下，我们可以考虑在每条SQL 中用hint。 如：
Select a.* from table a;
分开设计与优化
在设计上要特别注意，如在高可用的OLTP环境中，不要盲目地把OLAP的技术拿过来用。
如分区技术，假设不是大范围地使用分区关键字，而采用其它的字段作为where条件，那么，如果是本地索引，将不得不扫描多个索引，而性能变得更为低下。如果是全局索引，又失去分区的意义。
并行技术也是如此，一般在完成大型任务时才使用，如在实际生活中，翻译一本书，可以先安排多个人，每个人翻译不同的章节，这样可以提高翻译速度。如果只是翻译一页书，也去分配不同的人翻译不同的行，再组合起来，就没必要了，因为在分配工作的时间里，一个人或许早就翻译完了。
位图索引也是一样，如果用在OLTP环境中，很容易造成阻塞与死锁。但是，在OLAP环境中，可能会因为其特有的特性，提高OLAP的查询速度。MV也是基本一样，包括触发器等，在DML频繁的OLTP系统上，很容易成为瓶颈，甚至是Library Cache等待，而在OLAP环境上，则可能会因为使用恰当而提高查询速度。
对于OLAP系统，在内存上可优化的余地很小，增加CPU 处理速度和磁盘I/O 速度是最直接的提高数据库性能的方法，当然这也意味着系统成本的增加。
比如我们要对几亿条或者几十亿条数据进行聚合处理，这种海量的数据，全部放在内存中操作是很难的，同时也没有必要，因为这些数据快很少重用，缓存起来也没有实际意义，而且还会造成物理I/O相当大。 所以这种系统的瓶颈往往是磁盘I/O上面的。
对于OLAP系统，SQL 的优化非常重要，因为它的数据量很大，做全表扫描和索引对性能上来说差异是非常大的。
其他
Oracle 10g以前的版本建库过程中可供选择的模板有：
Data Warehouse （数据仓库）
General Purpose （通用目的、一般用途）
New Database
Transaction Processing （事务处理）
Oracle 11g的版本建库过程中可供选择的模板有：
一般用途或事务处理
定制数据库
数据仓库
个人对这些模板的理解为：
联机分析处理（OLAP,On-line Analytical Processing），数据量大，DML少。使用数据仓库模板
联机事务处理（OLTP,On-line Transaction Processing），数据量少，DML频繁，并行事务处理多，但是一般都很短。使用一般用途或事务处理模板。
决策支持系统（DDS，Decision support system)，典型的操作是全表扫描，长查询，长事务，但是一般事务的个数很少，往往是一个事务独占系统。
Apache Kylin logoOLAP 分析引擎 Apache Kylin
http://www.oschina.net/p/kylin-olap
Kylin 是一个开源的分布式的 OLAP 分析引擎，来自 eBay 公司开发，基于 Hadoop 提供 SQL 接口和 OLAP 接口，支持 TB 到 PB 级别的数据量。
Kylin 是：
-
超级快的 OLAP 引擎，具备可伸缩性
-
为 Hadoop 提供 ANSI-SQL 接口
-
交互式查询能力
-
MOLAP Cube
-
可与其他 BI 工具无缝集成，如 Tableau，而 Microstrategy 和 Excel 将很快推出
其他值得关注的特性包括：
-
作业管理和监控
-
压缩和编码的支持
-
Cube 的增量更新
-
Leverage HBase Coprocessor for query latency
-
Approximate Query Capability for distinct Count (HyperLogLog)
-
易用的 Web 管理、构建、监控和查询 Cube 的接口
-
Security capability to set ACL at Cube/Project Level
-
支持 LDAP 集成
运行环境要求：
Hadoop
-
Hadoop: 2.2.0.2.0.6.0-61 or above
-
Hive: 0.12.0.2.0.6.0-61 or above
-
HBase: 0.96.0.2.0.6.0-61-hadoop2
Tested with Hortornworks distribution (HDP2.1.3), not tested with others yet.
Kylin Server
-
Command hadoop, hive, hbase is workable on your hadoop cluster
-
JDK Runtime: JDK7 (OpenJDK or Oracle JDK)
-
Maven
-
Git
-
Tomcat
-
Mysql
Druid：一个用于大数据实时处理的开源分布式系统
http://www.infoq.com/cn/news/2015/04/druid-data/
Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，旨在快速处理大规模的数据，并能够实现快速查询和分析。尤其是当发生代码部署、机器故障以及其他产品系统遇到宕机等情况时，Druid仍能够保持100%正常运行。创建Druid的最初意图主要是为了解决查询延迟问题，当时试图使用Hadoop来实现交互式查询分析，但是很难满足实时分析的需要。而Druid提供了以交互方式访问数据的能力，并权衡了查询的灵活性和性能而采取了特殊的存储格式。
Druid功能介于PowerDrill和Dremel之间，它几乎实现了Dremel的所有功能，并且从PowerDrill吸收一些有趣的数据格式。Druid允许以类似Dremel和PowerDrill的方式进行单表查询，同时还增加了一些新特性，如为局部嵌套数据结构提供列式存储格式、为快速过滤做索引、实时摄取和查询、高容错的分布式体系架构等。从官方得知，Druid的具有以下主要特征：
- 为分析而设计——Druid是为OLAP工作流的探索性分析而构建，它支持各种过滤、聚合和查询等类；
- 快速的交互式查询——Druid的低延迟数据摄取架构允许事件在它们创建后毫秒内可被查询到；
- 高可用性——Druid的数据在系统更新时依然可用，规模的扩大和缩小都不会造成数据丢失；
- 可扩展——Druid已实现每天能够处理数十亿事件和TB级数据。
Druid应用最多的是类似于广告分析创业公司Metamarkets中的应用场景，如广告分析、互联网广告系统监控以及网络监控等。当业务中出现以下情况时，Druid是一个很好的技术方案选择：
- 需要交互式聚合和快速探究大量数据时；
- 需要实时查询分析时；
- 具有大量数据时，如每天数亿事件的新增、每天数10T数据的增加；
- 对数据尤其是大数据进行实时分析时；
- 需要一个高可用、高容错、高性能数据库时。
一个Druid集群有各种类型的节点（Node）组成，每个节点都可以很好的处理一些的事情，这些节点包括对非实时数据进行处理存储和查询的Historical节点、实时摄取数据、监听输入数据流的Realtime节、监控Historical节点的Coordinator节点、接收来自外部客户端的查询和将查询转发到Realtime和Historical节点的Broker节点、负责索引服务的Indexer节点。
查询操作中数据流和各个节点的关系如下图所示：
如下图是Druid集群的管理层架构，该图展示了相关节点和集群管理所依赖的其他组件（如负责服务发现的ZooKeeper集群）的关系：
Druid已基于Apache License 2.0协议开源，代码托管在GitHub，其当前最新稳定版本是0.7.1.1。当前，Druid已有63个代码贡献者和将近2000个关注。Druid的主要贡献者包括广告分析创业公司Metamarkets、电影流媒体网站Netflix、Yahoo等公司。Druid官方还对Druid同Shark、Vertica、Cassandra、Hadoop、Spark、Elasticsearch等在容错能力、灵活性、查询性能等方便进行了对比说明。更多关于Druid的信息，大家还可以参考官方提供的入门教程、白皮书、设计文档等。
end