去年，我們曾經使用了一批ssd的pc，用來做資料庫的伺服器，用來提高資料庫伺服器的io能力。但是從目前的使用情況來看，如果將ssd作為主儲存，存在一些問題：
首先，ssd的穩定性還不夠好，我們碰到了一些ssd盤損壞和ssd與機器不相容的情況發生。
第二，ssd的容量盤都比較小，考慮到穩定性的問題，如果做raid會進一步損失容量，價效比不高。
第三，ssd屬於nand型別的flash，寫操作不僅會產生「磨損」，而且隨著碎片的不斷增加，寫操作的效能會不斷下降。
目前看來，ssd並不太適合作為資料庫的主儲存，寫操作並不是ssd的特長，而且作為主儲存的代價過高，ssd更加適合作為記憶體和磁碟之間的一層cache，降低讀操作的延遲時間，我們將其稱為flash cache。oracle 11g r2中就提供了這樣的功能，oracle exadata v2配置了flash卡用來做flash cache，可以提供非常高的iops。對於mysql資料庫，google和facebook都提出了基於mysql資料庫的解決方案。
將ssd和flash卡配置在pc伺服器上，與普通sas或者sata磁碟混插，採用資料庫flash cache技術，可以達到乙個非常理想的效能，代價又不是特別高，我們也在考慮採用mysql的flash cache架構。但是，如果你採用大型的儲存裝置，比如emc和hds，儲存的cache實際上已經起到了乙個二級快取的作用，就沒有太多必要使用ssd或者flash卡了。
使用ssd還可以解決寫操作的響應延遲，比如oracle資料庫的redo，因為每次commit都必須物理寫入到磁碟上，所以將redo放在ssd上，可以提高寫的響應延遲，但是不必將資料檔案放在ssd上，因為他們並不是必須被寫入的。這裡要注意的是，ssd可能出現隨著大量的寫操作效能下降的情況。在我們的測試中，slc的寫能力比較穩定，而mlc的寫能力會出現下降的情況。
ssd一定有光明的未來，取代磁碟只是個時間問題，只是我們還需要等待技術更加成熟，**更加便宜。
關於可擴充套件的資料庫架構
資料庫分片(sharding)是最簡單實用的方案之一，將乙個集中式的資料庫拆分為很多小的資料庫，從而獲取資料庫橫向擴充套件的能力。但是，sharding也帶來一些問題：第一，應用可能需要進行大幅度的修改，以適應資料庫拆分的變化。我們通過資料庫**軟體來解決應用透明訪問的問題，比如amoeba，讓資料庫對應用透明，從而降低應用修改的複雜程度。第二，sharding帶來了一些應用上的限制，比如join，複雜查詢和事務，要想解決這個問題比較困難，但是我們可以選擇在適當的應用場景來使用，比如：在我們實際的應用場景中，絕大部分壓力來自於商品，訂單，交易等這類應用，其特點是：訪問簡單，資料量大，查詢壓力大。這類應用往往佔到系統85%以上的壓力，他們是非常適合做資料庫拆分的。還有些應用是不適合做拆分的，比如一些查詢複雜，事務要求高的應用，採用集中式資料庫是比較合適的。我們通過應用場景的不同，選擇不同的方案，既可以降低資料庫壓力，又可以降低應用的複雜程度。
還有一種常見的解決方案，在資料庫前端增加一層cache，比如記憶體資料庫，搜尋引擎，kv cache等等，屬於讀寫分離架構的一種，通過cache層有效緩解資料庫的讀壓力，提高整個系統的處理能力。在這種架構中，由cache層承載了大量的資料訪問，而資料庫則退化為乙個單純的資料儲存。在我們的系統架構中，就大量使用了memcache作為資料庫的外部cache，**也開發了自己的分布式kv cache(tair)。
作為dba來說，我們也常常使用資料本身的功能去解決問題，比如partition功能，但是它依然受限於單個database的處理能力，如果我們預期到單一資料庫可能產生效能瓶頸時，就需要考慮借助一些應用架構去解決問題，而不是總是侷限在資料庫本身的功能上。
事實上，解決方案都不是孤立存在的，這幾種方案經常混合在一起使用，比如facebook的架構中，就是利用mysql資料庫和memcache，通過sharding和讀寫分離等架構，從而使整個**具備非常高的效能和擴充套件能力。我們在實際解決問題時，也是如此，從資料庫本身的優化，資料庫內做分割槽，資料庫拆分，利用memcache作讀寫分離，多資料庫中心架構等等。
關於oracle和mysql
oracle更適合集中式資料庫架構，而mysql資料庫更適合分布式架構，在兩種架構並存的環境下，我們用mysql完全去替換oracle是不現實的。
從公司戰略的角度出發，逐步降低對oracle的依賴，這是乙個大的方向和目標，但並不意味著我們需要把所有的應用都遷移到mysql資料庫上，從純技術的角度分析，這並不合理。
我對mysql和oracle的想法是：分布式架構採用mysql資料庫，保留核心的oracle資料庫，通過資料庫拆分等手段，控制oracle資料庫的壓力和規模(license)。集中式架構和分布式架構共存，mysql和oracle共存，用最適合的技術解決問題。
關於小型機和儲存
雖然說近些年來pc伺服器的效能得到了很大的提高，甚至已經超過了小型機，但是小型機也不是一無是處，在穩定性，管理性和維護性等方面，小型機都要比pc伺服器高出不止乙個檔次。其缺點就是**昂貴，容易對硬體廠商產生依賴。
長遠來看，我們要控制小型機使用的規模，但並不意味著要替換掉所有的小型機，對於核心應用的oracle資料庫，我認為小型機還是有價值的，起碼在可用性方面***。對於mysql資料庫，我們大量採用pc伺服器，配合資料庫拆分和高可用架構，可以充分利用單台pc伺服器的處理能力，又保證整個mysql資料庫集群的可用性。
oracle和mysql資料庫對於機器的選型也有差異，oracle選擇小型機或者比較高階的pc伺服器，比如四路intel 7500系列，最高可以配置四路六核或八核cpu，在效能上已經超過了我們使用的ibm小型機。mysql則選擇處理能力與io能力均衡的伺服器，通常會配置比較多的本地磁碟，比如雙路intel 5500或者5600系列，本地配置12-16塊磁碟，甚至配置ssd或者flash卡。
對資料庫而言，儲存裝置非常重要，通常情況下，oracle資料庫會選擇中高階的儲存裝置，而mysql只配置pc伺服器上本地磁碟或者低端的磁碟擴充套件櫃。因為oracle的高可用策略通常都要基於共享的儲存裝置實現(比如rac，veritas vcs等)，所以san儲存幾乎是必須的選擇，而mysql的高可用策略是基於複製的，並不需要共享的儲存裝置。(當然，oracle也有data guard的方式，但是dg的切換過程複雜，需要人工干預，作為高可用策略並不適合，更多是作為一種容災和備份的機制)。
總的來說，硬體的選擇與資料庫本身的特性和應用架構有密切關係。從對主機的資源利用率上看，oracle可以充分利用機器的計算能力，而mysql對smp架構的支援比oracle差很多，單台mysql資料庫可能無法完全利用主機的處理能力，所以mysql主機配置過多的cpu也是一種資源浪費。
關於「去i/o/e」的策略(分別代表ibm，oracle，emc)，我個人的觀點是「合理使用」，而不是為了去而去。不管是資料庫的選擇還是硬體的選擇，我們的目標應該是不依賴於某個廠商，掌握主動權和話語權，這才是最重要的。
關於nosql和database
nosql現在非常火，我也寫了一些雞毛蒜皮的文章介紹nosql，nosql的出現並不是為了替代database，而是在某些特定的領域內解決問題，所以每個nosql產品都有其鮮明的特點，相比之下，database經過這麼多年的發展，已經發展成為非常成熟的商業產品，而nosql現在大部分還處於成長的階段。
nosql產品的優勢在於：擴充套件性，靈活的資料模型(非關係型)，大規模資料處理等方面，database的優勢在於：通用解決方案，成熟度，運維成本，使用成本等方面。我始終認為他們之間不是替代的關係，而是互補的關係，未來在alibaba的使用場景中，database應該還是首選的資料庫處理和儲存方案，但是在大規模的資料處理和資料倉儲計算方面，nosql應該可以找到大量的應用場景。
現在我們做技術方案時，往往面臨很多選擇，但是選擇太多未必是件好事，我們在選擇的過程中往往會加入個人的喜好，比如對某個技術的喜好和掌握程度，甚至為了證明某些能力，而選擇一些並不熟悉的技術，雖然它非常先進，但可能並不適用。每種技術都有其存在的合理性，但是引入過多技術必然增加成本和風險，比如facebook，他們利用mysql和memcache就解決了絕大部分的問題，而很火的cassandra，在facebook只是很小的乙個應用而已。相比較而言，我們使用的技術要多得多，我建議在選擇nosql和database產品時，選擇簡單和成熟的技術方案，後期開發和運維成本都是需要考慮的。
關於dba
dba不應該僅僅侷限於某個資料庫產品，而應該更全面的了解開發架構方面的知識，甚至需要具備開發能力。
dba的價值不僅僅在於維護資料庫本身，而應該在資料儲存方案的選擇上做出最專業的判斷，這是dba最大的價值所在。
現在，我們就在幹這些事。未來，就算不用oracle，我們也不會失業。
關於技術發展趨勢
我在公司五年多了，最初的資料庫就是採用pc伺服器，然後我們統一把他們整合到小型機上的集中式資料庫，把mysql換成oracle，而現在我們又要把小型機換成pc伺服器，把集中式oracle資料庫拆分成mysql資料庫集群，這不是簡單的輪迴，而是技術發展的結果。
雖然現在的發展趨勢是分布式架構，但是說不定過幾年又會出現超級計算機，從而又走向集中式的道路。我們要做的是能夠看到3年內技術發展的乙個方向，適應技術發展的潮流，並不斷調整目標，在解決問題的過程中不斷優化。問題和技術都是不斷發展的，試圖設計乙個完美的解決方案是不現實的，在乙個問題被解決後，一定會有新的問題冒出來。
選擇簡單但是不完美的技術解決問題，先做！然後再不斷優化。如果不去嘗試，我們永遠也不知道下一步要做什麼，總是停留在對技術方案本身優劣的討論上，是沒有意義的。
人總是在不斷反思，不斷否定自我的過程中進步的，技術發展也是一樣。
關於資料庫場景設計與架構
一 總起 文章 每每談到資料庫架構，我們在討論什麼 內容 二 實踐一 場景 單key業務，如何做到資料庫無限容量 文章 使用者中心，資料庫架構優化與實踐 內容 對於 業務複雜 併發量低 無需高可用 能接受一定延時 的後台業務 login name基因融入uid 思路 不能用login name生成u...
SQLite資料庫架構的儲存
select from sqlite master select from sqlite temp master 資料庫檔案的第1頁是表b 樹的根頁，它包含乙個特殊的表，名為 sqite master 如果是temp資料庫，則是 sqite temp master 該錶儲存了完整的資料庫模式。sqi...
檔案儲存與資料庫儲存
在大多數企業開發或web開發中，都會涉及資料的儲存和檢索。儲存資料有兩種基本的方法 儲存到普通檔案中 file system 或者儲存到資料庫 database 中。檔案儲存常見，並且簡單，作業系統提供的完善的api，所以在早期專案中都會使用檔案作儲存載體。但是隨著企業業務越來越複雜，訪問量也越來越...