在內存即硬盤的時代，在普通服務器就可擁有4核或者8核的多線程時代，隨着NOSQL數據庫的大規模應用，不僅要思考一個問題，顯然，NOSQL在很多方面還不能完全取代傳統的關係數據庫RDBMS，現有的基於關係數據庫的應用要移植到雲計算環境中，是改變程序適應NOSQL數據庫，還是改造現有的關係數據庫以適應雲計算環境？目前看來，前者似乎更加可行，而這裏思考的是後者！關係數據庫難以橫向擴展，主要的瓶頸在文件系統，數據庫的數據存儲在文件系統上，對數據庫表的修改，添加，刪除，都需要對文件系統進行操作，在關係數據庫興起的時候，很難想象關係數據庫會把同一個表的數據存在多個服務器上，目前關係數據庫的擴展主要是通過分表和分區等技術，而在雲計算領域，設想一種理想的情況，雲計算的文件系統是分佈式透明的N個節點的服務器，關係數據庫對文件系統的操作是通過分佈式的文件系統來進行的，一個表的數據存放按照記錄分佈在多個節點，查詢，join等所有數據庫的底層操作使用MapReduce進行任務的分配，這要比目前的分區和分表等技術對用戶來說更爲透明，而這和分表等技術原理上相同，只不過是數據庫底層提供了實現，對用戶來講沒有任何改變。
能不能實現不是這裏考慮的重點，重點是如果能夠實現將極大的減少傳統程序向雲計算領域遷移的成本，使用過Google App Engine的同學都知道，寫個App需要用特定的API，即使提供有傳統的JPA接口，也有不少功能不支持，現有的應用不經過大規模的修改是難以部署到GAE上的。
改造的難點有一部分取決於數據庫文件的保存方式，不少數據庫文件是單個文件，所有的表在一個文件，有的數據庫則是多個文件，每個表一個文件，個人感覺後一種數據庫保存方式改造起來更容易，可將數據庫的表按照記錄的索引到達一定限度分開保存在多個節點，查詢，刪除，修改行記錄的實現都要改變以適應多個節點，而插入恰恰是開銷最小，只需要找到最後一個節點就可，而查詢的功能可通過緩存行記錄到內存得到有效的改善！
改造的另外一個難點是需要一個能夠和這種操作相適應的分佈式的文件系統，而這種文件系統是可隨機訪問和修改的，以後再談關於這個文件系統的思考。
至於這樣的關係數據庫能不能實現，希望自己能做這方面的嘗試，已經選好了數據庫，改造方面的工作還是挺大的！