虎瀾集: 網頁與資料庫 (4)
October 10th, 2016
回到問題的原點,NoSQL 是為了什麼目的而發明的? 先來看看 NoSQL 的特色:
結構簡單,高度平行化,可以很 scalable: 加節點或玩 MapReduce 都很方便。
結構簡單,所以可以容易的 replicate。
因為簡單,所以大部份的 complex query 都必須想辦法客製化。
Scalability, Replicability, Parallelization。請問一下寫網頁的諸君,您的網頁 JS 程式在 browser 端有幾個 user? 一個,很好。需要 replicate 幾份? 微糖少冰一份備份帶走,很好。您在用戶端天天跑幾千個 core 的 MapReduce 嗎? 抱歉這問題有點神經病,正常人不應該問的。現在你願意為了 NoSQL 的 scalability 和 replicability 來犧牲寫 query 的便利性嗎? 不要以為這問題很白痴,真的不少人被這個 NoSQL hype 拐到,有興趣可以去逛一下小弟和他人的筆戰。
IndexedDB 就是這種 NoSQL 概念的產物: 它存的是 objects,只提供很基本的 indexing,然後有非常奇葩的 transaction model。這奇葩的程度,可能連搞 NoSQL 的都不太理解: begin transaction,過程中寫個檔案或跑個 XHR,transaction 自動結束 auto-commit! 做與 database 不相關的 async call 會害 database auto-commit,這神馬邏輯? 偏偏人家變成規格了,還自我感覺良好擺在那裡好幾年哩! 要想寫複雜一點的 query,那和搬石頭砸腳沒什麼兩樣,這樣的規格要紅要普遍,這難度不是一般的大。
最妙的是,不管在哪裡,只要提出要弄 relational DB 的規格,就有撲天蓋地莫名其妙的反對聲浪: 你為何要復活萬惡 WebSQL? 你榨出 IndexedDB 的所有潛能了嗎? 你有什麼東西是不能用 IndexedDB 做出來的嗎? 這種鬼打牆邏輯很不幸的就是現今 W3C 規格推動者們的主流意見。因為這東西已經在那裡了,所以你不該推一個新的規格,即便它的基本假設錯了 (而且還很多人搞不清楚錯在哪裡),除非有不得不改的理由,例如 performance 極其不好,那才可能有操作的空間。說真的,這樣的 argument 我都不知道要怎麼喬下去,已經存在的就地合法,新來的就地正法,大致上就這麼個概念。
當然日子還是要過,project 還是要交,WebSQL 不可行,所以只好撩下去用 JavaScript 寫一個資料庫了,這就是 Lovefield 的由來。
(謎之聲: 事實證明,程式庫寫的太好也會構成人家反對 relational DB 規格的理由,因為你寫的東西就很好用了嘛,幹嘛推新規格呢? 沒關係,大家就再撐著點吧 …)