現在SSD硬碟可以拿來跑資料庫嗎?

是io的存取問題嗎。

印象中有些是能精簡化資料庫,另一種是做資料庫的cache 把資料庫中比較需要io的部份丟到ram 中run
另一種是使用快取命中率的做法,也是可以少掉io的部份。

但後二項需要有ups 支援更好.

如果io指的是存取磁碟的部份,要外接介面卡,使用sas介面。
如果是指硬碟本身的存取效率,就改善raid架構,或是更換ssd。

印象中是如此 ^^
用SSD很猛不過企業的代價....


01主需要的是DB反應速度吧? 感覺資料多但是小

現在SSD還是在耐用度上跟有差,高耐用的有,但是很貴,家用的我想沒人敢擔這責任


空間還要上算未來成長,企業SSD目前仍是高價,急著踏進去應該很花錢......

如果有成本考量那SAS還是要好好考慮,不如弄個15K的SAS架構


像所言chin-4696443網友所言採用SSD快取架構,DB基礎架構跟SQL優化會更好


如果DB小也是有人丟在RAM裡面在跑的~~
chiang wrote:
我們一直受到I/O存...(恕刪)


有!!
不過通常是把部份須高速存取的Table移到SSD上,而不是全部!

另外oracle也可以alter table xxx cache
讓這個table已經被讀進cache的block不要那麼容易被age out

不過若要更高速的話(如即時扣款之類的或者是mediation device)
通常是會採用如TimesTen之類的In-memory DB
(平常直接將DB整個載入memory的一種高速資料庫,只有作checkpoint時才會將image寫回disk上的DB image file)
There is something more than you will ever see...
我想,DB server 是M01的最重要資產。M01可以受到大家這麼熱烈的參與,都是因為有一個不停止的DB server 在努力的提供線上服務。

從以上各位大大的建議,其實已經講了很多重點。
主要有三:
1. 調整 DB
2. 更換成SSD
3. 更換 disk array或增加更多硬碟櫃

個人經驗裡,有調整的過,有建index的DB跟沒調整過的,速度可以天差地遠的幾10倍。
但 M01 經營了這麼久,也許可以調的已經調的差不多,再調也改善不了多少?

更換企業級SSD是個好方法。(一般SSD就不要拿出來上陣了,我們還想要M01長命百歲阿)
但是每一顆都是天價。台灣的大企業超大流量的db server也沒有看過這麼闊氣的阿~(個人
接觸過某客戶,他們的DB server當時用的是 HDS 最高檔的 disk array, 已經是用錢買得到
的最快 disk array了,但是仍嫌不夠快)

最後怎辦?繼續增加更多硬碟櫃,把資料更分散才能解決。

chiang wrote:
我們一直受到I/O存...(恕刪)

我也想聽聽專家的見解!
a26233813 wrote:
Dear 我們...(恕刪)



Dear 您們的<公X>客戶
您可以問一下..大約在三年前左右..
因為內部工程師的操作不當,導致您說的那一座Storage 在幾秒鐘的時間全部損毀
操作的介面就是VMware vSphere 的vClient..

你可以問問當時的"大"主管,印象中是一位女性主管..姓李吧~
在損壞之後,當天晚上在廠商跟幾家原廠動員多少人,包括他們多少人晚上連夜加班
動員多少人.."重新"進入一家公司什麼系統都沒有的重建工程
Linux/Windows/Active Directory/Exchange/SharePoint/防毒系統
包括客X 電視的所有電腦重新加入Microsoft Directory Services..將所有人的Profile 搬到新的ProFile

操作不當跟SSD 有什麼關係!?
因為SSD 沒有救回的機會..當時客戶願意付百萬來修復~但只因為使用SSD..

建議在不了解客戶實際運用及使用方式前..不要提供任何建議

不管那家資料庫(SQL/DB2/Sybase/Oracle/mySQL)都有其調整的空間


我可以舉出數十例國內大型企業使用SSD RAID ,包括IBM V7000/EMC VNX 慘痛經驗
我非常認同SSD 的效能及企業的SSD應用,所以前面幾位大大說的方式..是同時考量安全性及備援方式
再來考量高可用性及平衡效能..


我救了不下N次....真的只能說..小心..再小心..架構調整/應用程式調整/系統調整/DB Tablet/Index 都要納入重新設計的範圍..不是換個硬體設備就能解決問題的
如果是超大型資料庫BIG DATA,可以試試用NO SQL,
存取效率非常好,但是程式能力要很強,
因為那已經不是用SQL語法就可以解決的SOLUTION了,也沒有SCHEMA
資料庫能不能用SSD? 當然能!
不過應該這麼說, 資料庫Server要用SSD, 不是只是把傳統硬碟換成SSD而已.
Server跟PC基本上是兩個世界了... 不是用PC的思維去想就可以的.

據說Google很早就改用SSD了, 因為到Google這種規模跟架構, 耗電問題比
可靠性問題大... 每天同樣要換一堆硬碟, 至少SSD可以省很多電下來.
當然前提是,這都是在規劃完整的架構, 任何硬碟壞掉都沒有影響的前提之下.

另外前陣子到我們公司介紹的AWS(Amazon Web Service)也說他們有一個
Storage是SSD, IOPS快到嚇死人, 當然也反映在價錢上....
與失敗為伍者,天天靠盃都是別人的錯。 與成功為伍者,天天跟失敗切磋直到不再出錯。
01的系統跑了這麼多年
我想該tune的SQL、該加的index大概也八九不離十了
至於DB的Schema ER relationship .... 這也不是三兩天能改的動的
小弟以為換DB或改Schema都不是現階段能做的事情
畢竟蔣大必須穿著衣服改衣服
Change太大只會造成更多問題而已

至於蔣大的問題
我覺得蔣大不妨先觀察Disk I/O的Queue length狀況再做決策
如果是Read Queue高 .....
最簡單有效的方式是加RAM
利用DBMS LRU演算法把常用data and Index cache進memory裡

如果是Write Queue高 .......
這時候要探討的是Disk Arrary的組成方式
對DB server來說 RIAD-5 (or 50/60) 的高速data fetch優點可以用大量Memory cahe來取代
但RAID-5的small write penalty只能靠RAID card的小小write cache處理 .... 這對01這種網站是不夠的
因此蔣大如果鈔票夠多
可以考慮用中大型SAN storage + 大量Disk stripping分散disk write loading
如果阮囊羞澀 (真是開玩笑)
可以優先考慮本機使用多組 RAID-1 or RAID-10來加速Disk write效率
說穿了就是分散loading一途(硬體如此,軟體亦然),別無他法
至於SSD .... 那只是RAID system下更高速的media選擇方案
架構搞對了,高速media才能發揮效益

另外對DB schema有個建議
如果圖形這種BLOB object也放在Table裡頭的話
建議將來改版可以優先把BLOB object切到另外的Table去
這個BLOB table再放到完全不同的Disk partition (tablespace / filegroup ..... whatever)
這樣子對文字型的data fetch performance有非常大的幫助


以一個大型論壇來講,scale up不是一個好方法,調整整體架構scale out才是長遠之計.
限制級
您即將進入之討論頁 需滿18歲 方可瀏覽。
根據「電腦網路內容分級處理辦法」修正條文第六條第三款規定,已於該限制級網頁,依台灣網站分級推廣基金會規定作標示。
評分
複製連結
請輸入您要前往的頁數(1 ~ 10)