主题：【原创】数据仓库软件的评测心得 -- 河蚌
家园 软硬件一体现在是大势所趋了 Teradata、DB2的BCU、Exadata、Netezza，GreenPlum。
数据仓库的CPU、IO配置均衡非常重要，现在一般不会单卖软件然后用户自己攒机器了、选操作系统。
家园 看来要从软件架构上考虑 数据仓库应用和一般的事务型数据库应用有很大的差别。OLTP和OLAP两种需求的区别不仅仅体现在底层支撑平台上，系统设计理念也是大不一样的。所以专用的数据仓库或分析类的系统不支持传统的SQL并不奇怪。毕竟SQL主要还是用在关系模型上比较得力。而关系模型在分析系统中并不见得是一种有效的架构。比如同样叫“表”用于分析的维度表更倾向于稀疏矩阵，而不是一般数据库的平衡树。
所谓数据仓库并不是仅仅作为仓库使用，其应用价值在于分析模型。因此我觉得你不应该将重点放在数据表操作上，而是应该考察其内核模型是否能满足你的分析需求。至于你提到的几个指标基本上都属于分析前的数据导入动作。某些特殊的导入需求不能用SQL实现实在不能算什么大问题。不能用SQL，用其他方式实现只要在性能上没问题，就不是问题。具体的解决方法让程序员考虑就可以了。
家园 我想你理解的数据仓库和我的有偏差 数据仓库系列软件，数据仓库存储工具（比如teredata)、多维数据库（比如Hyperion OLAP server)、前端信息展现工具（比如BO、Brio、Cognos)、数据仓库ETL工具（比如DataStageXe、infomatic)。这些软件，各有各的用处，但是都是工具级的。
而你说的分析模型，我想这是属于应用级的东西，是应用产品里面带的，比如客户关系管理、绩效考核等等。虽然很多咨询专家喜欢将工具和应用混到一起去谈数据仓库，但是这确实是两个层面的东西。
我这里说的是数据仓库存储工具（如teredata、greenplum)的测试，也许是我了解不深，真不知道这些工具内部有什么分析模型（但如果有的话，我想他们的宣传里面应该也会说呀），而且似乎DB2、oracle之类的传统数据库也不带分析模型什么的吧。
一个数据仓库软件上千万的投资，也许美国的分析很发达，所以需要那些东西，但是中国的客户需要它的，首先是海量历史数据存储和检索功能，至于玄而又玄的一些东西，如果客户连相关的业务需求都没有，你拿来也没用。不要只从数据仓库技术人员的角度去考虑问题，要考虑的是客户的实际需要。什么分析模型，也许很值钱，但是客户用不上，所以它就不值一分钱，而检索和插入的效率（何况这也是数据仓库的基本性能要求），客户需要，这就是体现价值的地方。产品商去自说自话，孤芳自赏这没用，要的是去满足客户的需要。起码teredata，这个数据仓库就是在10年的折腾中，把自己变得越来越象传统数据库了。
而数据仓库是不是应该支持传统SQL，这个倒是仁者见仁，智者见智。毕竟现在的应用开发体系（比如WEB/JAVA）什么的，完全可以在一套系统中同时存取两个不同型数据库中的数据。但是，如果想用单一数据库做复杂的应用，那么数据仓库存储不能完全支持SQL，这个就很致命了。
家园 过去的那些小型机 有些好奇，过去的那些小型机，RS/6000 和现在的这些服务器比起来到底怎么样.
现在的，哪怕是windows服务器能够轻松上几十个GB的内存，硬盘SSD的也不贵了，如果不是特别的可靠性要求，几年前的这种小型机是不是已经没有什么优势了
- 复 过去的那些小型机
家园 还是不一样的 其实现在服务器、小、中型机的界限已经很不明白了，RS/6000一开始时就是被定义为服务器的，但是现在的RS/6000，从520到595，性能差别极大，可以说涵盖了从服务器到中型机（甚至可以说大型机）的领域，只是体系架构上保持一致，
它们和PC服务器来比，从CPU体系架构到IO能力差别很大的。不过低档的RS/6000和PC服务器的处理能力，相差确实已经不大了（当然价格也相差不大）。
小型机和PC服务器，差别主要还是在于并行处理能力，如果只是单跑一个任务，这个差别不大。但是，小机是用来做中心主机的，象一个省级的金融系统（再大规模的就得用ES9000了），要求同时支持并发上万个交易。这个再强的PC都是做不到的。
象内存和硬盘，现在这个已经不能作为衡量大、中、小机的指标。比如现在想给PC机配个1T的硬盘，16G的内存，根本不是什么问题，但是要真说处理能力，还真不一定比得上5年前出产的RS6000 520。
- 复 还是不一样的
家园 why? 主要卡在总线带宽和IO带宽？
- 复 why?
家园 不一样的东西挺多了吧。 PC和RS/6000在总线好象是完全不同的架构。
CPU也不一样，RS/6000用的是POWER芯片。
硬盘不一样，SCSI/SAS硬盘的速度好象比IDE/SATA要快不少，SSD就不太知道了。
这方面研究的不多。可以查一下专业资料吧。
家园 不过Teradata可是run在intel体系下的 当然人家互联可以用专用的BYNET，磁盘挂的是EMC的阵列。貌似exadata也用的是Xeon，效率就没人家Teradata高，感觉还是软件的体系结构起决定性因素？
家园 Teredata的硬件与数据仓库应用是相适应的 Teredata的性能有一半是依赖于PC集群，说是专用的硬件，机柜里面实际上就是一块块的PC主机板，再装上SUSE LINUX，然后就买出几千万去，要不然大家觉得它贵呢。
不过它这种架构与数据仓库的任务有很大关系。数据仓库的应用和OLTP不一样，OLTP要求完成实时更新，要求事务完整性，并发的任务之间有关联的，而一个任务之内，再分解最终都会需要有一个总控来做事务的完结，也就是说任务发起和结束都必须是集中式的。
而数据仓库则主要是查询任务，可以把一个任务分散到多台机器上，并不需要最终有一台机器来汇总，因此，数据仓库软件可以采用PC群技术，但是OLTP却仍然是要求一台机器，即使是双机，真正起作用的也只是一台机器。
PC机和小型机的区别就在于单机的并行处理能力上。在并发数量上，一台小型机可以支持上百到千个并发进程，而PC机在这方面的能力要远低于小型机。而在单任务的计算上，小型机并不比PC机强多少。
家园 Teradata性能好，说明他软件上还是有一套的 感觉他最牛的地方在于把数据均分到各个节点上了以后，能尽量减少节点间的通信开销。
我怎么觉得OLTP更适合分布式？更新数据量通常都不大，但需要集中控制事务的完整性？是不是更像master/slaves 的模式？
倒是数据仓库业务，如果join多了以后，免不了有跨节点的数据需要join，最后还得汇总到一个节点上做？
家园 将数据均分在各个节点， 并尽量减少节点间交互的极至理论，就是share-nothing架构。只是这种架构对于应用有很大的限制。
OLTP单个交易更改数据量都很少，但是关键的问题还是在事务里面，有多条SQL语句，这些SQL语句所影响的数据可能分布在各个区域里，而这些SQL语句之间又有上下文关系。在下一条SQL发过来之间，数据库也不会知道它会影响哪儿的数据，所以分布式是很难处理的。
而数据仓库应用，不存在多条SQL之间的事务关联性，而单条SQL语句，无论多复杂，都意味着数据库程序是可以预先解析它，知道它如何工作，就可以在各个机器间进行分配，即使是有交互，也将交互做到最小。所以数据仓库应用更适合分布式，而OLTP则很不适合。
我的理解，如果数据库不做UPDATE操作，而只有delete、insert和select ,那么模式会简化很多。
家园 这倒是。 送花成功。有效送花赞扬。恭喜：你意外获得 16 铢钱。1通宝=16铢
参数变化，作者，声望:1；铢钱:0。你，乐善:1；铢钱:15。本帖花:1
家园 看来我们是同行 我在国内TD干过四年，进公司的时候还叫NCR。Teradata一直倡导的一个理念就是adhoc，即灵活查询、即席查询或者随机查询。在国内实施DW仓库项目的时候，TD上很少建索引，因为无法预知用户提交的查询是什么样，所以没办法提前优化。
至于数据在各节点间的重新分布，在实际应用中是不可避免的。最常见的情况就是在两个table做join的时候，如果两个表都是按照同一个键值做的分布，那么性能最好，一个大join就变为多个节点上local的小join；如果分布是不一样的，一般情况下稍小的那个表就会按照其参与join的字段做重新分布，这样就有变成节点内部的小join了。
这个过程必然伴随着节点间数据的迁移，但是Teradata有一个特有的节点间互联技术BYNET。这是一个点对点的网络，不是和以太网一样共享带宽的，因此加入新节点后不会影响节点间数据传输的带宽。所以TD一直标榜的斜率为1的线性性能增长，依赖的2个绝活就是数据均匀分布+BYNET。
至于Update，数据仓库里是一定有的。举个例子，对于账户表，会那源系统给的增量数据去update仓库内昨天的表，以获取最新的状态。