結構化資料、非結構化資料與半結構化資料
文章的開始，聊一下結構化資料、非結構化資料與半結構化資料，因為資料特點的不同，將在技術上直接影響儲存引擎的選型。
首先是結構化資料，根據定義結構化資料指的是由二維表結構來邏輯表達和實現的資料，嚴格遵循資料格式與長度規範，也稱作為行資料，特點為：資料以行為單位，一行資料表示乙個實體的資訊，每一行資料的屬性是相同的。例如：
因此關係型資料庫完美契合結構化資料的特點，關係型資料庫也是關係型資料最主要的儲存與管理引擎。
介於結構化與非結構化資料之間的資料就是半結構化資料了，它是結構化資料的一種形式，雖然不符合二維邏輯這種資料模型結構，但是包含相關標記，用來分割語義元素以及對記錄和字段進行分層。常見的半結構化資料有xml和json，例如：
張三name>這種結構也被成為自描述的結構。18age>
12345phone>
person>
關係型資料庫的優點
因為行 + 列的二維表邏輯是非常貼近邏輯世界的乙個概念，關係模型相對網狀、層次等其他模型更加容易被理解
通用的sql語言使得操作關係型資料庫非常方便，支援join等複雜查詢，sql + 二維關係是關係型資料庫最無可比擬的優點，這種易用性非常貼近開發者
支援acid特性，可以維護資料之間的一致性，這是使用資料庫非常重要的乙個理由之一，例如同銀行轉賬，張三轉給李四100元錢，張三扣100元，李四加100元，而且必須同時成功或者同時失敗，否則就會造成使用者的資損
資料持久化到磁碟，沒有丟失資料風險，支援海量資料儲存
最常用的關係型資料庫產品mysql、oracle伺服器效能卓越，服務穩定，通常很少出現宕機異常
關係型資料庫的缺點
緊接著的，我們看一下關係型資料庫的缺點，也是比較明顯的。
資料按行儲存，即使只針對其中某一列進行運算，也會將整行資料從儲存裝置中讀入記憶體，導致io較高
為了提供豐富的查詢能力，通常熱點表都會有多個二級索引，一旦有了二級索引，資料的新增必然伴隨著所有二級索引的新增，資料的更新也必然伴隨著所有二級索引的更新，這不可避免地降低了關係型資料庫的讀寫能力，且索引越多讀寫能力越差。有機會的話可以看一下自己公司的資料庫，除了資料檔案不可避免地佔空間外，索引佔的空間其實也並不少
資料一致性是關係型資料庫的核心，但是同樣為了維護資料一致性的代價也是非常大的。我們都知道sql標準為事務定義了不同的隔離級別，從低到高依次是讀未提交、讀已提交、可重複度、序列化，事務隔離級別越低，可能出現的併發異常越多，但是通常而言能提供的併發能力越強。那麼為了保證事務一致性，資料庫就需要提供併發控制與故障恢復兩種技術，前者用於減少併發異常，後者可以在系統異常的時候保證事務與資料庫狀態不會被破壞。對於併發控制，其核心思想就是加鎖，無論是樂觀鎖還是悲觀鎖，只要提供的隔離級別越高，那麼讀寫效能必然越差
前文提過，隨著企業規模擴大，一種方式是對資料庫做分庫，做了分庫之後，資料遷移（1個庫的資料按照一定規則打到2個庫中）、跨庫join（訂單資料裡有使用者資料，兩條資料不在同乙個庫中）、分布式事務處理都是需要考慮的問題，尤其是分布式事務處理，業界當前都沒有特別好的解決方案
由於資料庫儲存的是結構化資料，因此表結構schema是固定的，擴充套件不方便，如果需要修改表結構，需要執行ddl（data definition language）語句修改，修改期間會導致鎖表，部分服務不可用
例如like "%中國真偉大%"，只能搜尋到"2023年中國真偉大，愛祖國"，無法搜尋到"中國真是太偉大了"這樣的文字，即不具備分詞能力，且like查詢在"%中國真偉大"這樣的搜尋條件下，無法命中索引，將會導致查詢效率大大降低
寫了這麼多，我的理解核心還是前三點，它反映出的乙個問題是關係型資料庫在高併發下
的能力是有瓶頸的，尤其是寫入/更新頻繁的情況下，出現瓶頸的結果就是資料庫cpu高、sql執行慢、客戶端報資料庫連線池不夠等錯誤，因此例如萬人秒殺這種場景，我們絕對不可能通過資料庫直接去扣減庫存。
可能有朋友說，資料庫在高併發下的能力有瓶頸，我公司有錢，加cpu、換固態硬碟、繼續買伺服器加資料庫做分庫不就好了，問題是這是一種價效比非常低的方式，花1000萬達到的效果，換其他方式可能100萬就達到了，不考慮人員、伺服器投入產出比的leader就是個不合格的leader，且關係型資料庫的方式，受限於它本身的特點，可能花了錢都未必能達到想要的效果。至於什麼是花100萬就能達到花1000萬效果的方式呢？可以繼續往下看，這就是我們要說的nosql。
像上文分析的，資料庫作為一種關係型資料的儲存引擎，儲存的是關係型資料，它有優點，同時也有明顯的缺點，因此通常在企業規模不斷擴大的情況下，不會一味指望通過增強資料庫的能力來解決資料儲存問題，而是會引入其他儲存，也就是我們說的nosql。
nosql的全稱為not only sql，泛指非關係型資料庫，是對關係型資料庫的一種補充，特別注意補充這兩個字，這意味著nosql與關係型資料庫並不是對立關係，二者各有優劣，取長補短，在合適的場景下選擇合適的儲存引擎才是正確的做法。
比較簡單的nosql就是快取：
針對那些讀遠多於寫的資料，引入一層快取，每次讀從快取中讀取，快取中讀取不到，再去資料庫中取，取完之後再寫入到快取，對資料做好失效機制通常就沒有大問題了。通常來說，快取是效能優化的第一選擇也是見效最明顯的方案。
但是，快取通常都是kv型儲存且容量有限（基於記憶體），無法解決所有問題，於是再進一步的優化，我們繼續引入其他nosql：
資料庫、快取與其他nosql並行工作，充分發揮每種nosql的特點。當然nosql在效能方面大大優於關係挺資料庫的同時，往往也伴隨著一些特性的缺失，比較常見的就是事務功能的缺失。
下面看一下常用的nosql及他們的代表產品，並對每種nosql的優缺點和適用場景做一下分析，便於熟悉每種nosql的特點，方便技術選型。
kv型nosql（代表----redis）
kv型nosql顧名思義就是以鍵值對形式儲存的非關係型資料庫，是最簡單、最容易理解也是大家最熟悉的一種nosql，因此比較快地帶過。redis、memcache是其中的代表，redis又是kv型nosql中應用最廣泛的nosql，kv型資料庫以redis為例，最大的優點我總結下來就兩點：
因此，kv型nosql最大的優點就是高效能，利用redis自帶的benchmark做基準測試，tps可達到10萬的級別，效能非常強勁。同樣的redis也有所有kv型nosql都有的比較明顯的缺點：
綜上所述，kv型nosql最合適的場景就是快取的場景：
例如根據使用者id查詢使用者資訊，每次根據使用者id去快取中查詢一把，查到資料直接返回，查不到去關係型資料庫裡面根據id查詢一把資料寫到快取中去。
webservice簡單學習
一 web service 的概念想要理解 web service 必須先理解什麼是 service 服務 傳統上，我們把計算機後台程式 daemon 提供的功能，稱為 服務 service 比如，讓乙個防毒軟體在後台執行，它會自動監控系統，那麼這種自動監控就是乙個 服務 通俗地說，服務 就是計算機...
Linq to Sql簡單學習
從年前一直在做乙個專案，所有沒有時間來看書學習，最近終於有點空閒時間了，就想認真學習下在專案中用到的linq to sql。在做專案的過程中覺得linq很是神奇，語法簡單 直觀，對於我這個sql語句不是特別精通的菜鳥來說幫助甚大，所以就抽時間來好好學習學習linq的精妙。今天學習的內容是where的...
XBanner簡單學習
支援無限輪播的控制項，可進行自定義功能。1.新增 gradle 依賴 compile com.xhb xbanner 1.0.0 2.在布局檔案中新增 xbanner 3.在 activity 或者 fragment 中配置 初始化 直接傳入檢視集合進行初始化 4.載入廣告可根據自己專案需要使用相應...