不建議開發來做資料庫選型

     我見過用es存日誌的，畢竟ELK就是做這個的。我也見過用mongo存日誌的。畢竟也合適。但是我還聽過用TiDB來存日誌的，這個就有點大材小用了。當然MySQL和Oracle用來存日誌的也不少見，以前聽過一個故事，有人使用Redis來存日誌。用關係型資料庫存日誌我勉強能理解為了查起來方便。但是用Redis存日誌圖什麼？以上其實都是一般開發自己定的，完全是自己喜好。我記得5年前有個外包過來找我說他要一個redis叢集，我當然要問問這是要幹什麼?他說要處理高併發場景，我說我們這裡有redis，主從的。當然叢集也有，在實驗環境。我們場景就是沒有redis也能支援，你還要叢集嗎？他回答不上來，我知道，他可能是培訓機構速成的。這種其實在很多公司也常見，資料庫十幾種，訊息佇列五六種。基本就是微縮版的大廠架構，可能除了大廠自研的全上了。

   但是實際上每種資料庫有沒有物盡其用？比如ABCDE幾個系統都用了mongo，用來幹什麼？僅僅是存日誌。如果僅僅存日誌的話，其實MySQL的JSON也有這個功能，那麼我可以減少一種技術棧。但是如果要深度使用一下的話，那麼使用mongo才有意義。我的意思是每種技術要深度應用。看下面這圖，mongo從4開始支援事務。說實在的我並沒有好好在這方面使用，這個要反思。 這個案例就是多個步驟一句話完成。

    我們平時不能只說有個功能，一旦這樣說出去了開發就隨意使用了。一定要做好demo，告訴應該怎麼做不能怎麼做。 比如我說Oracle MySQL中的JSON型別是輔助的，別where條件後面就一個json的鍵值，因為通常沒索引。當然也可以建立，但是這不是最佳實踐。但是我依然日常能看到SQL依然我行我素的有且僅有JSON條件，當然並沒有索引。最後有問題的話，還說這個不是支援嘛？要不我們用es吧？

   用到es的時候，如果不用es的分詞，那等於沒用。完全就是靠硬體的全表（es的表叫索引）來抗。等於又沒用好。

   一個單機的MySQL PG每秒寫入一萬條資料不是難事。而且99%的系統根本達不到這種場景，但是可能在各種原因上比如SQL實現方式上有問題，這個時候如果找到問題就解決了。但是深度去了解技術棧，那麼就會來個訊息佇列吧，削峰填谷。但是由於又未能對技術深入，不瞭解我們一般訊息佇列對於硬體的要求，給了他一個很差的IO環境。（話說如果這種情況訊息佇列還能正常，真的說明不用它也行）。然後能又怕訊息佇列丟資料或者為了確認訊息的收發正常。那麼非同步（注意，一旦異構感覺就高大上了吧。解耦了。）再去把訊息放到資料庫中。

   資料庫技術棧本身就很卷，各種資料庫多模，如何選型是一個課題，如何使用這個話題就更長了。今天不展開了。