二次反擊《再論為什麼你不應該招DBA》

     上上週作者約戰，很久沒等到，我以為過去了，還是來了。那我們就回應一下，我僅代表我和和我類似感受的同仁進行回應。

     首先對其： DBA的價值空間的這個段落進行駁斥。他提到的：“但是可惜的是，過去十幾年來，行業趨勢是反的：DBA能達到的上限在下降，而沒有DBA的下限顯著地提高了。 ”實際情況恰恰相反。我認識70後的開發，開發入職考演演算法，寫SQL看執行計劃。但是90後的連索引是什麼都未必知道。我們這裡不知道是不是接觸的人不同。我經歷了幾個行業，國企私企都做過。發現都是這樣。外國開發水平如何我不知道，我沒接觸過。其次我的環境沒有在公有云上。我個人認為私有云不是雲（沒有云的屬性）。但是我幫別人他們租用處理過阿里雲和騰訊雲中使用過程中遇到的問題。我是針對以上的經歷發言。我接觸過一些開發，問他這個怎麼來的到哪裡去？他說不知道，我只管呼叫介面。我問知不知道全表查詢？不知道。我問知道這個鎖是怎麼回事，和哪些有關？不知道。 以上不是所有，但是是國內比較普遍的。10年前我遇到的問題，10年後的今天依然遇到。不知道這些基礎問題的人還是很多的。對於堆表的資料庫，很多人至今還以為刪除資料表中的資料，再全表查詢能提高效率。對於模糊查詢，時至今日還有人覺得要先%ABC or 一下ABC%組合起來，這也有。SQL只管邏輯對了，效能好不好不管。把機器拉滿。當然公有云可以彈性擴充套件儲存和計算，但是這個錢就花了。實際上寫好點，很多滿負荷的資料庫，最後都變成空載的資料庫。這種我處理過上百個資料庫例項了。如果有公司願意當冤大頭，那我就不說什麼了。其次是在非公有云環境中這種場景資料庫基本就不能正常工作。而更重要的是我看到很多連邏輯都寫錯的。這種太多了，每週我都能見到。（各種群）

   其次對其： 下限提升：免DBA得到更快的DB交付速度 這個段落部分進行駁斥。他提到的部分是對，就是雲簡化交付。這裡的雲是說公有云，這也就是雲的屬性，解決了快速獲得的問題。但是重要的來了，我也一再強調，很多公司是上不了 公有 雲的。而且我覺得在中國是不上公有云的比上 公有 雲的多的多（國企、央企、事業單位、政府還有各種各樣等等太多了）。 （私有云不是雲，解決不了這裡說的快速獲得的問題）所以還有這個快速交付的僅僅佔一小部分。在國外不知道如何，在中國這個佔比還是不大。

   下面一個段落： 下限提升：遠離DBA，遠離分庫分表。這是文章中對開發說的。我贊同開發提升，也贊同不要分庫分表。但是後面就開始亂說了。“DBA們只懂單機關係型資料庫 ”。這是20年前的沒有其他資料庫的時候了。請不要停留在過去。以我為例：使用、維護和學習過Oracle/MySQL/SQLSERVER/DB2/PostgreSQL/Redis/Cassandra/mongodb/Hbase/Hive/elasticsearch/neo4j/influxdb/Tdengine/ClickHouse/Greenplum/timesten/memcache/TiDB/OceanBase/達夢/TDSQL/RabbitMQ/Kafka/OGG。我相信在國內不止我一個人這樣。所以這個只懂關聯式資料庫的論點站不住腳。雖然我都不是很精通，但是我應該有發言權。RDBMS在很多領域為主，NoSQL配合。畢竟我們很少見到線上交易用NoSQL支援吧。然後只要是懂資料庫的DBA都討厭分庫分表，我倒是認為很多場景都是開發沒寫好，然後採用分庫分表來緩解的。我本人最不喜歡分庫分表。

   再下一個段落： 上限下降：不斷出現的刪庫跑路。更加是不負責任的言論了。國內資料庫例項有多少？一千萬都不止吧。極個別違背職業道德有刪除的，不能說明整體。你請看看刪庫的多，還是SQL寫的笛卡爾積多？難道SQL寫成這樣就不要開發了嗎？這和某地出現一個壞人，說這個地域全是壞人有什麼區別？

   最後一段：有四個公司說沒有設定DBA崗位。請問1哪4家？請問2說明除了這4家都要。請問3，您知道什麼是DBA嗎？database administrator？不。他還包括了database  analyst  和database architect 。雲只是做了administrator的一部分。做了標準化安裝、高可用和備份等基礎操作。但是最佳化呢？會給你找出TOP-SQL但是不會告訴你如何改？

   舉例1：一個16個表的關聯，一看就不合理。分析過後，發現有些欄位不是必須，既然不是必須那麼這個表可以不用關聯。那麼第一步我們就可以減少4張表關聯。請問哪個雲廠商去這樣給建議的？如果有告知一下名字。不是說雲都不看使用者資料的嗎？這是database administrator的範疇。

  舉例2：有一次我看到了這樣一句消耗高的，select * from t where a=xx   or b=yy   看到這裡可能一般人要說，加索引了。那麼如果就是加索引這種技術含量就不太高了。2018年Oracle就釋出了自動化索引的版本，那麼說明這種在更早版本就籌劃，甚至更早時間就設計了。雲如果解決了這個是應該的，因為這是他應該做的。我這裡要說的是，我就好奇進去看了一下b列的資料。發現B列3年以來都是空的。我就找開發說這個SQL不合理，然後拿出分析資料。開發當時就驚呆了，然後開發去問業務為什麼會這樣。業務說，這個業務場景早就不用了。該功能也不會用了。請問哪個雲廠商去這樣給建議的？如果有告知一下名字。不是說雲都不看使用者資料的嗎？ 說到這裡，可以看出來這是database  analyst。透過分析發現問題。

 舉例3： 又有一次我經歷一家公司為瞭解決登入問題，涉及到的資料庫有Oracle Redis mongo  Memcache Cassandra。這些是序列的一個環節有問題，登入就出問題。這些是我調研的結果，瞭解到只需要每秒處理1000個登入請求就行。那麼我就把mongo  Memcache Cassandra

這些全去掉了，其實直接訪問Oracle就行，最後還是給他留一個Redis。請問哪個雲廠商去這樣給建議的？如果有告知一下名字。雲廠商巴不得你多花錢，我從來是精簡架構為宗旨，少花錢才是價值。說到這裡，可以看出來這是database architect。

   例子太多，不佔用讀者時間。總是以上例子沒有一個是公有云能幫我的。更何況廣大不用公有云的公司。那麼以上問題誰來解決呢？很多場景從需求就要介入、還是設計包括邏輯設計、最後是實現都是資料庫的各種DBA去完成。做的過來和做不過來是另外一回事，做不過來可以透過招DBA來完成。