Hm. Not sure where in the OP you get the 'dial-by-name' idea from.
With 1GB of keys averaging 8 chars, that's 128 million key/value pairs. And 31GB / 128MB = ave. 246 char values, which is a bit big for a telephone number.
This bit of the OP seemed quite clear to me, hence my Google example:
I want to do real-time search as my users are typing words.
But I guess unless the OP comes back and clarifies, we won't know if I got it right or not.
I'm currently playing with an indexer, that indexes each record by each character and position in the keys. I project it would take 84 minutes to index the 32GB; and produce a count of matching records within 50 milliseconds. That's from disk with a cold cache. Should be substantially faster using an SSD.
For the described dataset, it would use 8GB of primary index and 1GB of secondary; which puts in the ballpark of the OPs requirements. Assuming that I read them correctly.
In reply to Re^4: fast disk db with bulk insert, fast read access, compact storage
by BrowserUk
in thread fast disk db with bulk insert, fast read access, compact storage
by iaw4
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |