標籤: 資訊學習

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 可用了，爽。

這幾天被感冒的一些病狀搞到實在很不舒服，誰身酸痛不說，喉嚨雖然沒有很痛，但整個乾得很難說話。

另外就是整個體力下降，本來要去公司撐的一、二天，結果出門時發現連機車都快牽不動，只好乖乖請假在家。

在網路上找到了一些區分一般感冒與流行性感冒 (流感) 差異的說明，簡單練出幾個差異比較大的症狀，如下 (Blogger 居然不支援畫表格 ….QQ)：

節錄，詳細內容請看「蒼藍鴿的醫學天地」

影片：感冒？流感？ 差別到底是什麼！？

症狀	一般感冒	流感
影響範圍	呼吸道局部症狀	全身性
發病速度	突發、漸進式	突發性
發病症狀	喉嚨痛、打噴嚏、流鼻涕	喉嚨痛、肌肉酸痛、倦怠
發燒	少發燒、或僅體溫稍微升高	發高燒

ps. 感謝 emmet 贊助畫表格 QQ

這次自己判斷可能還沒有到流感，暫時請狂睡，外加補充水份和維他命，希望週末、週日就可以恢復正常。

另外也感謝同事幫我把工作 hold 住，不然我應該會掛彩吧