The size of the crawl store DB that you mention is not abnormal. In fact I've seen them grow significantly larger than that! It can contain significant amounts of free space however.
There are a set of operations that are allowed against SharePoint databases (see for example https://technet.microsoft.com for SharePoint 2010) including the shrink operation, however the article linked to above says to only shrink the content databases as "Users and administrators do not delete enough data from the configuration database, Central Administration content database, and various service application databases to contain significant free space". I'd argue (and it's my experience) that the crawl store DB does end up with significant amounts of free space and is therefor a candidate for shrink operations as well.
Have a look at the free space for the crawl store DB and then decide whether this is something that you want to proceed with. I'd also suggest taking a copy onto another SQL Server to give the process a try before doing so on your production farm. Note also that access to the DB will not be available during the operation and so farm services may not function correctly, so plan to perform the operation out of hours. Testing the operation on another SQL instance will also give you an idea of how long the process takes. Ensure also that you address the issue of index fragmentation following shrink operations, and think carefully about sizing the database to allow future growth (at least in the short term) unless you've configured instant file initialisation.