in reply to Re^2: fast disk db with bulk insert, fast read access, compact storage
in thread fast disk db with bulk insert, fast read access, compact storage
Your original description of your application:
simple---key, value. ... 32GB ... (think as application of a word hash that I am rebuilding every night, and I want to do real-time search as my users are typing words.)
Is almost completely at odds with this description:
is about 5GB now (but could grow to 20GB in the future) ... the DB changes, say, once per month ... I do need quick access into individual words. so, if I want to find all articles that contain the word 'Time' and the work 'monks' and the number 245, my search should be blindingly fast to find all unique-keys that contain the three words, and then display these records.
The former implies indexing by the characters of the unique key only.
The latter requires a fully inverted index of the words in the entire records, which essentially makes the unique key redundant.
You need to define the actual use your data will be put to, before looking for the mechanism for doing it.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^4: fast disk db with bulk insert, fast read access, compact storage
by iaw4 (Monk) on Sep 18, 2010 at 22:27 UTC | |
by BrowserUk (Patriarch) on Sep 19, 2010 at 07:37 UTC | |
by iaw4 (Monk) on Sep 19, 2010 at 12:12 UTC | |
by BrowserUk (Patriarch) on Sep 19, 2010 at 13:26 UTC |