2024年最全嵌入式数据库（Embedded Database）_嵌入式数据库有哪些，你值得拥有

最新推荐文章于 2024-08-29 21:07:49 发布

2401_85015212

最新推荐文章于 2024-08-29 21:07:49 发布

阅读量1.3k

点赞数 24

分类专栏：程序员文章标签：物联网嵌入式硬件学习

本文链接：https://blog.csdn.net/2401_85015212/article/details/138832698

版权

程序员专栏收录该内容

16 篇文章 0 订阅

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上物联网嵌入式知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、电子书籍、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

高度灵活的SQL接口
优秀的掉电恢复能力
强壮的交易和锁存机制
支持SCSI,RAID,IDE,RAM,CD-RW,DVD-ROM,CF,等存储介质
支持Unicode 码
引擎可加载于磁盘和内存

eXtremeDB eXtremeDB特点：

内存数据库，eXtremeDB将数据以程序直接使用的格式保存在主内存之中，不仅剔除了文件I/O的开销，也剔除了文件系统数据库所需的缓冲和Cache机制。其结果是每个交易一微秒甚至更少的极限速度，相比于类磁盘数据库而言，速度成百上千倍地提高。作为内存数据库，eXtremeDB不仅性能高，而且数据存储的效率也非常高。为了提高性能并方便程序使用，数据在eXtremeDB中不做任何压缩，100M的空间可以保存高达70M以上的有效数据，这是其他数据库所不可想象的。
混合数据库，eXtremeDB不仅可以建立完全运行在主内存的内存数据库，更可以建立磁盘/内存混合介质的数据库。在eXtremeDB，我们把这种建立在磁盘、内存或磁盘+内存的运行模式称为eXtremeDB Fusion融合数据库。eXtremeDB Fusion兼顾数据管理的实时性与安全性要求，是实时数据管理的台阶性进步。
嵌入式数据库，eXtremeDB内核以链接库的形式包含在应用程序之中，其开销只有50KB~130KB。无论在嵌入式系统还是在实时系统之中，eXtremeDB都天然地嵌入在应用程序之中，在最终用户毫不知情的情况下工作。eXtremeDB的这种天然嵌入性对实时数据管理至关重要：各个进程都直接访问eXtremeDB数据库，避免了进程间通信，从而剔除了进程间通信的开销和不确定性。同时， eXtremeDB独特的数据格式方便程序直接使用的，剔除了数据复制及数据翻译的开销，缩短了应用程序的代码执行路径。
由应用定制的API，应用程序对eXtremeDB数据库的操作接口是根据应用数据库设计而自动产生，不仅提升了性能，也剔除了通用接口所必不可少的动态内存分配，从而提高了应用系统的可靠性。定制过程简单方便，由高级语言定制eXtremeDB数据库中的表格、字段、数据类型、事件触发、访问方法等应用特征，通过eXtremeDB预编译器自动产生访问该数据库的C/C++ API接口。
可预测的数据管理 eXtremeDB独特的体系结构，保证了数据管理的可预测性。eXtremeDB不仅更快、更小，而且更确定。在80双核CPU的服务器上，eXtremeDB在1TB内存里保存15B条记录；无论记录数多少，eXtremeDB可以在八十分之一微秒的时间内提取一条记录。

Firebird嵌入服务器版（Embedded Server）

从Interbase开源衍生出的Firebird，充满了勃勃生机。虽然它的体积比前辈Interbase缩小了几十倍，但功能并无阉割。为了体现Firebird短小精悍的特色，开发小组在增加了超级服务器版本之后，又增加了嵌入版本，最新版本为2.0。

Firebird的嵌入版有如下特色：

1、数据库文件与Firebird网络版本完全兼容，差别仅在于连接方式不同，可以实现零成本迁移。

2、数据库文件仅受操作系统的限制，且支持将一个数据库分割成不同文件，突破了操作系统最大文件的限制，提高了IO吞吐量。

3、完全支持SQL92标准，支持大部分SQL-99标准功能。

4、丰富的开发工具支持，绝大部分基于Interbase的组件，可以直接使用于Firebird。

5、支持事务、存储过程、触发器等关系数据库的所有特性。

6、可自己编写扩展函数(UDF)。

UnQLite

由 Symisc Systems公司出品的一个嵌入式C语言软件库，它实现了一个自包含、无服务器、零配置、事务化的NoSQL数据库引擎。UnQLite是一个文档存储数据库，类似于MongoDB、Redis、CouchDB等。同时，也是一个标准的Key/Value存储，与BerkeleyDB和LevelDB等类似。

UnQLite是一个嵌入式NoSQL（键/值存储和文档存储）数据库引擎。不同于其他绝大多数NoSQL数据库，UnQLite没有一个独立的服务器进程。UnQLite直接读/写普通的磁盘文件。包含多个数据集的一个完整的数据库，存储在单一的磁盘文件中。数据库文件格式是跨平台的，可以在32位和64位系统或大端和小端架构之间，自由拷贝一个数据库。UnQLite的主要特点，如下：

无服务器数据库引擎。
事务化(ACID)数据库。
零配置。
单一数据库文件，不使用临时文件。
跨平台的文件格式。
UnQLite是一个自包含的C语言程序库，无任何外部依赖。
标准的Key/Value存储。
基于Jx9的文档存储(JSON)数据库。
支持游标，满足线性记录遍历。
插件式运行时可交换存储引擎。
支持磁盘持久化和内存模式的数据库。
内建强大的磁盘存储引擎，支持O(1)查询。
线程安全，完全可重入。
简单、清晰，很容易使用的API。
支持TB（Terabyte）尺寸的数据库。
采用BSD开源许可协议。
合并：UnQLite和Jx9相关所有C源代码文件，都合并到单一的文件中。
很好的在线支持。

UnQLite是，一个自包含的C库，无外部依赖。它要求非常小的外部库或来自操作系统的支持。特别适合应用于嵌入式设备，也适用于应用程序内部（那些需要运行于大量的计算机，而无需修改各种配置）。

UnQLite是，100%手工编码，使用ANSI C，线程安全，完全可重入，编译无需修改，而且可运行于绝大多数的平台，包括受限的嵌入式设备，仅需要一个C编译器。UnQLite已经在非常广泛的平台进行了测试，包括Windows和UNIX系统，特别是Linux、FreeBSD、Oracle Solaris及Mac OS X。

UnQLite是，一个标准的key/value存储，与BerkeleyDB和LevelDB等相似。但是，拥有更加丰富的特性集，包括支持事务（ACID），并发读等。在KV存储下，键和值都被视为简单的字节数组，所以内容可以是任何东西，包括ASCII字符串、二进制对象和磁盘文件等。应用程序，可以通过接口API来访问KV层，包括

unqlite_kv_store() unqlite_kv_append() unqlite_kv_fetch_callback() unqlite_kv_append_fmt() unqlite_kv_delete() 等等。

UnQLite用来在数据库中存储JSON文档（如，对象、数组、字符串等）的文档存储接口，是通过Jx9编程语言支撑/实现的。Jx9是一种嵌入式的脚本语言，也叫扩展语言，被设计用于通用过程化编程，具备数据表述的特性。Jx9是一个图灵完备（Turing-Complete），基于JSON的，动态类型编程语言，作为UnQLite内核的一个库而存在。

总之，UnQLite一块开源软件，在 2-Clause BSD协议下开放源代码。

需要比较的：

Berkeley DB

SQLite

UnQLite

SQLite VS UnQLite

https://stackshare.io/stackups/sqlite-vs-unqlite#description

总的来说，相较于UnQLite,选择SQLite的公司更多

SQLite VS Berkeley DB

SQLite更适合数据集少的单线程的数据存储

以下来自Stateflow的回答：

 I participated in the beta evaluation of the BDB SQLite code and one of the things I tried to get a handle on was the performance difference. At this point, I cannot publish exactly what I found until I have at least one other person evaluate my code, run the tests, and confirm the numbers I got (which is being done). However, I can generalize here and say that there are cases where BDB offers significant performance improvements over SQLite, specifically in the area of handling heavy loads that involve write-concurrency.
 
 There are, generally, two measures of "fast" right -- (1) efficiency: how long does it take for a single process to do XYZ vs. (2) concurrency: how many times can many processes do XYZ per unit time. The main problem BDB addresses is concurrency -- large-scale transaction processing. Thus you think of many concurrent connections writing to and/or modifying the contents of the database.
 
 SQLite by design uses database-level locking so there is a maximum of one writer who can be working in the database at a time. Thus, SQLite's transaction rate stays more or less constant with the number of concurrent connections, so it's scalability in write-intensive applications is really measured by its efficiency (1).
 
 BDB on the other hand uses page level locking, which allows multiple writers to be working in the database at a given time (provided that they are working on separate pages). Thus BDB's rate potentially increases with the number of connections and so its scalability is both a matter of efficiency (1) and concurrency (2), which can add up.
 
 Mainly what it boils down to is (write) concurrency. BDB can push more TPS than SQLite for multiple writers. By transaction, I mean something that modifies the database (how are they of any real help for read-only operations?). That said, for read concurrency (apps that mainly do SELECTs), SQLite could very well go head to head with BDB because locking is no longer a critical issue.
 
 As for the size of the dataset, I am not sure. I've not looked into that. Ultimately, they both use B-trees for storage. There may be factors in their respective implementations to consider, but I've not investigated that. I know that SQLite can gracefully handle data sets into the hundreds of MBs and double digit GBs (and perhaps more now that the dirty page map implementation has been changed).
 
 Therefore, if you have an application which employs many connections that modify a given database and page contention is relatively low, then BDB can offer significant performance improvements. But page contention is a critical variable. In the limit, if you had a BDB database whose data consisted of a single page, then its performance would match that of SQLite in all cases because page-level locking here effectively degenerates into the equivalent of database level locking -- everybody is fighting over one thing. However, as the number of pages increases in BDB (and page contention decreases), then the maximum TPS will start to grow with the number of concurrent connections. Then from that point, memory becomes the next limiting factor. But that's another story.
 
 BTW, I am in the process of writing an article about using BDB for those coming from SQLite.

收集整理了一份《2024年最新物联网嵌入式全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升的朋友。