標籤: 資訊學習

Meilisearch 是一個以 Rust 開發的全文搜尋引擎 (full-text search engine)，主打簡單好用、搜尋和回應速度都很快，另外預設就支援多國語言，不需要特別調整設定或安裝擴充套件即可使用。

覺得有趣，去年拿來當作 site project 的一部分研究。當索引檔大小漸漸增加，也開始發現一些問題。

觀察了一下運作的狀況：

• 索引大小約 1 GB 時，使用 1 thread + 1 GB RAM，新增資料約 3 秒
• 索引大小在 5 GB 時，使用 4 thread + 2 GB RAM，新增資料至少 15 秒起跳

在索引檔大小增加以後，增加 threading 和 RAM 對執行效率並沒有顯著的效果，瓶頸看起來是卡在 disk I/O。

手上 VPS 觀察到的 I/O 最大約 200 MB/s，應該就是極限了：

---

Meilisearch 並不是不能用，這邊還是簡單列幾個優缺點。

優點：

• 就一個執行檔而已，不用下參數就可以正常運作
• 走 RESTful API，curl 就可以操作。因為簡單，所以幾乎這種程式語言已都有 API 可用。
• document based data，不需要事先定義 field / column (我覺得這也可以算是一個缺點)
• 隨時調整 searchable / sortable / displayable doument field
• 內建 dump & snapshot

缺點：

• 覺得算是一個迭代速度蠻快的專案，所以文件沒有很完整 (或說明不好找)
• 透過 master key 和 API key 來限制使用、操作，略顯不足
• 部份覺得蠻重要的功能尚在開發中，例如透過 rank 來排序之類的
• 查詢功能、查詢結果列表有一些限制，但可以透過其他功能來避免 (known limitations)

Meilisearch 的社群蠻活躍的，歡迎大家參與討論 -> Meilisearch Roadmap

這邊用 PHP 實作，可以自己改成其他程式語言。

主要是使用 \r 來回到行首，然後使用新的文字蓋過原有的文字，就可以出現簡單的圖形變換效果：

$symbol = ['\\', '|', '/', '-'];

$count = 0;
echo "\n";
while(1) {
    echo "\rpending ..." . $symbol[$count % 4] ;

    $count++;
    sleep(1);
}

不知道有沒有什麼其他符號看起來比較清楚的？ O_Oa

一般在賣場結帳時，會看到店員翻轉商品並掃描張由直線組成的條碼，掃描完成收銀機便可立即顯示出商品名稱以及售價。近一年因 COVID-19 而要求大家進入公共場所需要掃描的 QR code 也是條碼的一種，只是單位面積可以儲存的資料量更多 (資料密度更高)。以下貼出幾種常見的圖形條碼。

「一維條碼」指的就是這種條碼只由直線組合而成，常見的商品條碼就是條碼的一種。依照不同的檢查碼、線條格式等，還可以細分成很多種，但大致上就是長得像 UPC code 這樣：

由於在相同面積，一條條碼可以儲存的資料有限，所以後來做出了 PDF 417 這種以方格組成的條碼：

接著為了更複雜的需求 (快速辨識圖形方向、容忍變形、容忍圖形毀損等等)、提高資料密度，開始出現了設計不一樣的長形、方形條碼 (二維條碼)，最常見的就是 QR code：

再來還有幾個比較少見的圖形條碼，像是 Datamatrix 和 MaxiCode：

在約 15 年前有嘗試想要自己做一個縮網址服務 (現在我做加長網址服務 XD)，當時用來產生 string ID 的方法有弱點，被學弟抓出來打爆 (可以被預測下一個產生出來的 ID，然後建立 unliminted redirection)。最近摸到 crunch 這個工具，在重新思考以後，終於搞清楚向 ppt.cc 請教時得到的說明是什麼意思。

先說明有問題的作法，先建立 valid characters list，URL 有部份特出字元是 reserve character (RFC3986)，所以像是 ?、=、@ 等字元有特殊用途不能被拿來當作參數傳遞，然後做「N 進位」轉成 string ID：

<?php

$char = ['a', 'b', 'c', '.....', '7', '8', '9', '0'];

例如：數字是 1 時，產生出來的 ID 是 a、數字是 116 時產生出來的 ID 是 a1。當時我是依照流水號，所以 ID 是可以被預測的，導致弱點被利用。

當時得到 ptt.cc 的回覆是「先產生完 key 再隨機選取可用的 key」。

這陣子才搞懂這個說明，先用 crunch 之類的工具把所有可用的 string 都先產生出來，然後需要時再隨機選取一個 string 來當作 key/ID 使用。這個作法有些優點：

• 不需要先產生所有的 key，因為大概可以推算出大概可用的 ID 數量
• 隨機挑選 key 就無法被猜到未來會被用到的 key，不容易被攻擊

接下來要傷腦筋的，大概就是怎麼樣有效率的從 DB 隨機取 key 了。

ps. 目前使用 3 個 digits，大概就有 20 多萬個 unique string 可用了，爽。