【原】StreamInsight 浅入浅出（一）—— 基本概念

最近才小小研究了下 StreamInsight 这一新鲜玩意儿，发现其中很多理念和之前接触的针对数据行的数据库操作有很大不同，鉴于相关资料实在不多，中文的更少（MSDN上的根本惨不忍读），摸索了半天也只能算是刚刚入门，写此系列文章和大家探讨。

简介

StreamInsight 是 SQL Server 2008 R2 中的新模块，它提供了复杂事件处理（CEP, Complex Event Processing）的功能。

传统的数据库针对的是数据行操作，所有信息先被实体化存储在硬盘中，然后被取出，再进行一系列的计算。而CEP则针对的是事件流的操作，事件流从入口通过适配器进入，然后经过CEP服务器中的一系列查询逻辑的处理，最终通过输出适配器分发到各个目标上。

你可以认为在处理时所有事件以及事件上承载的数据被暂时保存在内存中了，但它们在被处理时一般是不可见的，你能触碰到的只有输入、输出。也就是说当你把一堆事件流丢给StreamInsight之后，除了在输出端乖乖等待从中流出来的经过处理的事件流外，你不能在中间某个过程就单独拎出来一条事件看看它变成什么样子了。

此外，由于输入适配器、输出适配器以及CEP服务器都在异步运行，你也无法确定某一条事件在某一时刻到底处于上图的哪一个模块中，所以传统的针对程序行的调试方法用在基于StreamInsight的程序上也有些水土不服，好在StreamInsight提供了很好的Debugger工具，可以从事件的角度来审查整个过程。

应用场景

可能看到这里还是不知道 StreamInsight 是干嘛的。下面就举个例子：

网站流量监控。如果我们要统计网站一天的总流量，用传统的数据库就可以了。但如果我们需要实时统计当前在线人数并保持更新，传统数据库就会显得笨拙缓慢了。因为如果我们先把访问信息一条一条存在数据库里，再用时间条件去筛选出当前时间段内的访问人数，一来一回会很没有效率。

而 StreamInsight 则提供了一种时间窗口的机制，把所有流入的事件按照时间窗口切片统计，并随着事件的流入不断推移窗口，始终统计最新窗口下的数据。这样就保证能够最快的得到当前在线人数的信息。

那么归纳起来，StreamInsight 应该应用于有下列特点的场景：

1. 注重结果的实时性。
2. 高吞吐的场景，并且不关注中间结果的存储。StreamInsight 据说是设计为适合高吞吐的场景的，而中间结果，如上所述，是无法得到的。
3. 可以被切片统计的。因为用 StreamInsight 计算得到的一般都是某一刻的数据，就像洪水时你切一刀，计算它的横截面。如果要统计一些总量，比如总流量之类的，用传统的数据库比较好。

安装与文档

StreamInsight 虽然是2008 R2上的新模块，但却是可以脱离SQL Server 2008 R2安装的，只要你有Key，不安装SQL Server 也可以安装 StreamInsight 的 Server 和 Client 端。

具体的安装介绍可以参照MSDN上的 http://msdn.microsoft.com/zh-cn/library/ee378749.aspx，很详细，比SQL Server 的安装简单很多。唯一需要注意的是在第七步，最好勾选“将当前用户添加到 StreamInsight 用户组”，否则无法利用 Connect 方法连接 StreamInsight 服务器端点。如果之后再添加的话，需要注销后再登录，麻烦一点。

而所有关于StreamInsight 的官方文档都在 http://msdn.microsoft.com/zh-cn/library/bb418434%28SQL.10%29.aspx，中文版比较糟烂，没有接触过的人乍一看会比较晕。

一个上手的好办法是下载 http://go.microsoft.com/fwlink/?LinkId=180356 上的示例，先有了感性认识，也许能比较快理解其中的原理。推荐其中的TrafficJoinQuery项目，比较简单，架构也比较清晰。

 

以上是本系列开篇，干货不多，但已经写的我满头大汗了，希望接下来的不会这么痛苦。各位看官，只要有一句“我看懂了”，对我就是莫大的安慰了。