Very large NSDictionary vs Core Data vs SQLite for read-only look up on iPhone?

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 ini开发者_如何转开发tWithContentsOfFile, 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

---

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 NSDictionary makes 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 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.