你沒有大資料

   今天在一個群裡，看到有人說：“國產資料庫都這麼強大了，把大資料的功能都實現了，大資料只需提供計算引擎就行。” 我隨後跟了一句：“ 我一直覺得大部分大資料場景，就是SQL沒寫好或者表設計問題導致的。有大資料場景的公司不多。 ” 隨後有幾個朋友覺得我說 的不錯。於是我就 覺得寫寫吧。

    什麼是大資料定義不管是4V還是5V，第一個要解決的是量級。 2000年左右一般沒人說大資料，因為谷歌是2003/2005和2006年發表三篇論文以後才有。 但是我們說個 常識 2000年時候中國人口有13億不到14億這是常識吧。 我剛畢業的時候做公安系統，經常看到公安人員因為需要在人口庫中，輸入姓名或者身份證號進行查詢。 我想全國人口庫的資料庫至少也有10億級別吧。 即使不在世的人也在人口庫中。 有人可能說人口庫資料不準，要不然為什麼不count一下，而是要人口普查呢？ 以我之愚見，我認為人口普查查的是 那 些和戶籍對不上的。 大致數量count一 把 也能查出來。 那麼我想說的是2000年左右人口庫的10億級的表。 比起今天有些業務系統的表的資料量如何？ 大資料嗎？

   如果查詢一個人的名字是前後%，那麼絕對的全表查，10幾億一定慢，資料量絕對大。那麼如 果精確查詢呢？比如查詢我薛曉剛。排除音同字不同等，完全匹配的當 時全國一共就9個。（我當時請公安查了一下，所以說那個就是全國庫）。用時不到1秒。大不大呢？就9條。說到這裡大家都應該明白我開頭提到今天群裡的故事了吧。大家也都是專業的，所以也心領神會 的贊同了。那麼如果一個系統中從設計、開發到運維等等都不知道怎麼最佳化查詢檢索的話，那麼遇到一定資料量的表全表查詢必然會很慢，必須要用大資料全家桶了。反之其實可以不用。也就是今天的主題。

    但凡資料庫都有索引，可能會有質疑說，關係型資料庫的前後%在es中就很快。這裡要說的是es本身又叫做全文索引，他也是有索引的。我們可以嘗試一下沒有分詞的快不快？ 比如有20G的日誌中搜尋%12%，也非常慢。所以我一直說大部分大資料場景，就是SQL沒寫好或者表設計問題導致的。我沒說所有，只是說大部分。BATJTMD等等一線網際網路公司妥妥的有大資料，五大行三大運營商作為非網際網路行業也是妥妥的有大資料的。有大資料的依然有很多企業，但是更多的企業是沒有。

    如果說真的遇到需要最佳化但是沒有相關人員和技術怎麼辦？那就提升硬體，2000年時候硬碟速度每秒200M左右差不多了。現在請看看因特爾的傲騰，每秒幾百GB。也就是說如果要用傳統資料庫+傳統硬體，執行一個小時的，大資料可能10分鐘完成了，而傳統資料庫+新硬體可能3-5秒就完成了。