數據庫SQL,NoSQL之小感悟

遇到1000萬數據表

最近遇到一個問題，就是單表數據過1000萬的存儲及查詢問題。舉個例子：1000萬的數據存在一個表中，字段4-5個樣子，平常 開發中不免要作過濾、排序、分頁。若是把這幾個放在一塊兒即要過濾又要排序，還要分頁那麼數據量大一些就會發現特別慢。

10多年前剛入行時就聽許多的人討論分頁，說什麼1000萬大表分頁存儲過程啥的。我以後一直工做中也沒怎麼遇到大數據量的開發工做，也真是慚愧啊，如今算是補補課吧。

1000萬數據分個頁吧

經常使用的數據庫產品對分頁都是有一些支持的，SQL語句確定是OK的，一樣的問題在於如何高效。由於分頁查詢最大的問題在於查詢越日後的數據就越慢，由於要掃描的數據多。好比要查詢第9999900-10000000以前的記錄，就得將前面的數據找起。

爲何會這樣呢？由於數據存在存儲介質裏，是一種數據結構的，計算機經過指令來查找想要的數據就要有一種算法，由於機器自己不知道你想要哪些數據。因此在數據寫入時的天然順序會在具體查找時變成麻煩。

換句話說，若是不在意時間長短，那麼分頁查詢其實也沒多大事，大不行等個幾十秒也能出來數據。但現實是這很難被接受。因此如今有一些方法來加快這個過程。

好比人們就想出一個方法，在分頁查詢前記錄一下最後那頁的記錄的ID，而後查詢時直接從這個ID日後找數據，這種方法就解決了上面說的掃描問題，利用數據庫的數據檢索功能大大提高性能。

但這種方法有弊端，畢竟這個ID須要有順序啊，所取的數據也要是排過序的。但這說明想要提高效率方法是有的。

索引

我也不知道爲何，一直以來就很害怕數據庫方面的開發，我心中索引一直是個很複雜的東西，因此工做許久也沒有好好去學習一下。最近正好親密接觸了一下，才發現這東西真是好東西，也沒有想象中的那麼可怕。

所謂索引其實就是對特定的數據進行一種排序，而後與實際的數據記錄做映射，這樣的好處就是掃描數據時能夠在一個有序的集合裏查找，那麼算法天然就簡單高效啦。在實際應用中也發現，經過索引查詢性能能夠大幅提高。

固然索引並無這麼簡單，在什麼字段上建索引頗有講究，要根據實際業務狀況來決定。這也就是爲何一些電商的網站不多會有全部字段都給排序的緣由，由於這種成本是很昂貴的，甚至不可實現。你們注意淘寶是否是隻給了特定的一些排序方式？

NoSQL

N多年前在NoSql開始流行時我就想學習來着，但多是本身太懶的緣由，直到今年我纔開始瞭解了NoSql。目前聽的最多的Mongodb，甚至還有Redis也稱爲Nosql，HBase之類的。它們有什麼特別呢？

我以爲Nosql最大的特色在於基於Key-value，這個特色的好處就是易於數據的擴展。傳統數據庫一旦遇到數據大了要麼就是分庫、分表，還有垂直，水平分的。可是NoSql自然解決這個問題，由於數據能夠經過算法進行橫向擴展。並且Nosql一般保存的數據結構也比較特別。另外Nosql一般是利用內存多於磁盤，這樣能夠大大提高讀寫效率吧。

在K-V的基礎上提供一些類SQL的功能，就變得很是好用了。好比Mongodb能夠實現過濾、排序、分頁等操做，這對於開發人員來講簡直神了，不用擔憂跨庫或者跨表查詢啦。

可是也有弊端，好比join操做可能就沒這麼好玩啦。

SQL+NoSQL

最近看到國內有個團隊在作一處TiDB的開源項目，是基於google的論文開發的一套數據庫，特色就是兼容mysql，同時又有nosql的高效和擴展性。這簡直更神了，我只能膜拜。只不過我連mongodb都還不會，因此這種好東西我暫時也沒有去了解。有空要學習學習吧。

結語

看起來複雜的東西其實道理不復雜，對，簡單的就是好的。