Searching text in database: caching database records into domain logic V/S using MySQL full-text search?

Question

I am developing a layered web app. In brief it has:

UI: html, javascript and jquery
Domain logic: Java and servlets
Business logic: MySQL

I have large amounts of records in the database containing info about books. In addition the application will be used by a lot of users at the same time. I want to enable users to input a book's "name" in a search text field , say "book1" and display a drop down list using jquery autocomplete.

The records in database are not updatable since they will never change.

Considering solid design patterns,which is better (performance and speed wise) :

Preloading these database records into a cache object at the domain logic and let the users search (query) them from this object? Or querying directly from the database using something like MySQL full-text search?

If using MySQL full-text search, I am concerned about having lots of calls to the database by many users at the same time. As for preloading into a cache object, i am not sure if this is generally a good software practice, does anyone recommend it? Should i put a timer for records to remain cached in memory?

Which of these 2 methods is preferable? are there other better methods for such scenarios?

Answer 1

I found a solution and hope this answer will help the ones who are dealing with a similar situation:
I will be using a software engineering design pattern, which I used frequently in the past, called Identity Map.

Only this time, since records are not updatable (i.e. not changeable), I will be using only the caching functionality of the identity map. So I will will be loading the records from the database into this identity map object once the server starts. This way a user will query them directly from the domain layer, thus faster and less calls to the database.

One issue to consider, and it is when adding new records by the administration, for this situation I will be using another design pattern called "observer pattern" (you can learn about it in this book).

UPDATE:
In case you are dealing with a similar situation, a good idea is to use MySQL indexing. I used it on the column of the "book's name" to enable faster loading in the cache object, because in my case the cache object will contain only book(s) name(s) since using the search field in the UI, the user is only concerned about a book's name. PS: other book details will be loaded only when user clicks on a book's name in the drop down list, and at this point u might want to use another Identity map holding the details . The reason behind this architecture is that, logically speaking never will u have all the books (with their details) from your database searched (loaded) by all the users of your application at the same time... thus to minimize server memory and bandwidth usage you first compromise loading the whole column of book names in memory for faster searching of all available book names BUT their details (ie more space in memory) will be loaded only when needed by a user and will be kept in another identity map to be used by another user searching for the same book with same details. In my opinion this minimizes memory usage on the server and less calls to the database to get details that have already been fetched by other users before.