数据共享-SQLite与共享内存IPC

我想听听您对数据共享设计实现的看法

我在Linux嵌入式设备（mips 200 Mhz）上工作，我想在多个进程之间共享某种数据，可以同时读取或写入多个参数

该数据包含约200个字符串参数，这些参数每秒更新一次。 进程可在1秒内访问约10次数据

我非常想尝试使设计高效（CPU/Mem）

此数据不需要是持久的，每次重新启动时都会重新创建

目前，我正在考虑两种选择：

使用分片内存IPC（SHM）+信号量（锁定所有SHM）

使用基于SQLite内存的数据库

对于任一选项，我将提供一个C接口库，它将执行DB操作的所有逻辑

对于SHM，这意味着锁定/解锁信号量并访问可称为索引数组的参数

对于SQLite，我的库将是SQLite接口库的包装器，因此流程不必知道SQL语法（应该对查询和回复进行一些解析）

我认为共享内存更有效：

不需要使用和解析SQL，它可以作为数组访问

尽管如此，使用SQLite也有一些优点： 已工作并调试（数据库级）。 增加灵活性。 广泛应用于许多嵌入式系统中

开门见山

就性能而言，我没有使用SQLite的经验，如果您能分享您的意见和经验，我将不胜感激

---

谢谢，SQLite的内存中数据库不能在进程之间共享，但是您可以将DB文件放入

tmpfs

---

但是，SQLite不会在进程之间进行任何同步。它确实会锁定DB文件以防止更新冲突，但如果一个进程发现该文件已被锁定，它只会随机等待一段时间

---

为了实现进程之间的高效通信，您需要使用SHM/信号量或管道之类的机制。

那么，要求是什么？SHM（直接暴露“原始位”）与DBMS（暴露“信息”、ACID等）完全不同。此外，SQLite依赖于文件锁，写/写/读争用是SQLite的“弱点”之一；获得锁时的行为/语义在网站上有很好的文档记录。还有其他（更快，但不一定是关系型的）数据库系统-也称为BDB风格-可能更适合，并且也经过了很好的测试。它们的开销比SQLite少得多，SQLite可以在“非常慢”（如今天的标准）的系统上发挥作用。（我可能会从SHM或a开始。如果需要，前者将允许细粒度/自定义锁定，但只需要稍微多做一点工作。我不会担心后者的性能；性能数字将告诉您是否应该这样做。）[have]，但在这一阶段，让它工作起来要重要得多。）一般来说，要求从设备收集不同的参数（存储在内核/其他内核/文件等的不同位置）。这将通过收集进程（写入数据）来完成然后，为了能够在一个中心位置和一个API中公开数据，这些数据应该可以通过web UI等进程轻松访问。为了“轻松处理”，DBD样式的DB在编写和读取键值对方面胜过SHM：）现在，SQLite（有了它的SQL语法，虽然现在可以在官方BDB上使用SQLite，但我相信对于$$$来说）在进行关系查询时具有最大的优势。如果键-值对在[自我管理]层次模型中足够，那么关系查询就没有什么好处。“SQLite不会在进程之间进行任何同步。它会锁定DB文件以防止更新冲突”这是一个矛盾：两个进程访问的文件上的锁定是这些进程之间同步的一种形式。我相信锁定是在表级别上的”如果一个进程发现文件已被锁定，它将随机等待一段时间"这听起来不太可能，我认为SQLite要求操作系统在释放锁时发出通知。锁定，而不是在进程级别；这意味着即使是同一进程中的两个连接也将使用文件锁定。请参阅：没有解锁通知。表锁定仅在共享缓存模式下使用，即，当ame进程同意共享对同一数据库的访问。