非常大的 NSDictionary vs Core Data vs SQLite 用于在 iPhone 上进行只读查找？答案

【问题标题】：Very large NSDictionary vs Core Data vs SQLite for read-only look up on iPhone?非常大的 NSDictionary vs Core Data vs SQLite 用于在 iPhone 上进行只读查找？
【发布时间】：2011-04-05 04:55:03
【问题描述】：

我正在修补一个 iPhone 单词应用程序，我在其中使用 DAWG 结构在用户键入时实时从用户定义的单词库中查找字谜。那部分效果很好。随着单词的识别，我想检索我当前在 plist 文件中拥有的每个单词的特定信息（按单词键控）。此信息需要导入并在应用启动时可用。

在启动时，我可以使用 initWithContentsOfFile 轻松地将 plist 准备为 NSDictionary 对象，但这会创建一个包含约 200,000 个键/值对的字典。我猜这不是最好的方法，因为 txt、bin 和 xml 格式的 plist 文件分别为 2.8 MB、3.9 MB 和 7.5 MB。

我应该使用 Core Data 还是 SQLite？我的首要任务是性能，因为如果可能的话，我想在用户键入时实时查找数以万计结果的信息。

谢谢

【问题讨论】：

标签： iphone sqlite core-data plist nsdictionary

【解决方案1】：

您只能通过尝试两种方法和分析（使用 Instruments.app）来回答性能问题。也就是说，有很多 Core Data 提供对象图管理功能，听起来你并不需要。如果您真正想要的是键值存储，那么使用NSDictionary 是有意义的。您应该与使用内存中持久存储的 Core Data 堆栈进行比较。如果您的目标是最大化读取性能并且您可以将整个数据集放入内存中，那么几乎没有理由使用 SQLite 或磁盘上的 Core Data 持久存储。

【讨论】：

【解决方案2】：

当有数百万行带有索引时，Sqlite 可能会遇到一些性能瓶颈。这可能有点矫枉过正，但在某些情况下，一种可能的技巧是将主表简单地分成 3/4 小表。例如，根据您的数据库设计，您可以打破跨越多个数据库的单词。

a-e.sqlite f-l.sqlite m-z.sqlite

然后，当您执行查找时，您可以动态切换您的选择语句以选择相应的数据库。

【讨论】：