Ano, použil jsem to přesně k tomu, co popisujete. Měli jsme dvě služby – jednu pro čtení a jednu pro zápis, ale jen proto, že jsme měli více čteček. Jsem si jistý, že jsme to mohli udělat pouze s jednou službou (autorem) a vložit čtečku do webové aplikace a služeb.
Použil jsem lucene.net jako obecný databázový indexer, takže to, co jsem dostal zpět, bylo v podstatě ID DB (k indexovaným e-mailovým zprávám), a také jsem ho použil k získání dostatečného množství informací k naplnění výsledků vyhledávání nebo podobně, aniž bych se dotkl databáze. V obou případech to fungovalo skvěle, i když SQL může být trochu pomalé, protože v podstatě musíte získat ID, vybrat ID atd. Vyřešili jsme to vytvořením dočasné tabulky (s pouze řádkem ID v ní) a hromadné vkládání ze souboru (což byl výstup z lucene) a poté připojení k tabulce zpráv. Bylo to mnohem rychlejší.
Lucene není dokonalý a musíte myslet trochu mimo rámec relační databáze, protože NAPROSTO není, ale je velmi dobrý v tom, co dělá. Stojí za to se podívat a, bylo mi řečeno, nemá problémy typu „jejda, promiňte, musíte znovu sestavit svůj index“, které dělá FTI MS SQL.
BTW, měli jsme co do činění s 20-50 miliony e-mailů (a asi 1 milionem unikátních příloh), v celkové výši asi 20 GB lucene indexu, myslím, a 250+GB SQL databáze + příloh.
Výkon byl přinejmenším fantastický – jen se ujistěte, že jste přemýšleli o slučovacích faktorech a upravovali je (když slučuje segmenty indexu). Není problém mít více než jeden segment, ale může nastat VELKÝ problém, pokud se pokusíte sloučit dva segmenty, které mají v každém 1 milion položek, a máte sledovací vlákno, které proces zabije, pokud to trvá příliš dlouho... .. (ano, to nás na chvíli nakoplo). Udržujte tedy maximální počet dokumentů na věc NÍZKÝ (tj. nenastavujte jej na maxint jako my!)
EDITACE Corey Trager zde zdokumentoval, jak používat Lucene.NET v BugTracker.NET.