传统的行数据库使用的基本都是数据字典算法(Data Dictionary) 算法，或者叫标记化(tokenization)算法, 将Block 里面经常出现的相同值写在Block的头部，在实际储存值的地方用1,2,3,A,B 这种符号代替.这种算法将不同的列放在一起，所以出现相同值的概率非常低. 而行式数据库在每一列分开储存，可以针对每一列的特征使用不同的算法. 这篇文章就是介绍列数据库常用的压缩算法.
最早的列式数据库Sybase IQ 使用的是一种Decomposed 模型, 简单的将每一列分开，然后用rowid 来标记每一行的位置. 如下所示
| age |
rowid |
|
region |
|
|
customer |
|
|
| 18 |
1 |
|
region1 |
1 |
|
customer1 |
1 |
|
| 19 |
2 |
|
region1 |
2 |
|
customer6 |
2 |
|
| 29 |
3 |
|
region1 |
3 |
|
customer109 |
3 |
|
| 29 |
4 |
|
region6 |
4 |
|
customer28 |
4 |
|
| 31 |
5 |
|
region2 |
5 |
|
customer15 |
5 |
|
| 32 |
6 |
|
region6 |
6 |
|
customer16 |
6 |
|
| 18 |
7 |
|
region1 |
7 |
|
customer88 |
7 |
|
| 18 |
8 |
|
region3 |
8 |
|
customer27 |
8 |
|
后来的列式数据库基本上都不用rowid 来标记每一列的位置, 并且对于每一个Block 的数据一定是先计算那一列具有最高选择性（唯一值最少），然后依次以选择性来排序从而可以不使用rowid 标记行的位置.
而由于排序之后相同的值在一起的机会更大，所以压缩率也就比普通的简单列储存(也即上面介绍的Decompose模型) 的压缩率大很多倍.
阅读全文…
最早的商业列式数据库是在1995年发布的Sybase IQ , 但是一直到1999年左右才慢慢稳定到能够投入生产环境. 现在的大多数分析型数据库都是在2003-2005年从Postgresql 分支出来的. 其中尤其是Vertica 为代表的列数据库已经在大规模数据仓库环境中证明其特别为数据仓库环境设计的思路在一些领域具有竞争优势. 这篇文章解释介绍列式数据库的几大特点.
- 高效的储存空间利用率 传统的行式数据库由于每个列的长度不一，为了预防更新的时候不至于出现一行数据跳到另一个block 上去, 所以往往会预留一些空间. 而面向列的数据库由于一开始就完全为分析而存在，不需要考虑少量的更新问题，所以数据完全是密集储存的.
行式数据库为了表明行的id 往往会有一个伪列rowid 的存在. 列式数据库一般不会保存rowid.
列式数据库由于其针对不同列的数据特征而发明的不同算法使其往往有比行式数据库高的多的压缩率，普通的行式数据库一般压缩率在3：1 到5：1 左右，而列式数据库的压缩率一般在8：1到30：1 左右. (InfoBright 在特别应用可以达到40:1 , Vertica 在特别应用可以达到60:1 , 一般是这么高的压缩率都是网络流量相关的)
列式数据库由于其特殊的IO 模型所以其数据执行引擎一般不需要索引来完成大量的数据过滤任务(Sybase IQ 除外) . 这又额外的减少了数据储存的空间消耗.
列式数据库不需要物化视图,行式数据库为了减少IO 一般会有两种物化视图，常用列的不聚合物化视图和聚合的物化视图. 列式数据库本身列是分散储存所以不需要第一种，而由于其他特性使其极为适合做普通聚合操作.(另外一种物化视图是不能实时刷新的，比如排名函数,不规则连接connect by 等等，这部分列数据库不包括.)
阅读全文…
随着Microsoft 也加入Hadoop 阵营，Hadoop 已经完全变成了DBMS 的好朋友了 , 2年之前的SIGMOD组织提出的“A Comparison of Approaches to Large-Scale Data Analysis”引发了关于并行数据库和MapReduce模型的讨论， 双方唇枪舌剑之后发现两个系统根本就是各有所长, DBMS 目前有些处理好的领域和商业支持，Hadoop 也有自己的优势和使用案例.
就如前一篇TDWI 所说的3个V 问题，新一代Hadoop MapReduce 主要解决的是数据容量和多种类型的数据（结构化，半结构化，非结构化）. 而传统的MPP DBMS 解决的主要还是速度，低延迟，实时性的问题.
| DBMS |
Hadoop |
| 低延迟，一般响应时间为秒 |
高延迟，一般响应时间最少为分钟 |
| 较高的吞吐(同一时间执行sql数) |
可以提交很多任务，但不一定快速执行. |
| 处理的数据量有限制（目前为P) |
可以处理大量的数据(从10p到1E） |
| 硬件有特殊需要，不能随时添加 |
硬件可随时添加，增加计算能力 |
| 假设机器是随时可用的，不对失败做处理 |
默认机器故障时正常的，可以容忍机器失效并用其它迅速机器替代 |
| 数据库模式过渡优化 |
对数据格式没有限制 |
| 数据满足完整性（外键） |
用户程序需要自己验证完整性 |
必须提前知道使用模式并进行优化
或者根据使用一段时间之后的情况进行特定优化 |
面对未知的使用模式，常规使用模式可以做一定程度的优化. |
| 需要添加额外的优化计算（索引，分区等） |
大部分情况不用额外优化 |
| CPU,内存，磁盘，网络利用率较为高效 |
资源利用率不算高效，人为优化需要较多技巧，目前没有DBMS 优化技术成熟 |
阅读全文…
前段时间TDWI 的一篇文章”big data analytics” 对现在流行的大数据量分析技术做了一些基础的背景说明，现状，机会和工具的分类，我觉得很有用，比很多单独的文章没有背景支撑讲的清楚很多. 下面摘录一些有用的信息
TDWI : Big Data Analytics
调查范围: IT 咨询，财务公司，软件和互联网的用户占了40%，其他各行业占60%.
（顺便说一句，国外大中型公司做信息化的时候都是有自己的懂行业的团队或者先找咨询公司的，不像国内的都是先找实施商).
背景介绍: 大数据量以前其实是个技术问题.现在由于硬件条件成熟和软件基础架构的变革已经可以更细的分析更多的数据并得到更多更准确更细节的信息, 从而为业务带来好处.
大数据分析的前身是高级分析，这在2009年就开始显露端倪，07年三大收购案结束后，大厂商已经具备一个通用的平台提供Gartner 提到的13条BI技术标准. 尤其是一些相关的技术开始成熟，
高级分析一般可以认为包括一系列的工具和技术，比如预测分析，数据挖掘，统计分析，复杂SQL,数据可视化 ,人工智能，自然语言处理，数据库支持的分析功能(In-Database Analysis ),，OLAP, MapReduce , 内存数据库，列数据库 , 等等.
另外一个更好的描述可能是“探索式发现”(discovery analytics or exploratory analytics) ， 数据如此之多，你在没看到数据之前根本不知道自己要找什么，或者你只能专注于几个最紧急的问题. 因此你需要使用大量数据，包括各种技术, 比如SQL , 数据挖掘，统计，快速分类，特征发现，数据可视化等等.
阅读全文…
数据仓库世界里面的massively parallel processing 大概定义：
MPP 是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果.
首先MPP 必须消除手工切分数据的工作量. 这是MySQL 在互联网应用中的主要局限性
另外MPP 的切分必须在任何时候都是平均的 , 不然某些节点处理的时间就明显多于另外一些节点.
对于工作负载是不是要平均分布有同种和异种之分，同种就是所有节点在数据装载的时候都同时转载，异种就是可以指定部分节点专门用来装载数据(逻辑上的不是物理上) ， 而其他所有节点用来负责查询. Aster Data 和Greenplum 都属于这种. 两者之间并没有明显的优势科研，同种的工作负载情况下，需要软件提供商保证所有节点的负载是平衡的. 而异种的工作负载可以在你觉得数据装载很慢的情况下手工指定更多节点装载数据 . 区别其实就是自动化和手工控制，看个人喜好而已.
另外一个问题是查询如何被初始化的. 比如要查询销售最好的10件商品，每个节点都要先计算出自己的最好的10件商品，然后向上汇总，汇总的过程，肯定有些节点做的工作比其他节点要多.
上面只是一个简单的单表查询，如果是两个表的连接查询，可能还会涉及到节点之间计算的中间过程如何传递的问题. 是将大表和小表都平均分布，然后节点计算的时候将得到的结果汇总（可能要两次汇总），还是将大表平均分布，小表的数据传输给每个节点，这样汇总就只需要一次. （其中一个特例可以参考后面给出的Oracle Partition Wise Join) . 两种执行计划很难说谁好谁坏，数据量的大小可能会产生不同的影响. 有些特定的厂商专门对这种执行计划做过了优化的，比如EMC Greenplum 和 HP Vertica . 这其中涉及到很多取舍问题，比如数据分布模式，数据重新分布的成本，中间交换数据的网卡速度，储存介质读写的速度和数据量大小（计算过程一般都会用临时表储存中间过程）.
一般在设计MPP 数据仓库的时候都会有一个指导原则用来得到比较好的性能，比如数据如何分布，customer 一般按照hash 分布比较好，而sales_order 一般按照时间分布.
所以一般建议在选型做POC 的时候，针对你自己需要的典型查询模式和负载进行测试. 一般优化的时候会考虑如下问题：
阅读全文…
今年10月Oracle Openworld 大会Larry 大爷一上来就是宣布新的整体数据仓库解决方案Exalytics , 新配置可谓豪华：
- 40 个CPU 的整体配置
- 1TB 内存
- 最新版 OBIEE 11G 做前端展现
- TimeTen 内存数据库
- Essbase 做OLAP Server
这个都拿来和全年12月底SAP 发布的HANA 配置做对比，两个都是BI 整体的一体机配置
- 硬件合作伙伴HP , DELL 等5家
- 内存数据库
- BO 4.0
- Sybase IQ 的集群
如果两个硬要做对比的话，Oracle 的可能会有些优势
- Sybase IQ 的集群规模可以比Oracle RAC 大，但是效率不一定高, 虽然Oracle RAC 的硬伤仍然是不具备线性扩展. 但是他较量的级别不是Sybase IQ .
- SAP 的硬件合作伙伴太多，这种整体的解决方案本来就是面向的高端客户，HANA一共就不一定卖多少套出去，别人要是问哪家的硬件好，你怎么回答.
- Sybase 的所谓内存计算早就不是新鲜科技了，但是他的内存数据库基本是一个新品牌，而Oracle 收购的Timeten 早就有N 多客户和行业经验了，打起广告来知名度都比较高
- OBIEE 和 BO 对比，OBIEE 也略占优势，很多第三方独立的调查机构和it 网站都基本认为07 年三大收购之后，IBM 的Cognos 和 SAP 的 BO 创新不足，客户满意度没有明显提升， 而收购Hyperion 的Oracle 由于产品基本没有大的重叠， 创新相对来说比这两个好很多.
阅读全文…
最近看到国外很多BI 公司都推出了自己的云平台，国外的很多调研机构基本都达成共识，BI 几大趋势之一的BI 云也算是真正进入普及阶段了. 有些国外的概念趋势也许对于国外是非常适合的，但是到了国内可能就有很大的变数.比如如下几个BI 的趋势
- 云
- 开源
- 移动
- 社交
- 列式分析型数据库
- 内存BI
- Big Data 与Hadoop
开源的BI 厂商国内应该是没有的，国外基本就两个Jaspersoft 和Pentaho , 这些年Jaspersoft 的发展好像比Pentaho 好那么一点,可能跟Pentaho 产品线太长，技术资金跟不上有很大关系，Jaspersoft 专注的技术少一些，营收也比Pentaho 强一点. 国内的话好像Pentaho 还有有些人讨论的，不过不知道是不是都是用的开源版，不用商业支持的.
移动的话不好说，国外移动的BI应用最主要还是智能手机的普及，毕竟工资水平不一样，而主要应用分社交和商务上的，社交没什么好说，商务上的话主要是改变以往信息流的传递方式，让任何人都能在任何时间跟别人分享信息. 另外一个是在不方便使用电脑的地方.比如某人在客户现场看到某个分析，想要评论或者添加数据之类的.
国内的话可能有些公司（金融，电信) 这种有钱的主像是给领导看数这种东西才会对这感兴趣.
社交 , 国外提到BI 的社交应用的主要原因其实还是他有应用，不是虚的东西，你像Facebook , Linkedin 这种平台公司在上面，你的客户在上面，你的客户的员工也在上面，你可以打广告，搞调查，在线营销，CRM , 这些东西如果做成分析都能实实在在的支持你的决定的, 国内的社交renren, kaixin, qq 算了吧，都是娱乐的. 而且数据也不是随便开放给所有人用的. 没应用你扯BI 干嘛.
列式分析型数据库，内存BI，Big Data 与Hadoop 国外和国内还算都有一点跟技术靠谱的，不过发展程度也是大不一样.不一一讨论了.
今天主要想说说国外的BI 云和国内的云的一些想法. 国外的云其实还是实实在在的有应用，有行业背景需求，有钱，所以他们的云都能落地，国内的则。。。。大家懂的.
国外云分几种
- 虚拟主机
- 虚拟主机+平台
- 平台服务提供商
- 计算平台
虚拟主机最开始大概就是dreamhost , bigdaddy 这种一开始用来建站的基本工具, 一般提供固定的编程语言(php ,asp 很少java) ,主要都是一些小的个人站点，个人博客，小公司的公司主页，小论坛或者聊天室这种, 后来随着虚拟化技术的成熟和服务器越来越便宜, 一般都是用的虚拟化的主机, 你可以自己装软件，配置东西，装数据库，选随意的编程语言. 这种公司像是Linode 一般叫VPS Hosting. 从小到大的应用都有
阅读全文…