嗨，开发者！
我是 Alex，一名技术爱好者。我很高兴向您展示 Jinbase，我的多模型事务嵌入式数据库。
大约一年前，我介绍了 Paradict，这是我对多格式流序列化的看法。鉴于其可读性，Paradict 文本格式实际上是配置文件的一种有趣的数据格式。但是使用 Paradict 来管理配置文件最终会使其编程界面变得混乱，并使那些仍然可以选择专用于配置文件的替代库（TOML、INI 文件等）的用户感到困惑。所以我使用 Paradict 作为 KvF（键值文件格式）的依赖项，这是我的一个新项目，专注于带有部分的配置文件。
凭借其紧凑的二进制格式，我认为 Paradict 将成为一个新项目的有效依赖项，该项目将依赖 I/O 函数（例如 Open、Read、Write、Seek、Tell 和 Close）来实现简约但可靠的功能持久性解决方案。但那是在我了解到“文件很难”之前。 sqlite 及其事务、BLOB 数据类型和 BLOB 的增量 I/O 似乎是我的新项目的正确选择。
Jinbase 最初只是一个键值存储，最终成为一个多模型嵌入式数据库，突破了我们通常使用 SQLite 所做的事情的界限。当我意识到键值存储不太适合为每个新记录自动生成唯一标识符 (UID) 的情况时，第一次转换到第二个数据模型（仓库），从而为用户节省了时间提供可能意外发生冲突并因此覆盖现有记录的标识符的负担。之后，我实现了一种搜索功能，该功能接受仓库存储的 UID 范围、仓库和键值存储的时间跨度（记录自动带有时间戳）以及键值存储中字符串和整数键的 GLOB 模式和数字范围.
队列和堆栈数据模型是作为必须按特定顺序使用记录的用例的解决方案而出现的。典型的记录将在单个事务单元中从数据库中检索和删除。
由于使用SQLite作为存储引擎，Jinbase事实上支持关系模型。为了方便起见，与 Jinbase 内部相关的所有表都以 jinbase_ 为前缀，这使得 Jinbase 成为打开旧版 SQLite 文件以添加与临时关系模型安全共存的新数据模型的有用工具。
所有四种主要数据模型（键值、仓库、队列、堆栈）都支持与 Paradict 兼容的数据类型，例如字典、字符串、二进制数据、整数、布尔值、日期时间等。在幕后，当用户发起写操作，Jinbase 会迭代序列化（二进制数据除外）、分块并存储数据。一条记录不仅可以批量访问，还可以有两种级别的部分访问粒度：字节级和字段级。
虽然 SQLite 的 BLOB 增量 I/O 旨在针对一行中的单个 BLOB 列，但 Jinbase 对此进行了扩展，以便对于每个记录，增量读取覆盖所有块，就好像它们是单个统一的 BLOB 一样。仅对于字典记录，Jinbase 自动创建并维护一个由指向根字段的指针组成的轻量级索引，然后允许从任意记录中提取在返回之前自动反序列化的字段内容。
Jinbase 最明显的用例是存储用户首选项、退出前保留会话数据、基于顺序的数据流处理、向其他进程公开数据、使用新数据模型升级旧版 SQLite 文件以及定制数据持久性解决方案。
Jinbase 用 python 编写，可在 PyPI 上使用，您可以使用 README 中的示例。
让我知道您对这个项目的看法。
