【有奖话题讨论】CPU核越多:数据库就跑得越快吗？（已公布获奖名单）

pastime_Wang · 发表于 2014-6-17 11:15

占位，更新

gzmt · 发表于 2014-6-17 11:15

处理器的核越多，数据库会跑得更快，但也是有限度的。

buptdream · 发表于 2014-6-17 11:52

好活动，支持

2009532140 · 发表于 2014-6-17 11:59

占楼，准备回答！

gzmt · 发表于 2014-6-17 12:04

本帖最后由 gzmt 于 2014-6-17 12:06 编辑

拐点主要会出现在数据库设计和CPU设计这两方面。

数据库设计方面主要涉及对CPU高速缓存以及内存的使用算法，但是我对神通数据库不怎么熟悉，就不多说了；

CPU设计方面，每个CPU内核共享使用高速缓存以及内存总线，这其中需要CPU厂商设计合理的算法。即便算法合理，当内核越多时，所有的内核都在通过相同的管道向存储器发出请求，这就像1个、2个、4个或8个人在同时说“我等着要这个东西”，一直等着回复。

shenzhen_sap · 发表于 2014-6-17 13:01

本帖最后由 shenzhen_sap 于 2014-6-17 13:02 编辑

	OLTP（聯機事務處理）	OLAP（聯机分析處理）
用戶方面	普通用戶，較低層的管理人員；通常有幾佰個或數以万，十万，百万，千万計的用戶	高級管理人員，決策人員；用戶數很少
功能方面	日常的交易操作	數據收集分析決策
數據庫設計	主要面向應用	面向不同的主題
數據方面	當前數據	歷史數據
系統訪問	讀和寫，通常幾條數據或上百條數據；讀寫頻繁（以秒計）；主要以標準的事務來完成	數以万條或百万，億條數據的讀取；通常按小時/日/周來讀數據；主要以複雜的查詢來完成
數據庫大小	以几百MB或GB為單位	以GB或TB為單位
主要應用	銀行交易，機票訂購	數據倉庫

OLTP強調數據庫內存的執行效率，而OLAP強調磁盤I/O的效率。
OLTP容易出現瓶頸的地方就是CPU和磁盤子系統，OLTP單個語句執行速度雖然很快，但操作次數非常多，消耗大量的CPU時間，造成負載過高。在OLTP中，磁盤採用單塊讀寫，但次數非常頻繁。OLTP常用的設計和優化可以使用CACHE技術和索引的設計。CACHE決定很多語句不需要從磁盤子系統獲得，索引則需要語句越簡單越好，儘量減少語句的複雜化，減少表關聯。批量更新時也要分批快速提交。由於OLTP中的SQL語句提交非常頻繁，盡可能地讓數據保存在內存中。減少物理I/O和SQL解析可以提高數據庫性能。
OLAP每條語句讀取的數據非常多，時間會非常長，所以需要考量的有磁盤子系統的吞吐量，通常吞吐量取決於磁盤個數，這時CACHE是沒有多大作用，所以應採用個數比較多的磁盤及較大的帶寬。

對OLTP增加CPU個數未必能達到想要的效果；而OLAP可以通過增加CPU處理速度和磁盤I/O速度。

所以數據庫不是單純通過增加CPU就可以解決性能上的問題，而要針對不同的應用，找出系統瓶頸進行優化。

-----------------------------------------------------------------------------------------------------------------------
吐cao下神通數據庫為何不叫神馬數據庫？

shenzhen_sap · 发表于 2014-6-17 13:04

gzmt 发表于 2014-6-17 11:15
处理器的核越多，数据库会跑得更快，但也是有限度的。

OLAP 系統這個方法可以。

shenzhen_sap · 发表于 2014-6-17 13:06

這個「神馬數據庫」的測試是針對什么系統呢？OLTP還是OLAP，看你的測試結果應該比較像OLTP。

gzmt · 发表于 2014-6-17 13:14

shenzhen_sap 发表于 2014-6-17 13:04
OLAP 系統這個方法可以。

一样会有问题，你没认真看我的回帖。

shenzhen_sap · 发表于 2014-6-17 13:16

gzmt 发表于 2014-6-17 13:14
一样会有问题，你没认真看我的回帖。

你占的樓太多。