Ja, jeg har brugt det til præcis det du beskriver. Vi havde to tjenester - en til at læse og en til at skrive, men kun fordi vi havde flere læsere. Jeg er sikker på, at vi kunne have gjort det med kun én tjeneste (skribenten) og integreret læseren i webappen og tjenesterne.
Jeg har brugt lucene.net som en generel databaseindeksering, så det, jeg fik tilbage, var dybest set DB-id'er (til indekserede e-mail-beskeder), og jeg har også brugt det til at få nok info tilbage til at udfylde søgeresultater eller lignende uden at røre ved database. Det har fungeret godt i begge tilfælde, selvom SQL'en kan blive lidt langsom, da du stort set skal have et ID, vælge et ID osv. Vi kom uden om dette ved at lave en temp-tabel (med kun ID-rækken i) og bulk-indsættelse fra en fil (som var outputtet fra lucene) og derefter slutte sig til meddelelsestabellen. Var meget hurtigere.
Lucene er ikke perfekt, og du er nødt til at tænke lidt uden for relationsdatabaseboksen, for den er HELT ikke en, men den er meget god til, hvad den gør. Værd at se, og jeg har fået at vide, har ikke de "ups, undskyld, du skal genopbygge dit indeks igen", som MS SQL's FTI gør.
BTW, vi havde at gøre med 20-50 millioner e-mails (og omkring 1 million unikke vedhæftede filer), i alt omkring 20 GB lucene-indeks tror jeg, og 250+ GB SQL-database + vedhæftede filer.
Ydeevnen var mildest talt fantastisk - bare sørg for at tænke over og justere dine fusionsfaktorer (når den flette indekssegmenter). Der er ikke noget problem i at have mere end ét segment, men der kan være et STORT problem, hvis du prøver at flette to segmenter, som har 1 million elementer i hver, og du har en watcher-tråd, som dræber processen, hvis det tager for lang tid... .. (ja, det sparkede os i røv et stykke tid). Så hold det maksimale antal dokumenter pr. ting LAVT (dvs. sæt det ikke til maxint, som vi gjorde!)
EDIT Corey Trager dokumenterede, hvordan man bruger Lucene.NET i BugTracker.NET her.