三步，即可完成圖片伺服器的遷移。至此就可以使用海量、彈性、高可靠、高性價比的對象存儲產品了。

除此之外，在互聯通CDN服務中選擇需要加速的對象存儲Bucket作為源站，就可以對這些圖片進行加速了！

看描述，起碼應該是半結構化數據。

1. 假設不是大量join，一次不會跨太多文件查詢：

建議不用資料庫。簡要解釋方案的核心：

• 文件按照業務切分以下。比如，每月存一個文件。甚至每天。格式用parquet。參考開源庫：arrow；
• 讀入內存，可以考慮內存對象，類似python著名的庫，pandas。它支持所有sql的騷操作，還有sql很難優雅寫出來的查詢。

方案優點：簡單快速；易於維護。

方案缺點：如果要讀入內存的數據超過限制，會爆。

2. 懶人方案，PostgreSQL+DBA優化。mySQL是肯定撐不住1TB。Oracle/MSSQL/DB2之類估計也不會太考慮。

3. 如果性能還是不夠。可能要去看看noSQL/newSQL的資料庫。Spark/HIVE/HDFS估計有可能。還有TiDB、KUDU，這類偏OLAP的資料庫也可以試試。

簡單與「c的fegt 直接讀取文件快」似乎沒有實戰意義。因為還有很多取出來以後，如何處理的問題。這些是資料庫擅長的。自己做費時費力。

我們通常認為這是一個比較典型的數據優化問題。但是你這個要求並不太清楚。

還是簡單的分析一下怎麼做吧。

1. 明確自己的查詢是什麼樣的要求， 是單一條件查詢，還是多條件查詢。
2. 明確自己的返回數據是什麼樣的要求，是隻返回唯一數據，還是要返回多條數據。
3. 明確自己的查詢最低容忍時間。
4. 導入數據測試，並使用explain分析。
5. 優化資料庫伺服器配置
6. 再測試。

如果你這是簡單的關係型數據，並且索引簡單明瞭，能放到內存裏去，我可以明確的告訴你，沒有一個資料庫能做到比fseek/fread快。但是也不會慢太多。因為其它別的資料庫也差不多要調用原生的c方法。 如果你再考慮到硬碟的存儲情況，做到分文件存儲，那c肯定是最快的。

但是如果你這是一個相對複雜的查詢，就是另外一件事了。

首先，在現有的資料庫裏，我瞭解的Postgresql本身在處理關係型數據上，表現得相當不錯。只要你做一定的針對性優化， 表空間分區，表索引，資料庫內存，並發數量。 另外你這臺伺服器的CPU不能太差了。

另外可以考慮一下HBase，這東西的目標就是要處理大數據。雖然它的一般性能比Postgresql要差一些，但是在大數據的表現上要比Postgresql穩定。

不過一定要記得，調優是根據業務來的，同時要結合理論。

還有就是我最近正在研究Dgraph， 從它的設計上來講，這種數據，應該也有不錯的性能。

不過我沒試過，不好說。

取決於你數據的訪問頻率

給你數據分類，那些熱數據，每小時成千上萬次訪問的，使用內存資料庫。

冷一些的數據，存硬碟或者對象存儲都可以。

你如果只是想要快，那就無腦全存內存裡面。

首先看數據的類型，數據類型包括塊存儲、對象存儲、文件存儲。塊存儲包括鏡像文件、資料庫數據文件，對象存儲包括圖標，圖片等