sqlite-collections

Rust集合类型，由sqlite数据库文件支持。

这提供了一些类似标准库的集合，可以使用任意序列化器进行序列化和反序列化。这使得您可以使用与 std::collections 类似的接口，具有以下特点

• 您可以在不序列化和反序列化整个集合的情况下将集合持久化到磁盘。与仅使用 serde 加载和转储整个内容相比，打开非常大的集合并进行小修改非常高效。
• 您可以存储非常大的结构，大小可以处理硬盘大小，而不仅仅是内存。这以与普通SQLite相同的方式处理数百GB。
• 您可以使用事务和保存点来回滚对任何或多个集合的更改。
• 您可以跨多个文件保持集合，并保持它们的整体事务完整性。

可移植性和稳定性

ds::set::DSSet 和 ds::map::DSMap 类型依赖于确定性序列化。您不会被阻止在Set中存储任何可序列化的内容，例如，但请注意

• 如果您存储类似于HashMap的内容，其顺序可能在运行之间发生变化。
• 某些格式对同一数据有多个表示。
  • Ciborium（cbor 功能）尚不支持半精度浮点数，因此将来添加它将破坏确定性。
    • 因此，ciborium没有实现CBOR的确定性编码。
  • serde_json选择在版本之间是否转义某些unicode值，也可能导致破坏。
  • 从另一种不按相同方式序列化的编程语言访问容器会导致问题
• 某些序列化器在不同架构上序列化的方式不同。如果您的序列化器在不同端序上表现不一致，则它不会在这些不同架构上具有可移植性。
• 某些数据类型在不同架构上不同，主要是 usize 和 isize。某些序列化格式将不同地编码这些。

为确保安全，请务必在彻底测试后更新序列化器。 Direct 始终安全。 postmark 可能是您能使用的最可靠的 serde 格式，但请注意不要依赖于使用 Hash 特性来确定排序的类型，除非您能确保单独的一致性顺序。 cbor 和 json 对跨语言使用很有用，但请注意警告，并确保其他语言以相同的方式序列化。

将来，将添加 BTreeSet 和 BTreeMap 以支持非确定性编码。这些将更慢，但将保证仅基于 Ord 和 Eq 来匹配。这不会解决平台可移植性问题，但会解决确定性序列化问题。

并发安全性

您的集合可能通过其他连接在不同线程或进程中打开。内部使用 SAVEPOINT 以防止不一致状态。

性能

此库使用内部 SAVEPOINT 以防止数据库状态不一致。为了在不牺牲可靠性的情况下获得最佳性能

• 在所有操作周围尽可能使用最大的事务。
• 当您知道将修改数据库时，请使用 IMMEDIATE 事务（升级事务可能导致死锁和错误）。
• 将数据库切换到 journal_mode = WAL 并使用 synchronized = NORMAL，当大量写入时可以提供一些性能提升。

集合

当前已实现

• DSSet
  • 一个常规集合，按存储表示法按字典顺序排序。
  • 需要确定性序列化。
  • 尚未完成。大部分必要功能已存在，但并非所有功能。

待实现

• DSMap
  • 一个常规映射，按键的存储表示法按字典顺序排序。
  • 需要确定性序列化。
• BTreeSet
  • 一个允许非确定性序列化的集合，只要实现了 Ord。应该比正常集合慢得多，因为每个比较都需要完全反序列化。
• BTreeMap
  • 一个允许非确定性序列化的映射。
• 列表
  • 一个按整数索引排序的序列。
  • 这不是 Vec，因为它实际上不是一个数组，也不能作为连续切片访问。
• Deque
  • 一个按整数索引排序的序列，两端都有高效的插入和删除。

我直接使用 SQLite 不行吗？

是的。这主要是为了让高效地与 SQLite 支持的集合交互变得容易，而无需过多考虑 SQL 细节，以及当需要持久性和/或大量数据而不填充 RAM 时，将现有的 std::collections 结构替换为不痛不痒的功能。

如果您真的只需要一个大型、持久和/或事务安全的集合，并且不需要任何其他 RDBMS 功能，则此库是一个不错的选择。