nark 資料庫簡介，nark資料庫

nark 資料庫簡介，nark資料庫

本文是本人原創，來自本人的公司網站：http://nark.cc/p/?p=1560

不同於普通 Hash 或 Tree 結構的資料庫，nark 資料庫是基於自動機的，這決定了 nark 的強大與簡潔，但是，最重要的是，nark 為大家提供了一整套解決方案。

因為自動機只有離線(offline)建立成唯讀資料庫，才能為線上(online)計算 提供 最節省記憶體 並且 高速尋找 的 功能。從而，絕大部分 nark 組件都分為離線(offline)建庫 和 線上(online)搜尋 兩部分。

目前，離線建庫以可執行程式的形式向所有使用者開放，線上搜尋以 C++ API 的形式僅向付費使用者開放。

為了讓所有使用者在付費前體驗 nark 的高效能，下載包中也包含了一些樣本程式，大部分樣本程式同時也是 benchmark 程式，所有使用者都可以在自己的機器上運行這些樣本程式。同時，這些樣本程式的代碼也向所有使用者開放，但只有付費使用者才能自己編譯這些樣本程式，因為需要 C++ API 。

nark 是如何的強大

作為 NoSQL 資料庫
智能錯誤修正	Demo 見首頁，這本質上可以認為是用Regex尋找資料庫，不過這個“Regex”不是人手寫的，而是從搜尋字詞建立了一個DFA， 這個DFA自然有某Regex與它對應。
規則引擎	每條規則是一個進階Regex，假如配置了10萬條規則，現在有一個字串(比如一條網路訊息)，要看這個字串能匹配那個(或哪些)規則，nark 規則引擎只需要幾微秒的時間就能得到結果。應用案例：某互連網公司的查詢詞分類、某自然語言處理應用中的，某手機簡訊分析應用、某網路裝置商的入侵檢測…… 一個簡化的情境是規則只包含需要精確匹配的二進位串，可以使用 nark AC自動機，Benchmark 中 2000 個 pattern ， 匹配效能高達 720MB/s
用於NLP (自然語言處理)	把大量語料（例如: N-Gram）壓縮到一個DFA中，既有強大的匹配能力，又大大減小記憶體用量（或者換句話說，使用相同的記憶體裝入更多語料）。 把很多複雜的計算問題簡化為（匹配 + 簡單的計算），等等
用于海量 小檔案壓縮	在小檔案儲存體中，使用主流的壓縮演算法，要即時讀取單個小檔案，就只能壓縮檔內的冗餘，檔案之間的冗餘無法壓縮 使用 rltzip ，可以高效壓縮海量小檔案，並且高速讀取單個小檔案(相當於僅解壓一個檔案) 搜尋引擎的正排表是一個典型的現實案例

nark 核心 API

抽象介面	功能
DFA_Interface	首碼搜尋、Key-Value 搜尋、Key 存在性檢驗
DAWG_Interface	首碼搜尋、字串 Key 和 整數 Index 互相轉化，Index 是 Key 在整個資料庫中的排序序號：從 0 到 n-1。 要實現 Map<Key,Value> 的功能，可以將 Value 儲存在外部一個數組中，用 Index 訪問；這就有了另外一種能力：修改 Value
SuffixCountableDAWG	DAWG_Interface 的派生介面，新增功能：高速擷取指定首碼的所有不同尾碼的數量
AC_Scan_Interface	AC 自動機多模匹配：在整個輸入資料中搜尋多個 Pattern 的出現位置

nark 離線建庫程式
adfa_build

用來從文字檔建立 (Key, Value) 資料庫，(Key, Value) 都是字串。文字檔中每行是一條 (Key, Value) 記錄，一般情況下 (Key, Value) 之間使用 \t 分隔，第一個 \t 之前的是 Key，之後的是 Value，Value 中也可以包含 \t。

這個程式產生的 dfa 資料庫僅支援 DFA_Interface 介面。

這個程式適合用來建立 (Key, Value) 集合有組合特徵的輸入，當你不能確定這一點時，可以嘗試 rptrie_build，看產生的 dfa 資料庫檔案是否更小。

dawg_build

用來從文字檔建立 (Key, Index) 資料庫，文字檔中每行的全部內容被當作一個Key。產生的 dfa 資料庫同時支援 DFA_Interface 和 SuffixCountableDAWG。

DAWG 的全稱是 Directed Acylic Word Graph。

• 在 DAWG 中，一個 Key 對應的 Index 是這個 Key 在整個 Key 集合中的字典序的序號(0 ~ n-1)
• 只有當 Key 集合有高度組合特徵時，這種資料庫的壓縮率才更高
• 根據以往經驗，DAWG 的適用範圍要小於 adfa 和 rptrie

rptrie_build

這個程式也用來從文字檔建立 (Key, Value) 資料庫，很多情況下產生的資料庫檔案比 adfa_build 要小，並且功能更豐富，支援 DFA_Interface 和 DAWG_Interface。

這種資料庫並不是 Directed Acylic Word Graph，但是它也可以實現 Key 和 整數 Index 之間的互相映射，這個 Index 不是字典序，而是 KeyLen+字典序，可以用以下代碼產生這樣的序列：

先比較長度，再按字典序比較內容

從名字可以看出，這種資料庫本質上是一種 trie 樹。但是相比雙數組(DoubleArray) Trie，這種 trie 的尺寸大約要小30倍，甚至300倍也有可能。當然，速度比 DoubleArray Trie 要慢不少，根據資料和應用情境的的不同，大約在 3~10 倍之間。

雖然這種資料庫比 adfa 擁有額外的能力(Key 和 Index 互相轉化)，但是很多時候尺寸竟然還更小，並且速度更快，似乎有點違反直覺，但事實確實如此。

只有在資料有大量組合特徵時，rptrie 才比 adfa 尺寸更大。在理論上 rptrie 的壓縮率是線性，adfa 是指數的，但實際資料的冗餘更多情況下的是線性，不是指數的。

因為 rptrie 有以上優點，以下兩種使用方式都很適合：

1. 文字檔每行是一條 (Key, Value) 記錄，通常使用 DFA_Interface 介面
2. 文字檔每行僅包含一個 Key，而無 Value，通常使用 DAWG_Interface，如果 Value 需要修改，就只能使用這種方式
3. 這種資料庫不是 SuffixCountableDAWG，幸運的是，這個功能大多數應用都不需要

rltzip

使用與 rptrie_build 相同的演算法，壓縮大量小檔案（目前單個檔案最大長度限制為16M），檔案數量越多，壓縮率越高，特別是對文字檔。

產生的 dfa 資料庫檔案格式與 rptrie_build 完全相同。我曾使用 rltzip 把總共 58G 的 300萬個json小檔案壓縮到 7G 的單個 rptrie 。

rltunzip

按檔案名稱從 rltzip 產生的資料庫中解壓/讀取

regex_build

這個是規則引擎建庫工具

 

 更多文檔，正在撰寫中……