database 嵌入式的“最佳”数据库是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2011724/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What's the "best" database for embedded?
提问by Mawg says reinstate Monica
I'm an embedded guy, not a database guy. I've been asked to redesign an existing system which has bottlenecks in several places.
我是嵌入式人员，而不是数据库人员。我被要求重新设计一个在几个地方存在瓶颈的现有系统。
The embedded device is based around an ARM 9 processor running at 220mHz.
嵌入式设备基于运行频率为 220mHz 的 ARM 9 处理器。
There should be a database of 50k entries (may increase to 250k) each with 1k of data (max 8 filed). That's approximate - I can try to get more precise figures if necessary.
应该有一个包含 50k 个条目（可能增加到 250k）的数据库，每个条目有 1k 个数据（最多 8 个归档）。这是近似值 - 如有必要，我可以尝试获得更精确的数字。
They are currently using SqlLite 2 and planning to move to SqlLite 3.
他们目前正在使用 SqlLite 2 并计划迁移到 SqlLite 3。
Without starting a flame war - I am a complete d/b newbie just seeking advice - is that the "best" decision? I realize that this might be a "how long is a piece of string?" question, but any pointers woudl be greatly welcomed. I don't mind doing a lot of reading & research, but just hoped that you could get me off to a flying start. Thanks.
没有开始火焰War - 我是一个完整的 d/b 新手，只是寻求建议 - 这是“最好的”决定吗？我意识到这可能是“一根绳子有多长？” 问题，但任何指针都将受到极大欢迎。我不介意做大量的阅读和研究，但只是希望你能让我有一个良好的开端。谢谢。
p.s Again, a total rewrite, might not even stick with embedded Linux, but switch to eCos, don't worry too much about one time conversion between d/b formats. Oh, and accesses should be infrequent, at most one every few seconds.
ps 再次完全重写，甚至可能不会坚持使用嵌入式 Linux，但切换到 eCos，不要太担心 d/b 格式之间的一次转换。哦，访问应该是不频繁的，最多每隔几秒一次。
edit: ok, it seems they have 30k entries (may reach 100k or more) of only 5 or 6 fields each, but at least 3 of them can be a search key for a record. They are toying with "having no d/b at all, since the data are so simple", but it seems to me that with multiple keys, we couldn't use fancy stuff like a quicksort() type search (recursive, binary search). Any thoughts on "no d/b", just data-structures?
编辑：好的，似乎他们有 30k 个条目（可能达到 100k 或更多），每个条目只有 5 或 6 个字段，但其中至少有 3 个可以作为记录的搜索键。他们正在玩弄“根本没有 d/b，因为数据很简单”，但在我看来，对于多个键，我们不能使用像 quicksort() 类型搜索（递归、二分搜索）这样的花哨的东西）。关于“没有 d/b”的任何想法，只是数据结构？
Btw, one key is 800k - not sure how well SqlLite handles that (maybe with "no d/b" I have to hash that 800k to something smaller?)
顺便说一句，一个键是 800k - 不确定 SqlLite 处理得如何（也许在“没有 d/b”的情况下，我必须将 800k 散列到更小的值？）
回答by Valentin
Also SQLite is the Database chosen by virtually all mobile operating systems. Android, Iphone OS and Symbian ship with SQLite which makes me think that manpower was spent to optimize it for the processor in those phones (nearly always ARM).
SQLite 也是几乎所有移动操作系统都选择的数据库。Android、Iphone OS 和 Symbian 随附 SQLite，这让我认为人力被用于为这些手机（几乎总是 ARM）中的处理器优化它。
回答by selfawaresoup
I would stick with SQLite, it's widely supported and pretty rich in features.
我会坚持使用 SQLite，它得到了广泛的支持并且功能非常丰富。
回答by Carl Smotricz
Firebird (previously Interbase) claims to work well embedded.
HypersonicQL (HQL) is small and fast and also claims to be suitable for embedded use.
Firebird（以前称为 Interbase）声称可以很好地嵌入。
HypersonicQL (HQL) 体积小、速度快，还号称适合嵌入式使用。
Alas, I have no personal experience to back up either claim.
唉，我没有个人经验来支持这两种说法。
回答by figurassa
SQLite is probably a pretty safe bet. However, if performance is really important for your application and you do not need a relational database, I would suggest you take a look at Berkeley DB link text. Berkeley DB is not a relational database though. In other words, if your data is grouped in different tables and you constantly need to query result sets that require relating data from more than one table, you probably need a relational database. Berkeley DB is better suited for something like look up tables (i.e., the data is organized in a few tables and you don't need to query data from more than one of them in order to produce the result sets you want). Berkeley DB is very fast but it will require more work on your end in order to get the most out of it.
SQLite 可能是一个非常安全的赌注。但是，如果性能对您的应用程序真的很重要并且您不需要关系数据库，我建议您查看 Berkeley DB链接文本。虽然 Berkeley DB 不是关系数据库。换句话说，如果您的数据分组在不同的表中，并且您经常需要查询需要来自多个表的相关数据的结果集，那么您可能需要一个关系数据库。Berkeley DB 更适合于查找表之类的事情（即，数据组织在几个表中，您不需要从多个表中查询数据即可生成您想要的结果集）。Berkeley DB 速度非常快，但您需要做更多的工作才能充分利用它。
回答by James
if you want an alternative, then berkeleydbis worth looking at. it used to be owned by sleepycat software, but is now available from oracle. it's a barebones database engine; is directly programmable (rather than a sql) frontend. it's used as part of the core engine in many major databases, and as the database in many embedded devices - it used to be particularly popular for managing routing tables in routers. it tends to get overlooked these days for more fashionable setups, but i've found it to be decent, solid and for the numbers you are talking about it can be lightning fast.
如果你想要一个替代方案，那么berkeleydb值得一看。它曾经由 sleepycat 软件拥有，但现在可以从 oracle 获得。它是一个准系统的数据库引擎；可直接编程（而不是 sql）前端。它被用作许多主要数据库的核心引擎的一部分，以及许多嵌入式设备中的数据库 - 它曾经特别流行用于管理路由器中的路由表。如今，对于更时尚的设置，它往往会被忽视，但我发现它是体面的、可靠的，而且对于您所谈论的数字，它可以是闪电般的快速。
回答by jRam90
SQLite is ok, but don't plan to use if you plan to insert, update and delete data that involves more that 6 millon rows(All at the same time, or any partial part). The thing is that the VACCUM keyword has to be done everynow and then and it becomes a very severe bottleneck for performance, even when it's automatic.
SQLite 是可以的，但如果您打算插入、更新和删除涉及超过 6 百万行的数据（同时全部或任何部分），则不打算使用。问题是 VACCUM 关键字必须时不时地执行，它成为性能的一个非常严重的瓶颈，即使它是自动的。
回答by Fredrik S
8 Years late, but as an update: I've had pretty good experience using Raima Database Manager. If you are looking for a small footprint db, they can get down to 40k. One of the reasons I like RDM is the platform independence, it is portable across 32-bit and 64-bit machines and between big-endian and little-endian architectures as well as support for most operating systems, meaning you can use it on Embedded Linux and eCos as mentioned in the first post. And it's performance gets better as you add better hardware and users as opposed to SQLite
晚了 8 年，但作为更新：我在使用Raima Database Manager方面有很好的经验。如果您正在寻找占用空间较小的数据库，它们可以降至 40k。我喜欢 RDM 的原因之一是平台独立性，它可以在 32 位和 64 位机器之间以及大端和小端架构之间移植，并且支持大多数操作系统，这意味着您可以在嵌入式系统上使用它第一篇文章中提到的 Linux 和 eCos。当你添加更好的硬件和用户而不是SQLite 时，它的性能会变得更好
回答by sagasw
I will suggest sqlite3 too. It is used by many famous application.
我也会推荐 sqlite3。它被许多著名的应用程序使用。
回答by joetsuihk
回答by tkyle
The 01-11-10 Embedded.com Newsletter does a nice job of covering this topic. The newsletter can be found at Embedded.com: Embedded.com Tech Focus Newsletter (1-11-10): Embedding Databases.
01-11-10 Embedded.com 时事通讯很好地涵盖了这个主题。该通讯可在 Embedded.com 上找到：Embedded.com Tech Focus Newsletter (1-11-10): Embedding Databases。
