nark 数据库最重要的特性：高压缩并且拥有丰富、高效的查询能力。特别是高压缩，其他数据库都没有这个能力，你可能对此表示怀疑，本文提供的内容会打消你的疑虑。
实现上，不同于普通 Hash 或 Tree 结构的数据库，nark 数据库是基于自动机的，这决定了 nark 的强大与简洁，但是，最重要的是，nark 为大家提供了一整套解决方案。
因为自动机只有离线(offline)创建成只读数据库，才能为在线(online)计算 提供 最节省内存 并且 高速查找 的 功能。从而，绝大部分 nark 组件都分为离线(offline)建库 和 在线(online)搜索 两部分。
目前，离线建库以可执行程序的形式向所有用户开放，在线搜索以 C++ API 的形式仅向付费用户开放。
为了让所有用户在付费前体验 nark 的高性能，下载包中也包含了一些示例程序，大部分示例程序同时也是 benchmark 程序，所有用户都可以在自己的机器上运行这些示例程序。 继续阅读
描述 Double Array Trie 的文章有很多，我在这里从另一个视角来讲 Double Array Trie。首先，是 base 和 check 的更深层含义，然后再详细说一下由此引申出来的问题。 继续阅读
先强调一点，在我的引擎中，所有正则表达式的语法结构，包括 并、交、差、补 都是在编译时完成的，对匹配性能无任何影响，切记！…… 现在可以开始了：
正则表达式，描述的是正则语言， 学过形式语言与自动机理论的人应该都知道，正则语言在并、交、差、补运算下都是封闭的；但是，根据 Wikipedia 的描述，到目前为止，还没有任何一个已知的正则流派(Flavor)将交和差纳入正则语法。理论与实践之间竟然隔着这么巨大的鸿沟！
| 并： | A || B | 能匹配 A 或者能匹配 B | 这三种操作都可以编译为 DFA， 从而非常高效地执行匹配 |
|---|---|---|---|
| 交： | A && B | 能匹配 A 并且能匹配 B | |
| 差： | A &! B | 能匹配 A 但不能匹配 B，即从 A 中排除 B |
一直以来，自动机的创建程序（adfa_build/dawg_build/kvbin_build 等）性能虽然尚可，以最常用的 adfa_build 来说，根据不同的输入文本，平均吞度量能达到每秒钟 5~20M 。这个速度看上去还不错，至少比竞品要快了许多，但是，如果有非常大的数据 继续阅读
前段时间实现了基于 Succinct Data Structure 的自动机，这种自动机（内存）存储方式将状态转移的 label 单独存储起来，从而，查找 label 就是一个在 byte 数组中查找 byte 的操作，并且，绝大多数情况下，需要查找的这个 byte 数组都非常短（状态的平均转移(label)数一般情况下大约是 2 ）。 继续阅读
前一段时间，在将 多正则表达式匹配工具 用于数十万任意的正则表达式时，以前一直担心的问题终于出现了：NFA 转化 DFA 时的指数爆炸，那样的 DFA 根本创建不出来，因为那些正则表达式之间有不可预料的各种交集！ 继续阅读
