程式設計補完計畫(一): mybatis

-

程式設計補完計畫(一): mybatis

因為一些原因我發現自己一直以來都只有在寫程式，沒有認真想過為甚麼要用這個 Lib 或框架。
因此想透過這個系列重新審視自己身邊常用的 Lib。
第一集我想要先聊 Mybatis，基本上所有跟 ORM 有關的開發我都會用 Mybatis 去處理，但沒有認真探討過為甚麼要用和甚麼時候用。
那就先開始吧。

簡介(來自 wiki)

MyBatis 不是物件與資料庫表關聯，而是將Java方法與SQL語句關聯。MyBatis允許使用者充分利用資料庫的各種功能，例如儲存程序、視圖、各種複雜的查詢以及某資料庫的專有特性。如果要對遺留資料庫、不規範的資料庫進行操作，或者要完全控制SQL的執行，MyBatis是一個不錯的選擇。

優點:

先將優點列出之後一項一項說明

  • sql 與 Java 程式碼分離
  • MyBatis支持許多高級映射和存儲過程，使得更複雜的數據庫操作更容易。
  • MyBatis支持基於Spring、Guice等框架的注入，這意味著可以更輕鬆地集成到現有的應用程序中。
  • 由於 Mybatis 需要直接寫 sql，因此可以做更細和更複雜的 sql 操作。
  • 提供緩存機制，在搜尋資料時可以提高效率。

sql 與 Java 程式碼分離

MyBatis 可以將 sql 寫在另外的 xml 檔案中，也可以透過 annotation 寫 sql ，因此不會看到還先用 String 組成 sql 後執行的情況發生。

MyBatis支持許多高級映射和存儲過程，使得更複雜的數據庫操作更容易。

MyBatis 在 xml 中提供了，if, where 等語法，讓 sql 在組合時會更簡單，例如透過 <if> 判斷特定變數是否為 null ，如果是 null 就不要加入 set 裡面。
<where> 和 <if> 搭配的話就可以很簡單的組合出 where 條件，詳細的內容可以參考這個網站: https://mybatis.org/mybatis-3/dynamic-sql.html

Mybatis 可以很好的跟 spring 整合

再重複說一次，Mybatis 可以很好的跟 spring 整合。
這一點很重要，這代表著服務初期可以透過 spring jpa 或其他 ORM 框架設計，當服務足夠大導致出現 DB 效能瓶頸的時候在改用 Mybatis。

提供緩存機制，在搜尋資料時可以提高效率。

MyBatis 提供了三種緩存機制，主要是為了讓重複的資料在搜尋時不需要再去 DB 搜尋，而是直接在緩存取得資料，從而降低 DB 的負擔。
但需要注意!對於經常更新的資料不適合使用緩存機制，因為這很有可能會導致緩存資料和 DB 實際資料不相同。
下面簡單說明三種緩存:

一級緩存（Local Cache）

這是默認會開啟的緩存機制，同一個 SqlSession 跑同一個 SQL 語句的時候就會直接從緩存取得，但一離開 SqlSession 就會被清空。

二級緩存（Global Cache）

剛剛一級緩存是綁 SqlSession 的，二級緩存是跨 SqlSession 的，二級緩存必須在映射文件(如: xml 檔)宣告才會啟用。
注意: 二級緩存不會知道 DB 的資料有更改，我們必須寫 code 或設定二級緩存的固定更新時間。

聯合緩存 (Combined Cache)

聯合緩存是同時使用一級緩存和二級緩存。當數據被寫入數據庫時，一級緩存和二級緩存都會被更新。當數據被讀取時，首先會從一級緩存中查找，如果沒有找到，才會從二級緩存中查找。如果在二級緩存中也沒有找到，才會向數據庫中查詢。在 MyBatis 中啟用聯合緩存需要同時在映射文件和全局配置文件中進行配置。

題外話

甚麼是不常更改的數據? 像是: 郵遞區號，商品分類。
甚麼是常更改的數據? 像是: 庫存更新。
如何清除二級緩存? 根據情況可以考慮開一個 API 專門用於清楚二級緩存，或像前面提到的設定二級緩存的更新週期。

缺點

  • 需要會 sql，提高學習曲線
  • 需要設定映射配置
  • 可能出現重複的程式碼
  • 執行前可能不會發現 SQL 寫錯了
  • MyBatis 的性能與 SQL 的質量、緩存配置有問題的話會發生性能問題

需要會 sql，提高學習曲線

這有點像雙面刃，會寫 sql 的人可以透過檢查 table 的 index 寫出高效率的 sql 語句，但就是需要花時間去了解。

需要設定映射配置

常見的 mybatis 寫法會在 Java 寫一個 index 之後再寫一個 xml 去搭配，因此我們需要跟 spring 或其他框架說 xml 放在哪裡，但如果以 spring boot 來說的話配置通常不會太複雜。

可能出現重複的程式碼

因為會需要依照不同情境寫不同 SQL 的 where 條件，但這部分可以參考剛剛前面提到的 <if> <where> tag 生成動態 sql 就可以解決了。

執行前可能不會發現 SQL 寫錯了

由於 SQL 都是寫在 xml 裡面，在編譯 Java 時 mybatis 並不會檢查 SQL 語法，因此有可能會在執行到該 SQL 時才發生錯誤。

MyBatis 的性能與 SQL 的質量、緩存配置有問題的話會發生性能問題

如果寫 SQL 的經驗不多可能會導致 DB 搜尋時間很久(如 join 大量的 table 等)，錯誤的決定緩存策略可能會導致緩存取得的資料與 DB 不符從而影響後續的邏輯判斷。

總結

統整起來看的話如果沒有複雜sql需求的話會有其他更好的選擇，比如spring jpa等，但如果今天sql是需要使用特定index或需要靈活組合 sql 的話 mybatis 會是不錯的選擇。

留言

張貼留言

這個網誌中的熱門文章

基本 Spring security 快速入門

-
圖片
基本 Spring security 快速入門 最近學了 spring security 遇到一些 6 版和舊版的一些差異，所以想說寫一下快速入門，但有些前情提要: 這個入門不包含 spring security 的使用概念，關於這部分相當推薦閱讀 spring security 實戰這本書 本快速入門不包含 OAuth2 和權限控管，只會使用 Basic 驗證，但建議先學會入門之後再加深． 由於個人專案有使用到 swagge ，因此也會有相對的教學 主要使用到的 spring security 元件： org.springframework.security.authentication.AuthenticationProvider org.springframework.security.crypto.password.PasswordEncoder org.springframework.security.core.userdetails.UserDetailsService org.springframework.security.core.userdetails.UserDetails 撰寫 UserDetailsService 首先先在 service 新增 class 並且 implements UserDetailsService 實作的時候會發現需要實作: UserDetails loadUserByUsername ( String username ) throws UsernameNotFoundException ; 依照 function name 可以知道要實現的功能是去 DB 或 redis 之類的地方取得使用者資訊，並且將資料放進 UserDetails 後 return 出去，因此在開始寫 loadUserByUsername 方法之前需要先實作 UserDetails 實作 UserDetails 實作的時候會發現我們需要實作 getAuthorities getPassword getUsername isAccountNonExpired isAccountNonLocked isCredentialsNonExpired isEnabled 基本上依照 functio...
閱讀完整內容

記帳專案說明

-
圖片
新專案說明 最近開新的專案，目前專案的系統架構和後端處理的差不多了，剩下前端的部分正在一邊學 react 一邊完成中，考慮到最近要開始找工作了，所以想說寫個部落格一邊介紹目前專案的架構與紀錄目前的狀態。 專案整體架構 在開始之前我們先發一張架構圖吧，接下來請把架構圖當成地圖開始冒險吧。 這次的專案主要是走雲原生的概念，下述我們分成基礎設施、前端、後端來聊吧 基礎建置 雲端服務廠商選擇: AWS 這個專案從剛開始設計就是預計上雲且使用的是 aws，主要有兩個點 我們家並沒有固定 IP ，如果要走地端的話勢必要使用到 DDNS ，那牽涉的範圍就會更廣了，因此決定直接上雲 根據網路上查到的資料，目前 aws 市佔 33% ，考慮到將來要找工作與方便尋找資料因此決定直接使用 aws 用到的 AWS 服務 接下來先概覽一下用到的服務與相關功能，下面會以使用者接觸到服務的順序來說明： 服務名稱 用途 router53 DNS, 用於將 domain 轉換成 IP, 我的 domain 也是在該服務購買的 彈性 IP 當我們租了 AWS 的伺服器時是沒有對外 IP 的，因此我們需要透過彈性 IP 申請並且綁定到我們的 EC2 安全群組 連到伺服器的防火牆，可以設定每個 port 是否要開啟，並且設定白名單等 EC2 這個就是我租伺服器的本體，所有的服務與反向代理等都是放在這裡 EC2 建置了哪些服務 這邊會講一下我安裝與使用到哪些非我開發的服務 資料庫： 資料庫的部分我使用的是 mariaDB, 會選擇 mariaDB 的原因除了他是 MySQL 的分支之外，他的社群很活躍、穩定性也很高 catch: catch 的部分我使用 redis ，主要適用於處理會需要經常取得資料或者不需要持久化的資料，目前我主要用於記錄使用者登入後的 token，由於採取的是前後端分離的架構，後端會需要頻繁的驗證 token 和透過 token 取得用者資訊，因此這部分得資料就放在 redis，更詳細的使用邏輯將會在後面提到後端的時候說明。 SSL: 這個專案的 SSL 主要用於 https 連線，這部分是使用 Let's Encrypt 家的憑證。 會用 Let's Encrypt 的原因最主要是免費和自動化申請，如果考慮到...
閱讀完整內容

JMSTemplate 的教學

-
前言（一堆廢話） 嘿，大家好久不見！我發現距離上次在 Blogger 發文，竟然已經過了快半年了。想想還真有點不好意思，不過這次我可是帶著新東西來跟大家分享的！ 這次要聊的是 Java JMSTemplate。為什麼突然要學這個呢？主要是因為我最近換了新公司，而他們那邊剛好需要用到 訊息佇列 (Message Queue) 的技術，所以我就趁這個機會好好學了一下。 (老實說，我其實都工作六年了，這東西早就該會了啦！) Message Queue 是什麼和目的 這部分我覺得我讀的書的寫的很棒，因此想說直接引用過來。 假設現在是星期五 16:55 ，在幾分鐘就可以開始期待已久的休假了。再過幾分鐘你的飛機就要起飛了，但是在這幾分鐘你需要先確定主管和同事了解你的工作進度，這樣他們才有機會於下週一接續你的工作。這時候該怎麼辦？ 這時候避免打擾到他們最好的做法就是留紙條或發送 E-mail ，如此一來他們就可以在下週一或有空的時候看到 E-mail 接續工作。 這段很完美的解釋了 Message Queue，的概念，將訊息傳到佇列，之後根據佇列的先進先出讓服務吸收消化，最後調整服務一次接收多少 Message 。 如此一來可以帶來以下幾個好處： 解耦合： 發送者可以完全不管接收者狀態與是否可以承受，只需要將訊息丟到 Queue 就好了 系統不同的區塊可以獨立開發（其實就跟現今流行的微服務類似概念） 非同步處理：發送者可以完全不需要等待另一方處理就可以繼續處理下一個 request。這樣講有點抽象，可以想像麥當勞點餐系統，櫃檯的人員不需要完全確認廚房是否收到單就可以接下一個客人了。 提高可靠性：很多提供 Message Queue 的元件會提供持久化的功能，他會將 message 存起來，這樣一來就算遇到某個 Message 處理有問題，也可以很快查到並且做後續 support。 水平擴展：我們可以很輕易地增加消費 Message 的處理人員，這樣就可以提高 Queue 的消化速度，已應付高流量又要快速處理的需求。 等等 上述只有放我自己認為很重要的優點，但其實還有很多的優點。 名詞 那優點介紹完之後我們來聊一下在 Message Queue 常會用到的名詞， 佇列(Queue)：就像是排隊一樣，先進先出。 生產者(Producer)：就是指生成 Message 的服務 消費者(...
閱讀完整內容