随着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 优化技术成熟 |
阅读全文…
数据仓库世界里面的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 的时候，针对你自己需要的典型查询模式和负载进行测试. 一般优化的时候会考虑如下问题：
阅读全文…
其实这篇文章Fenng 早写了(连接), 08年四月Mysql 大会上的, 讲的是ebay 使用mysql 的memory 引擎做其用户个性化的解决方案.
ebay 的有趣数据:
1.1亿商品出售
每秒2千美元的交易量
2.7亿注册用户
20亿页面点击每天
6千台应用服务器(apache Geronimo)
300 个数据库服务器和700 数据库实例 (oracle居多)
9PB 的OLTP 数据
1千3百万代码(Java 的)
由于ebay 还在快速的向其v4 架构转变，无论是后台的基于eclipse 的快速开发，还是前台基于Flex 的用户体验. 除了9PB 的数据量比以前多很多之外，其他的数据比其巅峰时期还是下降了不少(amazon 在技术上真是低调呀).
大型互联网站点的用户个性化还是比较重要的, 而cookie 和 普通的数据库储存上还是有很多限制的，比如
cookie 只能保存4k的数据，(虽然你可以通过多个站点的多个cookie 来扩展)
每次传输都需要浪费不必要的数据，不管你在cookie 中需要的还是不需要的.
OLTP 数据库的读写和扩展性都有限，尤其面对ebay 的平均每个用户40k 的个性化数据, 每秒处理能力有限.
面对ebay 这样的数据量，每一个字节都是宝贵的,尤其是ebay 从v4 开始，有能力把多个http request 压缩, 每一个字节都能为他们节省宽带和服务器.
使用mysql memory 作为其个性化引擎之后,所面临的需求:
每天要40 亿次读写,（读写基本上个半50%/50%开)
要能够至少支持1万两千个java 进程发起的connection.
使用低端硬件 (ebay 也是有钱的主，全世界最贵的it 硬件基本都能在他们机房找到,最贵的软件也是毫不含糊)
水平和垂直的无线扩展.
低延时，快速响应和低网络消耗.
我猜最后一点是其选用mysql memory 引擎的最优先考虑，不能使用嵌入式数据库和内存数据库主要就是不能无限扩展和容灾.
阅读全文…
这是看了Sun 的communityone 上一篇介绍hyperic 在mysql 上scaling 的介绍写的笔记.
hyperic 是一个在大型数据中心用作服务器管理和监控的软件，Hyperic HQ 提供中心服务器来收集多台主机的状态和性能指标，并且在一个中心界面上管理…… 其他的好处看后面的参考资料
Hyperic 默认是支持三种数据库mysql,oracle,postgresql.
后面会用到的几个hyperic 内的术语:
Servers: 一台主机上一个特定的应用类型，比如mysql 服务，jboss 服务.
Services: 对应一个服务里面具体的某一个类型,比如mysql 里面的cpu 消耗,内存消耗,每个表的磁盘消耗.
Metrics: 每一个Services 一个时间点收集上来的数据,比如10：40 cpu 的消耗是60%.
Metrics data points(数据点): 一个时间点的某一个services 的具体数值, 比如上面的60%.
一种标准中等规模的度量数据:
远程管理300台主机，2100 Servers,21000 Services , 46万metric, 每分钟收集2万metric (平均值), 每天就是2千8百万数据点 (这个数据比较保守,性能收集间隔可以大一些.所以实际支持主机还可以多很多)
Hyperic Mysql 版本Scaling 技巧: 阅读全文…