拿個錘子看誰都是釘子

    最早我聽這句話是有一次DTCC上，有位嘉賓說Elasticsearch的。首先他既能儲存資料也能做全文索引，所以Elasticsearch歸屬資料庫範疇。也有不少人沒有這個認識，甚至認為es和redis都算中介軟體，有這個認識的基本其實和他也沒法深入溝通了。那麼由於es的某些場景中全文索引解決了我們RDBMS中非常忌諱前%，不過這個有個前提條件就是有分詞，如果沒有分詞那麼在es中也是全表。不過es有個特點就是分片，用N臺資料庫以及N臺資料庫的CPU記憶體等資源去硬抗這些全表掃描。

    可能有時候大家覺得給MySQL 96個CPU，256G記憶體有點大。但是給es這麼多好像覺得應該。（也不知道這是從何說起，為什麼會有這種歧視和錯誤的認知，也許就是錘子和釘子的定位問題）。其實我剛才說的給MySQL的還是小了。我有一次在一個群裡看大家討論，現在誰還共享池總出問題？隨隨便便都是1T的記憶體，怎麼會有問題？無論哪種資料庫吧，配置夠好的話，SQL的容忍度就高一點。配置低的話，SQL的容忍度就差一點。我上大學時候，2000年前後，有的同學家裡條件好，每天愛吃什麼吃什麼。不在乎價格，有的同學家裡條件不好，只能每頓飯算著過。這就是質量和硬體之間的權衡。

   這是從es說起的錘子和釘子。我還想說一個事情， 和ES不是銀彈一樣，我覺得微服務也不是。我這樣說可能被扣上開倒車的帽子，好在我這樣想的不止我一個，而且還有人做了。大家可以參考這個連線。 https://blog.csdn.net/lianggzone/article/details/112975554   就是放棄微服務，我們為什麼重回單體架構？ 我一直說分散式是好的。但是一定是單體處理不好的情況下，如果單體足夠勝任，還去做拆分，那就是為了做而做。效果非常不好。（我現在有一個任務2個人能做，和我領導申請說我要10個人來協同處理。我上級一定不批准我的要求。是個老闆都不同意）我打個比方。如果一個公司有1000人，那麼有10個部門經理，是比較正常的。如果一個初創公司就5個人，也搞5個部門，怎麼看怎麼不習慣。有事做下來談論一下，就不要用OA辦公了吧？

   當年做hadoop時候5個節點（別笑話我，和概念車一樣，概念嘛），在hive中count一個60條資料的表，要1分鐘多。比我人肉數的都慢。這也是一樣道理，都有個使用場景。不是拿到盤子就是菜啊。

   es、微服務、hadoop都不是錘子。用的好了是工具，用的不好，把自己的東西敲得七零八落。