Unite是一個vim的模糊搜尋外掛，透過將模糊搜尋的邏輯和資料來源分離，實現了一個可泛用於各種情境的模糊搜尋框架，例如：檔案搜尋、內文搜尋、git commits等等；加上它作為一個原生vim外掛，幾乎是只要vim能用的地方它就能用，省去不少環境設定的麻煩，過去幾年來它一直在我的開發環境中扮演重要角色。但Unite效能不彰、由於設計上的問題擴充不便，更受不了的是作者Shougo沒事就把一樣的東西一直重寫，而不是好好地維護好一個專案，終於「再次」下定決心換掉 –– 是的，這不是我第一次找，只是過去都沒有成功。
所幸一代新人換舊人，這次很快就找到：fzf。實作品質優秀、效能拔群、設計上擴充容易，加上穩定的維護，用得我老淚縱橫，忍不住就贊助了好幾杯咖啡給來自南韓的作者junegunn。
以區塊鏈為基礎的技術現在有多火紅，相信不需要任何解釋。個人最早的加密貨幣經驗是十幾年前在研究所的時候嘗試買了一千多台幣的比特幣，體驗過整個流程後覺得「喔喔，真的這樣就可以買、可以用了耶，好有趣呢」就把它忘了 –– 對，忘到連錢包都弄丟了，我並沒有因此買房買地，謝謝關心。
現在會想去玩玩看的契機，主要是連我周遭跟技術領域八竿子打不著的人都開始聊這個，再加上我本身對分散式技術一直很有興趣，偶然發現Ethereum的EVM是turing complete，同樣基於區塊鏈技術實現的Golem和野心勃勃的The Internet Computer像約好了一樣同時吸引了我的目光，就決定是時候從使用者的角度去從Ethereum切入體驗看看。
幾個月下來後這所謂「真正自由的去中心化網路」，並沒有讓我感受到它的支持者所大肆宣揚的種種美好，因此我現在是沒什麼在玩了。它的好已經很多人在寫了，因此本篇專注在為什麼我覺得它其實沒這麼好。
我個人目前偏好的工具是M牌的Playwright。因為早期calypso的e2e tests是用Puppeteer，不知為何它的行為常常跟我預期的相差甚遠，只能說八字不合；至於Selenium就更不對盤了，我連要弄個最基本的開個網頁點個按鈕都弄半天。Playwright倒是幾分鐘內就弄出來了，API設計上對我來說較易理解，而且原生支援多種瀏覽器，就這麼用到現在了。
說到瀏覽器自動化，大部分人第一件想到的事情其實是屬於「操作」的自動化，例如：開啟網頁A，按下按鈕X，如果出現Y對話框就按下Z按鈕等等。但我個人經驗上，對於平日開發工作的輔助上，真正最常用的其實是瀏覽器的狀態設定腳本化，例如：cookies、local storage、query strings、解析度、桌面裝置vs行動裝置等等，能夠把這些都寫成一個能重複使用的腳本，在修改完程式後輕鬆地用一行命令生出需要的瀏覽器實體，不用重複手動設定，又不用動到自己平常用的瀏覽器。過去總是靠匿名視窗去手動調、這個瀏覽器開發用那個瀏覽器日常用，簡直不堪回首。
今天在設定開發環境以及安裝git-filter-repo和tmux-open時不知動到什麼，首先發現顏色都跑掉，接著tmux出現一系列令我抓狂的問題：tab completion陣亡，在zsh下delete變空白，打clear會出現terminals database is inaccessible 錯誤，然後我的命令列提示字元甚至還可以刪除：
搞了半天，桌子快撞壞，才發現$TERM不知為何變成了tmux-256color，在tmux.conf中加下面這行設回macOS預設的xterm-256color就行了：
set -g default-terminal "xterm-256color"
我還是不知道我在安裝過程中到底動到什麼，或許是安裝git-filter-repo時有更新一些tmux相依套件，安裝tmux-open後重開tmux問題才顯現出來。後來我的顏色設置還是回不來，索性就當一個機會把用了6年還是7年的配色給換了。vim換了molokai：
terminal則是自己隨便配一配：
僅以本文紀念一下今日花在這問題上的半天，和我一去不復返的配色們 T___T
距離上次整10天了，閱讀進度愈來愈不穩定了啊啊啊啊啊。公司讀書會的進度其實已經到第6章，俺已經放棄追車尾燈，改成用自己的步調慢慢看了。
第三章的最後著重在解釋analytics資料庫在檔案的佈局上的一個有趣的實作策略：以資料欄為基礎(column-based)的序列化，而非一般transactional database的資料列為基礎(row-based)。所謂資料列為基礎的佈局，就是把每個資料列(row)一個接一個地寫到檔案中，而column-based就是反過來：把每個資料欄(column)一個接一個地寫到檔案中。會這樣做是因為硬碟的讀取頻寬有限，但統計分析經常要對百萬級以上的資料做運算，但同時又只需要少部分欄位即可。以資料欄為基礎去序列化，就可以有效做到只讀取需要的欄位了。
舉例來說，假設我們是個超級水果電商，我們可能會有長這樣的資料庫：
那麼，如果是資料列為基礎的檔案佈局概念上就長這樣：
那麼資料欄為基礎的佈局就大約是這樣：
從上圖也可以觀察到兩件事： 第一，資料列因為被以欄位打散到許多檔案中，因此一個資料欄檔中的順序是非常重要的，因為那是我們重建一個資料列的唯一依據。第二，因為一個欄位的值域通常不大，因此很容易壓縮，例如書中用的例子是run-length encoding。
但這樣一來column-based的資料庫寫入上會需要不同的策略。像B-tree那種會需要in-place寫入並維持排序的檔案結構自然是不行的，因為一個資料列現在可以橫跨數千個欄位檔，如果要從中間插入一個資料欄，那就意味著要去動那數千個欄位檔，保證機房人員整天換硬碟換到手軟，硬碟廠商笑開懷。前面的章節提過的log-structured storage便是一個解方：每次寫入只從檔尾附加(append)，並適時進行壓實(compaction)。書上提到LSM-tree可以用，但我有點想像不出來這東西在記憶體中的SSTables(sorted-string tables)要怎麼建。如果是跟一般情形相同的平衡樹，因為本質上還是以資料列為單位，會不會造成什麼困難？還是會針對之後以欄為基礎的序列化做什麼特化？這些細節可能要去看實作才能知道了。
到此第三章終於堂堂結束，接著第四章為「Encoding and Evolution」，乍看之下應該是在說實際將資料序列化到檔案的實作策略 … 吧？這次第三章真的讀很慢，希望這次可以快一些。
(進度：loc 2353 – 2540)
又一個星期沒寫了 … 恐怖，專案死線太恐怖了 …
這次讀的段落雖然觸及的主題很多，但重點其實是要從前段以線上即時應用為主的線上交易處理(OLTP，Online Transaction Processing)，過渡到本章後段的主題線上分析處理(OLAP，Online Analytical Processing)。就個人目前粗淺的印象，那個"OL"真的是挺雞肋的，OLTP出生的年代線上與否是件大事，但OLAP就不一樣了，一方面線上或線下並不是重點，另一方面以其探討的架構來看自然是跟大型的資料中心有關，那就一定是線上的。或許只是因為和OLTP對稱，只好硬是冠個OL上去吧？
中間的過渡主題包括fuzzy indexes，full-text search和in-memory database，但都只是蜻蜓點水式帶過，尤其前二者並沒有太多深究，只有指出為何fuzzy indexes和full-text search會需要不同的索引結構。至於in-memory database，很有趣的是因為今日從database engine乃至OS都有自己的caching機制，導致in-memory database真正有效益的地方不在於查詢與讀取，反而是因為在寫入時它不需要轉換成硬碟需要的格式，例如序列化。
過渡之後，本章堂堂進入analytical data的世界。在本章開頭，作者就有指出transaction data和analytical data由於目的和資料量級的差異，存儲策略會完全不同。書中的這個表格總結得不錯：
簡單來說，資料分析的應用大多是一次抽出大量資料出來作統計分析，而當服務規模夠大，直接在production database上做這件事很容易造成整個服務停擺，弄得operation team森七七，系統部門和資料分析部門間烏煙瘴氣。為了兩邊都能做好自己的工作，才衍生出透過ETL程序(extract-transform-load)，把資料定期轉到另外的"data warehouse"，讓資料分析師們可以有個地方愛怎麼搞就怎麼搞，operation team保有內心的祥和，從此和氣生財，大家都過著幸福快樂的生活。
WordPress.com的作法大致上與書中相符。內部有自己維護的ETL程序會把最新的production data輸入到一個Hadoop cluster中，再透過Hue、Looker、以及N種自幹的資料分析工具去找出需要的資料。至於production database上則有作一系列的保護措施，盡量避免OLAP量級的query被某個沒睡飽的工程師跑到，但並沒有很完美就是了。
下個段落開始要提到analytical datastore的存儲策略，標題是「column-oriented storage」，希望不會又是一週後才寫了。
(進度：loc 1668 – 2353)
爆忙了一陣，竟然已經整整一週沒繼續寫這個系列了。恐怖，在家上學太恐怖了 …
這個部分首先從兩種database engine底層常見的檔案結構開始提起：LSM-tree與B-tree。這讓我回想起了大學時代修檔案結構(file structure)的血淚史，期末作業就是實作一個最基本的B-tree，後來太多人卡住，大家還聯合起來去向教授求情，才得以寬限一週。總結來說，LSM-tree(log-structured merging tree)因為針對硬碟的sequential性質去特化的存儲策略，對側重寫入的應用會有較佳的表現；但B-tree則是四平八穩，因為就是棵平衡樹，在讀取上通常表現不錯，寫入上因為隨機存取多的關係會比前者弱一些，且容易有空間破碎的問題。雖然概念上是這樣，到底何者對自身的應用才是最適合的，還是要靠實驗分析才有辦法知道。
其實就像學資料結構(data structure)一樣，許多資料結構雖然不明講，但大致上是基於von Neumann架構來設計的東西，所以實作與應用上其實都有考量到硬體性質。B-tree和LSM-tree也不例外，整個實作策略上精密地考慮了傳統硬碟的特性：存取時間長、循序讀寫佳、隨機讀寫不行，以及一定要考慮到當機復原，因為寫到硬碟裡的東西不像記憶體裡的大不了重開機治百病。
段落的最後以索引結構作結，簡單說就是這個key-value pair裡，value到底要存在哪。它可以是直接inline或說in-place跟key存在一起成為所謂的clustered index，也可以是一個heap file，也有可能是介於兩者之間，一部分在heap一部分跟index在一起成為所謂的covering index。這裡也順便提到以R-tree為代表實作的spatial index，可用於做multi-dimensional的range queries，這部份我就沒什麼實務經驗了。
下一個段落要進入Full-test search和fuzzy indexes了，這個部分和analytics data storage是我最想了解的部分，好興奮啊！希望明天不要又忙到沒時間看了啊啊啊啊啊。
(本日進度：loc 1900 – 2032)
天啊，今天第一次開始讀第三章，只能說太精彩了。繼第二章走訪各data model的性質後，本章進一步深入到database engine的存取實作概念。雖然我現在才剛讀完一開頭一點點，但真的是讀到忍不住啊啊啊喔喔喔又喘又叫的，旁人看到搞不好以為我在讀的是官能小說。哼哼，誰說讀技術書籍不能高⬤的？
本章以一個「世界上最簡單的資料庫」開始，因為實在太精簡了，值得在這邊照抄一下：
#!/bin/bash
db_set () {
echo "$1, $2" >> database
}
db_get () {
grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}
這種append-only的讀寫策略很顯然寫入非常有效率，但讀取會是一場災難。從這裡，作者進一步帶出hash indexes的概念：透過一個在記憶體中的hash map去儲存從key到file offset的map來解決讀取效率問題，同時指出任何index都會增加寫入的overhead，這也是為什麼幾乎所有資料庫都不會預設index。這讓我想起以前年少不懂事，曾經搞出過index file比實際資料還龐大的烏龍。
由於是append-only，那代表任何對已存key的更新或刪除事實上是透過在檔案尾端新增一筆相同key的紀錄來完成。雖然概念上簡單，但書中指出這在實作上其實有很多挑戰，例如空間使用效率上需實作compaction來把所有相同key的records合為1個，以及把一個資料庫檔案切成多個"segment"等等。
既然有了這組map，那這代表我們可以直接in-place覆寫檔案來實作update嗎？作者在這裡回顧了上面的極簡資料庫，指出這種append-only的log structure其實出乎意料地有效，因為它是一種sequential operation，這在過去磁盤為主的硬碟尤其重要；上面提到的compaction若造成segment merge，也會是sequential operation。
實作以上hash indexes的代表性key-value store為Bitcask，稍微看了一下它的repo，似乎相關應用還不少。
段落的最後作者指出這種資料庫的兩大限制：
以此為引，下一個段落要開始講沒有這兩項限制的SSTables與LSM-Trees了。
…
太興奮了啊啊啊啊啊啊啊啊！！
週末盡可能地找空閒時間讀，終於把剩下的最後一點點讀完了。
最後一段介紹Datalog，標題是「The Foundation: Datalog」，因為它是在1980年代從學術界開展出來的query language，盡管在當年並未在實務上獲得成功，作為QL的老前輩，其作為催生其他QL的基礎可謂功不可沒。
應該啦，書上這麼寫，我就這麼信了。
Datalog是一個類Prolog的logical language。大學時代在學Programming Languages時我就搞不懂，現在看了還是滿頭問號。所以請原諒我寫不出什麼像樣的心得，因為心得就只得一句花惹發。
有意思的是學到有個叫Datomic的資料庫就是採用Datalog，看起來挺新穎的。這讓人聯想到因為Elixir重新讓世人認識的Erlang，又有點像超前時代太多而不受重視的藝術品，因緣際會等了數十年才得以重見天日。資訊科學的歷史中還有多少這樣靜待發掘知識珍寶呢？
下回第三章：「Storage and Retrieval」，要進入database engine的實作世界了，有種好硬好硬的預感 …
(進度：loc 1327 – 1668，昨天沒能抽空出來寫，因此這是兩天各讀個20分鐘左右的量。希望以後可以盡量避免這個情形)
從這個段落開始，本章堂堂從個人略懂得relational model與document-based model進入Graph data model。作者手先帶讀者認識上圖的範例，接著用PostgreSQL的語法示範這樣的資料在relational資料庫中可能會長什麼樣子，再引領讀者思考我們可以「問」這dataset的問題，例如：哪些人出生在英國但目前住在美國。透過這樣的思考練習，很快就會發現，雖然我們可以把這樣的資料在relational database裡表述出來，但query會非常難寫。以上例來說，透過「within」表現的從屬「美國」的「地區」關係很難預先說有多少層，這代表很難預先知道到底要寫幾個join，雖然有些資料庫現在有recursive join這種超魔幻的東西，但 … 就太魔幻了。在這基礎下，本章開始介紹Cypher QL與neo4j，SPARQL與Triple-Stores，以及因為異曲同工之妙而常被放在一起討論的RDF和semantic web。
因為我過去從來沒接觸過這種database，整個段落讀來讓我覺得眼界大開。雖然沒有實際用過，但我還蠻喜歡triple stores的概念的：不刻意區分vertices與edges，而是把一切都編為"subject-predicate-object"的三元組。因此，Cypher QL在撰寫時會需要考量到條件式放的是vertices還是edge，SPARQL可以不用考慮這件事。當然，實用起來我會不會還持同樣意見就是未知數了。
段落的最後作者花了一整頁的篇幅解釋Graph data model與前面提過已經凋零的network model的不同。雖然概念上同樣都是表現graph，但兩者的實際資料結構差異使。總結起來個人覺得最關鍵的差異有二：其一，network model真的把資料存儲成巢狀結構，因此要存取entities的唯一方法就是真的去巡覽整個graph；但Graph data model並沒有這個限制，必要的時候甚至可以用直接的index來存取各entities。其二：network model因為這樣的設計，只能用imperative query language而非像graph data model有很好的declarative query language可以使用。對於QL方面的差異，我想network model如果活得夠久搞不好能獲得解決，但也有可能先天上的限制讓它無法這麼做就是了。
下一段的標題是「The foundation: Datalog」，又是一個完全沒看過的東東，令人期待。
軟人手札 
你必須登入才能發表留言。