非常大的 NSDictionary vs Core Data vs SQLite 在 iPhone 上进行只读查找？
我正在修改一个 iPhone 单词应用程序，其中使用 DAWG 结构在用户键入时从用户定义的单词库中实时查找字谜。那部分效果很好。识别出单词后，我想检索当前 plist 文件中每个单词的具体信息（按单词键入）。这些信息需要导入并在应用程序启动时可用。
启动时，我可以使用 initWithContentsOfFile 轻松地将 plist 准备到 NSDictionary 对象中，但这会创建一个包含约 200,000 个键/值对的字典。我猜测这不是最好的方法，因为 txt、bin 和 xml 格式的 plist 文件分别为 2.8 MB、3.9 MB 和 7.5 MB。
我应该使用 Core Data 还是 SQLite？我的首要任务是性能，因为如果可能的话，我希望在用户输入时实时查找数以万计的结果信息。
谢谢
I'm tinkering around with a iPhone word app where I am using a DAWG structure for finding anagrams from a user defined word bank in real time as the user types. That part works well. As the words are identified, I want to retrieve specific information about each word which I currently have in a plist file (keyed by word). This information needs to be imported and available when the apps starts.
On startup, I can easily ready the plist into an NSDictionary object using initWithContentsOfFile, but this creates a dictionary with ~200,000 key/value pairs. I'm guessing that this is not the best approach as the plist files in txt, bin, and xml format are 2.8 MB, 3.9 MB, and 7.5 MB respectively.
Should I be using Core Data or SQLite? My top priority is performance as I would like to look up the info for literally tens of thousands of results in real time as the user types if possible.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您只能通过尝试两种方法和分析来回答性能问题（使用 Instruments.app）。也就是说，有很多核心数据提供对象图管理功能，但听起来并不像您需要的那样。如果您真正想要的是键值存储，那么使用 NSDictionary 是有意义的。您应该与使用内存中持久存储的核心数据堆栈进行比较。如果您的目标是最大读取性能并且可以将整个数据集放入内存中，则没有理由使用 SQLite 或磁盘上的 Core Data 持久存储。
You can only answer performance questions by trying both approaches and profiling (use Instruments.app). That said, there is a lot of Core Data that serves object graph management functionality that it doesn't sound like you need. If what you really want is a key-value store, then using an
NSDictionarymakes sense. You should compare against a Core Data stack using an in-memory persistent store. There is little reason to go to SQLite or a Core Data persistent store on disk if your goal is maximal read performance and you can fit the entire data set into memory.当有数百万行带有索引时，Sqlite 可能会遇到一些性能瓶颈。
这可能有点矫枉过正，但在某些情况下，一种可能的技巧是将主表简单地分成 3/4 的小表。例如，根据您的数据库设计，您可能会破坏跨多个数据库的单词。
ae.sqlite
sqlite
mz.sqlite
然后，当您执行查找时，您可以动态切换 select 语句以选择相应的数据库。
Sqlite can hit some performance bottlenecks when there are millions of rows with indexes.
This maybe an overkill, but in some situations, one possible hack is to simply break the main table into 3/4 smaller tables. For example, depending on your database design, you could break words spanning across multiple dbs.
a-e.sqlite
f-l.sqlite
m-z.sqlite
then as you perform lookups you can dynamically switch your select statement to choose corresponding db.