我是嵌入式人,而不是数据库人。我被要求重新设计在多个地方存在瓶颈的现有系统。
该嵌入式设备基于运行频率为 220mHz 的 ARM 9 处理器。
应该有一个包含 50k 个条目(可能增加到 250k)的数据库,每个条目包含 1k 个数据(最多 8 个字段)。这是近似值 - 如果需要,我可以尝试获得更精确的数字。
他们目前正在使用 SqlLite 2 并计划迁移到 SqlLite 3。
没有开始一场激烈的战争——我是一个完全的 d/b 新手,只是在寻求建议——这是“最好”的决定吗?我意识到这可能是“一根绳子有多长?” 问题,但任何指针都将受到极大的欢迎。我不介意做大量的阅读和研究,但只是希望你能让我有一个好的开始。谢谢。
ps 再次,完全重写,甚至可能不坚持嵌入式Linux,而是切换到eCos,不要太担心d/b格式之间的一次转换。哦,访问应该不频繁,最多每隔几秒一次。
编辑:好的,似乎他们有 30k 个条目(可能达到 100k 或更多),每个条目只有 5 个或 6 个字段,但其中至少 3 个可以作为记录的搜索键。他们正在玩弄“根本没有 d/b,因为数据是如此简单”,但在我看来,对于多个键,我们不能使用诸如 quicksort() 类型搜索(递归、二进制搜索)之类的花哨的东西)。关于“无 d/b”的任何想法,只是数据结构?
顺便说一句,一个键是 800k - 不确定 SqlLite 处理得有多好(也许使用“no d/b”我必须将 800k 散列到更小的值?)