﻿<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Alex的个人Blog &#187; Architecture</title>
	<atom:link href="http://www.gemini5201314.net/category/architecture/feed" rel="self" type="application/rss+xml" />
	<link>http://www.gemini5201314.net</link>
	<description>关注数据仓库,商业智能和八卦</description>
	<lastBuildDate>Mon, 28 Nov 2011 12:04:22 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Hadoop 和DBMS 的互补性</title>
		<link>http://www.gemini5201314.net/bi/hadoop-%e5%92%8cdbms-%e7%9a%84%e4%ba%92%e8%a1%a5%e6%80%a7.html</link>
		<comments>http://www.gemini5201314.net/bi/hadoop-%e5%92%8cdbms-%e7%9a%84%e4%ba%92%e8%a1%a5%e6%80%a7.html#comments</comments>
		<pubDate>Sun, 23 Oct 2011 12:54:11 +0000</pubDate>
		<dc:creator>Alex</dc:creator>
				<category><![CDATA[Architecture]]></category>
		<category><![CDATA[BI]]></category>
		<category><![CDATA[Hadoop]]></category>
		<category><![CDATA[hadoop]]></category>
		<category><![CDATA[mpp]]></category>

		<guid isPermaLink="false">http://www.gemini5201314.net/bi/hadoop-%e5%92%8cdbms-%e7%9a%84%e4%ba%92%e8%a1%a5%e6%80%a7.html</guid>
		<description><![CDATA[随着Microsoft 也加入Hadoop 阵营，Hadoop 已经完全变成了DBMS 的好朋友了 , 2年之前的SIGMOD组织提出的“A Comparison of Approaches to Large-Scale Data Analysis”引发了关于并行数据库和MapReduce模型的讨论， 双方唇枪舌剑之后发现两个系统根本就是各有所长, DBMS 目前有些处理好的领域和商业支持，Hadoop 也有自己的优势和使用案例.]]></description>
		<wfw:commentRss>http://www.gemini5201314.net/bi/hadoop-%e5%92%8cdbms-%e7%9a%84%e4%ba%92%e8%a1%a5%e6%80%a7.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>数据仓库技术中的MPP</title>
		<link>http://www.gemini5201314.net/bi/%e6%95%b0%e6%8d%ae%e4%bb%93%e5%ba%93%e6%8a%80%e6%9c%af%e4%b8%ad%e7%9a%84mpp.html</link>
		<comments>http://www.gemini5201314.net/bi/%e6%95%b0%e6%8d%ae%e4%bb%93%e5%ba%93%e6%8a%80%e6%9c%af%e4%b8%ad%e7%9a%84mpp.html#comments</comments>
		<pubDate>Sat, 15 Oct 2011 10:38:07 +0000</pubDate>
		<dc:creator>Alex</dc:creator>
				<category><![CDATA[Analytic Platform]]></category>
		<category><![CDATA[Architecture]]></category>
		<category><![CDATA[BI]]></category>
		<category><![CDATA[exadata]]></category>
		<category><![CDATA[mpp]]></category>
		<category><![CDATA[netezza]]></category>
		<category><![CDATA[teredata]]></category>

		<guid isPermaLink="false">http://www.gemini5201314.net/bi/%e6%95%b0%e6%8d%ae%e4%bb%93%e5%ba%93%e6%8a%80%e6%9c%af%e4%b8%ad%e7%9a%84mpp.html</guid>
		<description><![CDATA[数据仓库世界里面的massively parallel processing 大概定义： MPP 是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果. 首先MPP 必须消除手工切分数据的工作量. 这是MySQL 在互联网应用中的主要局限性 另外MPP 的切分必须在任何时候都是平均的 , 不然某些节点处理的时间就明显多于另外一些节点. 对于工作负载是不是要平均分布有同种和异种之分，同种就是所有节点在数据装载的时候都同时转载，异种就是可以指定部分节点专门用来装载数据(逻辑上的不是物理上) ， 而其他所有节点用来负责查询. Aster Data 和Greenplum 都属于这种. 两者之间并没有明显的优势科研，同种的工作负载情况下，需要软件提供商保证所有节点的负载是平衡的. 而异种的工作负载可以在你觉得数据装载很慢的情况下手工指定更多节点装载数据 . 区别其实就是自动化和手工控制，看个人喜好而已. 另外一个问题是查询如何被初始化的. 比如要查询销售最好的10件商品，每个节点都要先计算出自己的最好的10件商品，然后向上汇总，汇总的过程，肯定有些节点做的工作比其他节点要多. 上面只是一个简单的单表查询，如果是两个表的连接查询，可能还会涉及到节点之间计算的中间过程如何传递的问题. 是将大表和小表都平均分布，然后节点计算的时候将得到的结果汇总（可能要两次汇总），还是将大表平均分布，小表的数据传输给每个节点，这样汇总就只需要一次. （其中一个特例可以参考后面给出的Oracle Partition Wise Join) .&#160; 两种执行计划很难说谁好谁坏，数据量的大小可能会产生不同的影响. 有些特定的厂商专门对这种执行计划做过了优化的，比如EMC Greenplum 和 HP Vertica .&#160; 这其中涉及到很多取舍问题，比如数据分布模式，数据重新分布的成本，中间交换数据的网卡速度，储存介质读写的速度和数据量大小（计算过程一般都会用临时表储存中间过程）. 一般在设计MPP 数据仓库的时候都会有一个指导原则用来得到比较好的性能，比如数据如何分布，customer 一般按照hash 分布比较好，而sales_order&#160; 一般按照时间分布. 所以一般建议在选型做POC 的时候，针对你自己需要的典型查询模式和负载进行测试. 一般优化的时候会考虑如下问题： 查询如何初始化？ 是否有足够的节点用来处理查询？ 同样的，数据装载的时候是否有足够节点用来装载数据 数据装载如何影响查询的，一些列数据库数据装载的时候一般不适合处理查询. 数据该复制多少份？把常用的数据分布在更多的节点上显然会减少数据移动的影响 [...]]]></description>
		<wfw:commentRss>http://www.gemini5201314.net/bi/%e6%95%b0%e6%8d%ae%e4%bb%93%e5%ba%93%e6%8a%80%e6%9c%af%e4%b8%ad%e7%9a%84mpp.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>数据仓库工作负载分类</title>
		<link>http://www.gemini5201314.net/bi/%e6%95%b0%e6%8d%ae%e4%bb%93%e5%ba%93%e5%b7%a5%e4%bd%9c%e8%b4%9f%e8%bd%bd%e5%88%86%e7%b1%bb.html</link>
		<comments>http://www.gemini5201314.net/bi/%e6%95%b0%e6%8d%ae%e4%bb%93%e5%ba%93%e5%b7%a5%e4%bd%9c%e8%b4%9f%e8%bd%bd%e5%88%86%e7%b1%bb.html#comments</comments>
		<pubDate>Sat, 15 Oct 2011 04:13:23 +0000</pubDate>
		<dc:creator>Alex</dc:creator>
				<category><![CDATA[Analytic Platform]]></category>
		<category><![CDATA[Architecture]]></category>
		<category><![CDATA[BI]]></category>
		<category><![CDATA[workload]]></category>

		<guid isPermaLink="false">http://www.gemini5201314.net/bi/%e6%95%b0%e6%8d%ae%e4%bb%93%e5%ba%93%e5%b7%a5%e4%bd%9c%e8%b4%9f%e8%bd%bd%e5%88%86%e7%b1%bb.html</guid>
		<description><![CDATA[持续（准实时）类型 : 持续更新从OLTP 来的数据，包括刷新汇总和预计算的数据. 批量更新 : 在系统不忙的时候批量更新大量数据 支持报表和仪表盘的数据仓库 ： 使用常规的索引，物化视图，分区等优化手段 策略业务分析 : 只IT 的帮助下建立了通用的模型，但是业务人员自己需要交互式的分析改变和保存. 可能会产生非预测无法优化的情况. 即席查询的数据仓库 ： 用户以一种不可预知的方式查询任意数据. 传统的优化手段不可能预先覆盖所有情况. 面向分析的数据仓库 : 包括复杂的分析函数，排名，记分，预测，OLAP模拟，数据挖掘，文本挖掘等等，一般分析时间较长. 另外也有一种按数据仓库的使用案例分类的 EDW ： 最原始的理想状况的所有数据放一起的 Data Mart : 一般是部门级别的数据，管理起来方便，性能也更好 实时数据仓库 ： 需要实时更新的，尤其是对于操作型的一些报表和即席查询 历史数据仓库 :&#160; 历史数据，按时间归档，很少查，偶尔会有汇总 分析型OLTP 数据仓库 :&#160; 主要面向操作型的报表和仪表盘，大多是中小企业的 混合负载的 ： 白天可能有各种报表然后又实时的，晚上又是批量装载又是分析型的大量计算. &#160; 另外分析型的也有很多不好分的分类： high-volume simple processing online request processing internet request processing network [...]]]></description>
		<wfw:commentRss>http://www.gemini5201314.net/bi/%e6%95%b0%e6%8d%ae%e4%bb%93%e5%ba%93%e5%b7%a5%e4%bd%9c%e8%b4%9f%e8%bd%bd%e5%88%86%e7%b1%bb.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>eBay 使用mysql 进行Personalization</title>
		<link>http://www.gemini5201314.net/architecture/ebay-%e4%bd%bf%e7%94%a8mysql-%e8%bf%9b%e8%a1%8cpersonalization.html</link>
		<comments>http://www.gemini5201314.net/architecture/ebay-%e4%bd%bf%e7%94%a8mysql-%e8%bf%9b%e8%a1%8cpersonalization.html#comments</comments>
		<pubDate>Wed, 25 Mar 2009 08:23:43 +0000</pubDate>
		<dc:creator>Alex</dc:creator>
				<category><![CDATA[Architecture]]></category>

		<guid isPermaLink="false">http://www.gemini5201314.net/architecture/ebay-%e4%bd%bf%e7%94%a8mysql-%e8%bf%9b%e8%a1%8cpersonalization.html</guid>
		<description><![CDATA[其实这篇文章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 引擎的最优先考虑，不能使用嵌入式数据库和内存数据库主要就是不能无限扩展和容灾.为什么选定mysql memory 引擎还是做了灰常多的测试的(ebay自己做的patch):在一个50%/50% 读写环境的测试中，一个低端的SUN 4100 [...]]]></description>
		<wfw:commentRss>http://www.gemini5201314.net/architecture/ebay-%e4%bd%bf%e7%94%a8mysql-%e8%bf%9b%e8%a1%8cpersonalization.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>hyperic mysql scaling 案例学习</title>
		<link>http://www.gemini5201314.net/architecture/hyperic-mysql-scaling-%e6%a1%88%e4%be%8b%e5%ad%a6%e4%b9%a0-3.html</link>
		<comments>http://www.gemini5201314.net/architecture/hyperic-mysql-scaling-%e6%a1%88%e4%be%8b%e5%ad%a6%e4%b9%a0-3.html#comments</comments>
		<pubDate>Tue, 24 Mar 2009 06:01:32 +0000</pubDate>
		<dc:creator>Alex</dc:creator>
				<category><![CDATA[Architecture]]></category>
		<category><![CDATA[data center]]></category>
		<category><![CDATA[hyperc]]></category>
		<category><![CDATA[mysql]]></category>
		<category><![CDATA[scale]]></category>

		<guid isPermaLink="false">http://www.gemini5201314.net/uncategorized/hyperic-mysql-scaling-%e6%a1%88%e4%be%8b%e5%ad%a6%e4%b9%a0-3.html</guid>
		<description><![CDATA[这是看了Sun 的communityone 上一篇介绍hyperic 在mysql 上scaling 的介绍写的笔记. hyperic 是一个在大型数据中心用作服务器管理和监控的软件，Hyperic HQ 提供中心服务器来收集多台主机的状态和性能指标，并且在一个中心界面上管理&#8230;&#8230; 其他的好处看后面的参考资料 Hyperic 默认是支持三种数据库mysql,oracle,postgresql. 后面会用到的几个hyperic 内的术语: Servers:&#160; 一台主机上一个特定的应用类型，比如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 技巧: 批量插入 INSERT INTO TABLE (a,b,c) values (0, [...]]]></description>
		<wfw:commentRss>http://www.gemini5201314.net/architecture/hyperic-mysql-scaling-%e6%a1%88%e4%be%8b%e5%ad%a6%e4%b9%a0-3.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

