Your first design task is to decide what data you want to be able to search. Which fields do you want to be able to search on? What data do you want your search to return? There are several tradeoffs here so it's worth thinking about these things carefully.
Firstly, your index should contain as few fields as possible. Less fields mean a smaller index at runtime, and less use of system resources. Don't put it in your search service unless you need it.
Each field in your index can be indexed (i.e. searchable), stored (i.e. you can retrieve its value), or both. The reasons you would want to index a field are obvious - you want to be able to search based on it. However, some fields you might not want to search on - such as non-human-readable IDs. You might wish to add these to your search service as stored but non-indexed fields, so that you can perform database lookups based on the results of your searches. If you don't need to index a field, then don't - your extract processes will run faster and your index will consume less system resources.
Likewise, you may choose to store field values or not. In general, the index does not store the original value of a field, but keeps a searchable representation only. In general, to be useful, a search must store at least one field (the corresponding primary key of the database record).
After that, whether or not to store fields is a tradeoff. You could store all the fields you need in order to display your search results, or you could store only the database IDs and use these to retrieve the data from the database to display. The first option will result in a much larger index, but a faster display of search results because the database is not required.