nosql電子商務

㈠ 如何實現NewSQL，NoSQL與OldSQL的混合部署

在大數據時代，「多種架構支持多類應用」成為資料庫行業應對大數據的基本思路，資料庫行業出現互為補充的三大陣營，適用於事務處理應用的OldSQL、適用於數據分析應用的NewSQL和適用於互聯網應用的NoSQL。但在一些復雜的應用場景中，單一資料庫架構都不能完全滿足應用場景對海量結構化和非結構化數據的存儲管理、復雜分析、關聯查詢、實時性處理和控制建設成本等多方面的需要，因此不同架構資料庫混合部署應用成為滿足復雜應用的必然選擇。不同架構資料庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個案例對不同架構資料庫的混合應用部署進行介紹。
OldSQL+NewSQL 在數據中心類應用中混合部署
採用OldSQL+NewSQL模式構建數據中心，在充分發揮OldSQL資料庫的事務處理能力的同時，藉助NewSQL在實時性、復雜分析、即席查詢等方面的獨特優勢，以及面對海量數據時較強的擴展能力，滿足數據中心對當前「熱」數據事務型處理和海量歷史「冷」數據分析兩方面的需求。OldSQL+NewSQL模式在數據中心類應用中的互補作用體現在，OldSQL彌補了NewSQL不適合事務處理的不足，NewSQL彌補了OldSQL在海量數據存儲能力和處理性能方面的缺陷。
商業銀行數據中心採用OldSQL+NewSQL混合部署方式搭建，OldSQL資料庫滿足各業務系統數據的歸檔備份和事務型應用，NewSQL MPP資料庫集群對即席查詢、多維分析等應用提供高性能支持，並且通過MPP集群架構實現應對海量數據存儲的擴展能力。

商業銀行數據中心存儲架構
與傳統的OldSQL模式相比，商業銀行數據中心採用OldSQL+NewSQL混合搭建模式，數據載入性能提升3倍以上，即席查詢和統計分析性能提升6倍以上。NewSQL MPP的高可擴展性能夠應對新的業務需求，可隨著數據量的增長採用集群方式構建存儲容量更大的數據中心。
OldSQL+NoSQL 在互聯網大數據應用中混合部署
在互聯網大數據應用中採用OldSQL+NoSQL混合模式，能夠很好的解決互聯網大數據應用對海量結構化和非結構化數據進行存儲和快速處理的需求。在諸如大型電子商務平台、大型SNS平台等互聯網大數據應用場景中，OldSQL在應用中負責高價值密度結構化數據的存儲和事務型處理，NoSQL在應用中負責存儲和處理海量非結構化的數據和低價值密度結構化數據。OldSQL+NoSQL模式在互聯網大數據應用中的互補作用體現在，OldSQL彌補了NoSQL在ACID特性和復雜關聯運算方面的不足，NoSQL彌補了OldSQL在海量數據存儲和非結構化數據處理方面的缺陷。
數據魔方是淘寶網的一款數據產品，主要提供行業數據分析、店鋪數據分析。淘寶數據產品在存儲層採用OldSQL+NoSQL混合模式，由基於MySQL的分布式關系型資料庫集群MyFOX和基於HBase的NoSQL存儲集群Prom組成。由於OldSQL強大的語義和關系表達能力，在應用中仍然占據著重要地位，目前存儲在MyFOX中的統計結果數據已經達到10TB，占據著數據魔方總數據量的95%以上。另一方面，NoSQL作為SQL的有益補充，解決了OldSQL資料庫無法解決的全屬性選擇器等問題。

淘寶海量數據產品技術架構
基於OldSQL+NoSQL混合架構的特點，數據魔方目前已經能夠提供壓縮前80TB的數據存儲空間，支持每天4000萬的查詢請求，平均響應時間在28毫秒，足以滿足未來一段時間內的業務增長需求。
NewSQL+NoSQL 在行業大數據應用中混合部署
行業大數據與互聯網大數據的區別在於行業大數據的價值密度更高，並且對結構化數據的實時處理、復雜的多表關聯分析、即席查詢、數據強一致性等都比互聯網大數據有更高的要求。行業大數據應用場景主要是分析類應用，如：電信、金融、政務、能源等行業的決策輔助、預測預警、統計分析、經營分析等。
在行業大數據應用中採用NewSQL+NoSQL混合模式，充分利用NewSQL在結構化數據分析處理方面的優勢，以及NoSQL在非結構數據處理方面的優勢，實現NewSQL與NoSQL的功能互補，解決行業大數據應用對高價值結構化數據的實時處理、復雜的多表關聯分析、即席查詢、數據強一致性等要求，以及對海量非結構化數據存儲和精確查詢的要求。在應用中，NewSQL承擔高價值密度結構化數據的存儲和分析處理工作，NoSQL承擔存儲和處理海量非結構化數據和不需要關聯分析、Ad-hoc查詢較少的低價值密度結構化數據的工作。
當前電信運營商在集中化BI系統建設過程中面臨著數據規模大、數據處理類型多等問題，並且需要應對大量的固定應用，以及占統計總數80%以上的突發性臨時統計(ad-hoc)需求。在集中化BI系統的建設中採用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復雜分析、即席查詢等方面處理性能的優勢，及NoSQL在非結構化數據處理和海量數據存儲方面的優勢，實現高效低成本。

集中化BI系統數據存儲架構
集中化BI系統按照數據類型和處理方式的不同，將結構化數據和非結構化數據分別存儲在不同的系統中：非結構化數據在Hadoop平台上存儲與處理;結構化、不需要關聯分析、Ad-hoc查詢較少的數據保存在NoSQL資料庫或Hadoop平台;結構化、需要關聯分析或經常ad-hoc查詢的數據，保存在NewSQL MPP資料庫中，短期高價值數據放在高性能平台，中長期放在低成本產品中。
結語
當前信息化應用的多樣性、復雜性，以及三種資料庫架構各自所具有的優勢和局限性，造成任何一種架構的資料庫都不能完全滿足應用需求，因此不同架構資料庫混合使用，從而彌補其他架構的不足成為必然選擇。根據應用場景採用不同架構資料庫進行組合搭配，充分發揮每種架構資料庫的特點和優勢，並且與其他架構資料庫形成互補，完全涵蓋應用需求，保證數據資源的最優化利用，將成為未來一段時期內信息化應用主要採用的解決方式。
目前在國內市場上，OldSQL主要為Oracle、IBM等國外資料庫廠商所壟斷，達夢、金倉等國產廠商仍處於追趕狀態;南大通用憑借國產新型資料庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強;NoSQL方面用戶則大多採用Hadoop開源方案。

㈡ newsql和nosql的區別和聯系

TiDB 是 PingCAP 公司設計的開源分布式 HTAP (Hybrid Transactional and Analytical Processing) 資料庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持無限的水平擴展，具備強一致性和高可用性。TiDB 的目標是為 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案。

TiDB 具備如下特性：

• 高度兼容 MySQL

  大多數情況下，無需修改代碼即可從 MySQL 輕松遷移至 TiDB，分庫分表後的 MySQL 集群亦可通過 TiDB 工具進行實時遷移。

• 水平彈性擴展

  通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕松應對高並發、海量數據場景。

• 分布式事務

  TiDB 100% 支持標準的 ACID 事務。

• 真正金融級高可用

  相比於傳統主從 (M-S) 復制方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復 (auto-failover)，無需人工介入。

• 一站式 HTAP 解決方案

  TiDB 作為典型的 OLTP 行存資料庫，同時兼具強大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解決方案，一份存儲同時處理 OLTP & OLAP，無需傳統繁瑣的 ETL 過程。

• 雲原生 SQL 資料庫

  TiDB 是為雲而設計的資料庫，支持公有雲、私有雲和混合雲，配合TiDB Operator 項目可實現自動化運維，使部署、配置和維護變得十分簡單。

TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更復雜的 OLAP 分析可以通過TiSpark 項目來完成。

TiDB 對業務沒有任何侵入性，能優雅地替換傳統的資料庫中間件、資料庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關注資料庫 Scale 的細節問題，專注於業務開發，極大地提升研發的生產力。

㈢ 你身邊的資料庫系統有哪些請列舉3到5個

1、MySQL

MySQL是一個快速的、多線程、多用戶和健壯的SQL資料庫伺服器。MySQL伺服器支持關鍵任務、重負載生產系統的使用，也可以將它嵌入到一個大配置(mass- deployed)的軟體中去。

2、SQL Server

SQL Server 提供了眾多的Web和電子商務功能，如對XML和Internet標準的豐富支持，通過Web對數據進行輕松安全的訪問，具有強大的、靈活的、基於Web的和安全的應用程序管理等。

3、Oracle

Oracle產品系列齊全，幾乎囊括所有應用領域，大型，完善，安全，可以支持多個實例同時運行，功能強。能在所有主流平台上運行。完全支持所有的工業標准。採用完全開放策略。可以使客戶選擇最適合的解決方案。對開發商全力支持。

(3)nosql電子商務擴展閱讀：

資料庫的發展現狀：

在資料庫的發展歷史上，資料庫先後經歷了層次資料庫、網狀資料庫和關系資料庫等各個階段的發展，資料庫技術在各個方面的快速的發展。

特別是關系型資料庫已經成為目前資料庫產品中最重要的一員，80年代以來， 幾乎所有的資料庫廠商新出的資料庫產品都支持關系型資料庫，即使一些非關系資料庫產品也幾乎都有支持關系資料庫的介面。這主要是傳統的關系型資料庫可以比較好的解決管理和存儲關系型數據的問題。

隨著雲計算的發展和大數據時代的到來，關系型資料庫越來越無法滿足需要，這主要是由於越來越多的半關系型和非關系型數據需要用資料庫進行存儲管理，以此同時，分布式技術等新技術的出現也對資料庫的技術提出了新的要求，於是越來越多的非關系型資料庫就開始出現；

這類資料庫與傳統的關系型資料庫在設計和數據結構有了很大的不同， 它們更強調資料庫數據的高並發讀寫和存儲大數據，這類資料庫一般被稱為NoSQL（Not only SQL）資料庫。 而傳統的關系型資料庫在一些傳統領域依然保持了強大的生命力。

㈣ 資料庫有哪些類型

資料庫有兩種類型，分別是關系型資料庫與非關系型資料庫。

資料庫，簡而言之可視為電子化的文件櫃——存儲電子文件的處所，用戶可以對文件中的數據進行新增、截取、更新、刪除等操作。

關系型資料庫主要有：

Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL等等。

非關系型資料庫主要有：

NoSql、Cloudant、MongoDb、redis、HBase等等。

(4)nosql電子商務擴展閱讀：

非關系型資料庫的優勢：

1、性能高：NOSQL是基於鍵值對的，可以想像成表中的主鍵和值的對應關系，而且不需要經過SQL層的解析，所以性能非常高。

2、可擴展性好：同樣也是因為基於鍵值對，數據之間沒有耦合性，所以非常容易水平擴展。

關系型資料庫的優勢：

1、可以復雜查詢：可以用SQL語句方便的在一個表以及多個表之間做非常復雜的數據查詢。

2、事務支持良好：使得對於安全性能很高的數據訪問要求得以實現。

㈤ 為什麼要用NoSQL資料庫管理系統

一、首先看看傳統關系型資料庫的瓶頸：

1. 無法應對每秒上萬次的讀寫請求，硬碟IO此時也將變為性能瓶頸

2. 表中存儲記錄數量有限，橫向可擴展能力有限，縱向數據可承受能力也是有限的，面對海量數據，勢必涉及到分庫分表，難以維護。大數據查詢SQL效率極低，數據量到達一定程度時，查詢時間會呈指數級別增長

3. 難以橫向擴展，無法簡單地通過增加硬體、服務節點來提高系統性能。對於需要24小時不間斷提供服務的網站來說，資料庫升級、擴展將是一件十分麻煩的事，往往需要停機維護，數據遷移，為了避免服務間斷，如果網站使用伺服器集群，則根據集群策略，需要相應的考慮主從一致性、集群擴展性等一系列問題

二、然後看看NoSQL資料庫的優點：

1. 海量數據下，讀寫性能優異

2. 數據模型靈活

3. 數據間無關系，易於擴展

三、NoSQL資料庫分類：

1，鍵值存儲資料庫。代表資料庫：Redis

適用場景：會話信息，用戶配置信息，購物車

2，列存儲資料庫

代表資料庫：BigTable，Cassandra，HBase

適用場景：事件記錄，內容管理，博客平台

不適合需要ACID事務的場合

3，文檔型資料庫

代表資料庫：MongoDB

適用場景：事件記錄，內容管理，博客平台，網站分析，實時分析，電子商務應用

4，圖資料庫：可以使用圖結構相關演算法，比如最短路徑定址

代表資料庫：Neo4j

適用場景：社交網路，推薦引擎，基於位置的服務

㈥ 數據分析和數據收集 需要什麼方法

一般聽到數據分析和數據可視化的比較多，數據收集聽到相對較少。數據收集一般指數據存儲在各業務系統中，或者手動錄入資料庫里。這里就要提到一個功能叫數據填報。數據填報功能是億信華辰新推出的一款產品，一站式數據分析平台—ABI中數據採集的一個特色功能。數據填報功能可對報表進行數據回填設置，對缺失的數據進行補錄，也可以製作全新的填報表單用於錄入數據，真正的實現了數據分析填報一體化。回填報表支持導入excel數據，讓大數據量填報不再是困擾，同時支持數據審核，確保數據正確性。
億信華辰一站式數據分析平台—ABI，是一款全能型產品，融合了數據源適配、ETL數據處理、數據建模、數據分析、數據填報、工作流、門戶、移動應用等核心功能。其中數據分析和數據可視化又是億信ABI的長處也是其核心功能。億信ABI擁有多種特色分析手段，除了中國式復雜報表、dashboard、大屏報表外，ABI還支持自助式分析，包括拖拽式多維分析、看板和看板集，業務用戶通過簡單拖拽即可隨心所欲的進行探索式自助分析。同時，類word即席報告、幻燈片報告，讓匯報展示更加出彩。億信ABI的數據可視化也是豐富多彩，其報表中內置了上百種可視化元素和圖形。不僅支持80多種統計圖，還囊括了世界、中國各省市的地圖及gis地圖，通過設計與搭配，可衍生出成千上萬種可視化效果。同時abi還支持動態炫酷的酷屏分析，獨特的3D全景視角，自由快捷製作各類互動式常規屏和大屏報表，將創意變為現實。

㈦ 搭建一個日點擊量百萬以上的 電子商務網站，它的硬體設備投資大概會是多少

百萬級訪問量網站的技術准備工作
當今從純網站技術上來說，因為開源模式的發展，現在建一個小網站已經很簡單也很便宜，所以很多人都把創業方向定位在互聯網應用。這些人里大多數不是很懂技術，或者不是那麼精通，而網站開發維護方面的知識又很分散，學習成本太高，所以這篇文章將這些知識點結合起來，系統的來說，一個從日幾千訪問的小小網站，到日訪問一兩百萬的小網站，中間可能會產生什麼問題，以及怎麼才能在一開始做足工作盡量避免這些問題。

你的網站因為努力經營，訪問量逐漸升高，在升高的過程中，問題也可能開始顯現了。因為帶寬的增加、硬體的擴展、人員的擴張所帶來的成本提高是顯而易見的，而還有相當大的一部分成本是因為代碼重構、架構重構，甚至底層開發語言更換引起的，最壞的情況就是數據丟失，所有努力付之一炬。這類成本支出大多數在一開始就可以避免，先打好基礎，往後可以省很多精力，少操很多心。

對於不同的初期投資成本，技術路線的選擇是不同的。這里假設網站剛剛只是一個構想，計劃第一年伺服器硬體帶寬投入5萬左右。對於這個資金額度，有很多種方案可選擇，例如租用虛擬主機、租用單獨伺服器，或者流行的私有雲，或者託管伺服器。前兩種選擇，網站發展到一定規模時需遷移，那時再重做規劃顯然影響更大。伺服器託管因為配置自主、能完全掌握控制權，所以有一定規模的網站基本都是這種模式。採用自己託管伺服器的網站，一開始要注意以下幾點——

一、開發語言
一般來說，技術人員（程序員）都是根據自己技術背景選擇自己最熟悉的語言，不過不可能永遠是一個人寫程序，所以在語言的選擇上還要是要費些心思。首先明確一點，無論用什麼語言，最終代碼質量是看管理，因此我們從前期開發成本分析。現在國內流行的適用於網站的語言，大概有java、php、.net、 python、ruby這五大陣營。python和ruby因為在國內流行的比較晚，現在人員還是相對難招一些。.net平台的人相對多，但是到後期需要解決性能問題時，對人員技能的要求比較高。剩餘的java、php用人可以說是最多的。java和php無法從語言層面做比較，但對於初期，應用幾乎都是靠前端支撐的網站來說，php入門簡單、編寫快速，優勢相對大一點。至於後端例如行為分析、銀行介面、非同步消息處理等，等真正需要時，就要根據不同業務需求來選擇不同語言了。

二、代碼版本管理
稍微有點規模的網站就需要使用代碼版本管理了。代碼版本管理兩點最大的好處，一是方便協同工作，二是有歷史記錄可查詢比較。代碼版本管理軟體有很多，vss/cvs/svn/hg等，目前國內都比較流行，其中svn的普及度還是很高的。

假設選了svn，那麼有幾點考慮。一是採用什麼樹結構。初期可能只有一條主幹，往後就需要建立分支，例如一條開發分支，一條上線分支，再往後，可能要每個小組一個分支。建議一開始人少時選擇兩條分支，開發和線上，每個功能本地測試無誤後提交到開發分支，最後統一測試，可以上線時合並到上線分支。如果每人都建自己的分支，合並時會浪費很大精力，對於幾乎每天都要修改幾次的WEB應用來說，所費時間太多。

向伺服器部署代碼，可以手工部署也可以自動部署。手工部署相對簡單，一般可直接在伺服器上svn update，或者找個新目錄svn checkout，再把web root給ln -s過去。應用越復雜，部署越復雜，沒有什麼統一標准，只是別再用ftp上傳那種形式，一是上傳時文件引用不一致錯誤率增加，二是很容易出現開發人員的版本跟線上版本不一致，導致本來想改個錯字結果變成回滾。如果有多台伺服器還是建議自動部署，更換代碼的機器從當前服務池中臨時撤出，更新完畢後再重新加入。

三、伺服器硬體
在各個機房裡，靠一台伺服器孤獨支撐的網站數不清，但如果資金稍微充足，建議至少三台的標准配置，分別用作web處理、資料庫、備份。web伺服器至少要8G內存，雙sata raid1，如果經濟稍微寬松，或靜態文件或圖片多，則15k sas raid10。資料庫至少16G內存，15k sas raid 10。備份伺服器最好跟資料庫伺服器同等配置。硬體可以上整套品牌，也可以兼容機，也可以半品牌半組裝，取決於經濟能力。當然，這是典型的搭配，有些類型應用的性能瓶頸首先出現在web上，那種情況就要單獨分析了。

web伺服器可以既跑程序又當內存緩存，資料庫伺服器則只跑主資料庫（假如是MySQL的話），備份伺服器所承擔就相對多一些，web配置、緩存配置、資料庫配置都要跟前兩台一致，這樣WEB和資料庫任意一台出問題，很容易就可以將備份伺服器切換過去臨時頂替，直到解決完問題。要注意，硬體是隨時可能壞掉的，特別是硬碟，所以寧可WEB伺服器跟資料庫伺服器放在一起，也一定不能省掉備份，備份一定要異機，並且有非同步，電力故障、誤操作都可能導致一台機器上的所有數據丟失。很多的開源備份方案可選擇，最簡單的就是rsync，寫crontab里，定時同步。備份和切換，建議多做測試，選最安全最適合業務的，並且盡可能異地備份。

四、機房
三種機房盡量不要選：聯通訪問特別慢的電信機房、電信訪問特別慢的聯通機房、電信聯通訪問特別慢的移動或鐵通機房。機房要盡可能多的實地參觀，多測試，找個網路質量好，管理嚴格的機房。機房可以說是非常重要，直接關繫到網站訪問速度，網站訪問速度直接關繫到用戶體驗，訪問速度很慢的網站，很難獲得用戶青睞。

五、架構
在大方向上，被熟知的架構是web負載均衡+資料庫主從+緩存+分布式存儲+隊列。在一開始，按照可擴展的原則設計和編程就可以。只是要多考慮緩存失效時的雪崩效應、主從同步的數據一致性和時間差、隊列的穩定性和失敗後的重試策略、文件存儲的效率和備份方式等等意外情況。緩存失效、資料庫復制中斷、隊列寫入錯誤、電源損壞，在實際運維中經常發生，如果不注意這些，出現問題時恢復期可能會超出預期很長時間。

六、伺服器軟體
操作系統Linux很流行。在沒有專業運維人員的情況下，應傾向於擇使用的人多、社區活躍、配置方便、升級方便的發行版，例如RH系列、 debian、ubuntu server等，硬體和操作系統要一起選擇，看是否有適合的驅動，如果確定用某種商業軟體或解決方案，也要提前知曉其對哪種操作系統支持最佳。web伺服器方面，apache、nginx、lighttpd三大系列中，apache佔有量還是最大，但是想把性能調教好還是需要很專業的，nginx和 lighttpd在不需要太多調整的情況下可以達到一個比較不錯的性能。無論選擇什麼軟體，除非改過這些軟體或你的程序真的不兼容新版本，否則盡量版本越新越好，版本新，意味著新特性增多、BUG減少、性能增加。一個典型的php網站，基本上大多數人都沒改過任何伺服器軟體源代碼，絕大多數情況是能平穩的升級到新版本的。類似於jdk5到 jdk6，python2到python3這類變動比較大的升級還是比較少見的。看看ChangeLog，看看升級說明，結合自己情況評估測試一下，越早升級越好，升級的越晚，所花費的成本越高。對於軟體包，盡量使用發行版內置的包管理工具，沒有特殊要求時不建議自己編譯，那樣對將來運維不利。

七、資料庫
幾乎所有操作最後都要落到資料庫身上，它又最難擴展（存儲也挺難）。資料庫常見的擴展方法有復制、分片，設計時要考慮到每種應用的數據如何復制、分片，當然這種考慮一般會推遲到技術設計時期。在初期進行資料庫結構設計時，要根據不同的業務類型和增長量預期來考慮是否要分庫、分區，並且盡量不要使用聯合查詢、不使用自增ID以方便分片。復制延時問題、主從資料庫數據一致性問題，可以自己寫或者用已有的運維工具進行檢測。

用存儲過程是比較難擴展的，這種情形多發生於傳統C/S，特別是OA系統轉換過來的開發人員。低成本網站不是一兩台小型機跑一個資料庫處理所有業務的模式，是機海作戰。方便水平擴展比那點預分析時間和網路傳輸流量要重要的多的多。

另外，現在流行一種概念叫NoSQL，可以理解為非傳統關系型資料庫。實際應用中，網站有著越來越多的密集寫操作、上億的簡單關系數據讀取、熱備等，這都不是傳統關系資料庫所擅長的，於是就產生了很多非關系型資料庫，比如Redis/TC&TT/MongoDB/Memcachedb等，在測試中，這些幾乎都達到了每秒至少一萬次的寫操作，內存型的甚至5萬以上。在設計時，可根據業務特點和性能要求來選擇是否使用這類資料庫。例如 MongoDB，幾句配置就可以組建一個復制+自動分片+failover的環境，文檔化的存儲也簡化了傳統設計庫結構再開發的模式。但是當你決定採用一項技術時，一定要真正了解其優劣，例如可能你所選擇的技術並不能支持你所需要的事務和數據一致性要求。

八、文件存儲
存儲的分布幾乎跟資料庫擴展一樣困難，不過只有百萬的PV的情況下，磁碟IO方面一般不會成大問題，一兩台採用SATA做條帶RAID的機器可以應付，反而是自己做非同步備份比較復雜，因為小文件多。如果只有一台機器做存儲，可以做簡單的優化，例如放最小縮略圖的分區和放中等縮略圖的分區，根據平均大小調整一下塊大小。存儲要規劃好目錄結構，否則文件增多後維護起來復雜，也不利於擴展。同時還要考慮將來擴容，例如採用LVM，或者把文件根據不同規則散列到不同機器。磁碟IO繁重的情況下更容易出現故障，所以要做好備份，若發現有盤壞掉，要馬上行動更換，很多人的硬碟都是壞了一塊之後，接二連三的壞下去。

為了將來圖片走cdn做准備，一開始最好就將圖片的域名分開，且不用主域名。因為很多網站都將cookie設置到了.domain.ltd，如果圖片也在這個域名下，很可能因為cookie而造成緩存失效，並且佔多餘流量，還可能因為瀏覽器並發線程限製造成訪問緩慢。

九、程序
一定硬體條件下，應用能承載多少訪問量，很大一部分也取決於程序如何寫。程序寫的不好，可能一萬的訪問都承載不了，寫的好，可能一兩台機器就能承擔幾百萬PV。越是復雜、數據實時性要求越高的應用，優化起來越難，但對普通網站有一個統一的思路，就是盡量向前端優化、減少資料庫操作、減少磁碟IO。向前端優化指的是，在不影響功能和體驗的情況下，能在瀏覽器執行的不要在服務端執行，能在緩存伺服器上直接返回的不要到應用伺服器，程序能直接取得的結果不要到外部取得，本機內能取得的數據不要到遠程取，內存能取到的不要到磁碟取，緩存中有的不要去資料庫查詢。減少資料庫操作指減少更新次數、緩存結果減少查詢次數、將資料庫執行的操作盡可能的讓你的程序完成（例如join查詢），減少磁碟IO指盡量不使用文件系統作為緩存、減少讀寫文件次數等。程序優化永遠要優化慢的部分，換語法是無法「優化」的。

然而編程時不應該把重點放在優化上，應該關注擴展性。當今的WEB應用，需求變化非常之快，適應多種需求的架構是不存在的，我們的擴展性就要把要點放在跟底層交互的架構上，例如持久化數據的存取規則、緩存的存取規則等，還有一些共用服務，例如用戶信息等。先把不變的部分做完善，剩下的部分就很容易將精力放在業務邏輯上面了。