为 ASP.NET MVC 应用程序实现全文搜索的最佳方法是什么？
我使用 MVC 2.0 和 Fluent NHibernate 构建了一个 ASP.NET MVC 应用程序（由于某些原因隐藏在存储库后面）。该应用程序代表一个相当复杂的域，其中包含一些不同的对象，例如用户、消息、评论、文件和约会。
现在我想实现全文搜索，使用户只需输入搜索短语即可轻松找到所有类型的内容。当单独处理应用程序中所有类型的不同对象时，我现在必须将它们“放在一起”进行搜索。这意味着用户不区分不同类型，他只需输入“xyz”并希望获得列表中的结果、与消息混合的评论等。
选项 1 是创建一个搜索服务，从不同的类型中获取搜索结果存储库并准备组合输出（排序、分页等）。但当背后的数据增长（而且它将会增长）时，这真的非常非常昂贵。
所以我正在寻找替代解决方案。目前我正在使用SQL Server 2008。我发现的是lucene.net（http://lucene.apache.org/lucene.net/），但我还没有投入太多时间。
有什么建议吗？
I've built an ASP.NET MVC application with MVC 2.0 and Fluent NHibernate (hided behind repositories for some reasons). The application represents a quite complex domain with some different objects like users, messages, comments, files and appointments.
Now I want to implement a fulltext search which is enabling the user to find easily all types of content by simply entering a search phrase. When handling all that types of different objects in the application seperately, I now have to put them "together" for the search. That means the user makes no distinction between the different types, he just enters "xyz" and wants to get results in a list, comments mixed up with messages etc.
Option 1 is to create a search service which fetches the search result from the different repositories and prepares the combined output (sorting, paging etc.). But that's really, really expensive when the data behind grows (and it will grow).
So I am looking for an alternative solution. Currently I am working with SQL Server 2008. What I have found is lucene.net (http://lucene.apache.org/lucene.net/), but I didn't invest much time yet.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我肯定会选择 SQL 全文功能。我确实理解某些内容可能在文件、其他结构中可用，但即便如此，大部分数据也应该位于后端，并且 SQL 在架构方面的全文索引方面做得很好。
我建议您从 SQL 全文开始，并创建一个查询其他资源的小组件（如果需要）。我假设 80% 的可搜索内容来自 SQL Server。
以下是一些开始使用 SQL Server 全文的资源：
I'd definitely go with SQL fulltext capabilities. I do understand that some of the content might be available in files, other structures but even then, the majority of the data should be in the backend and SQL does a fine job with fulltext indexes architecture-wise.
I'd suggest you start with SQL fulltext and create a small component that query the other resources (if required). I'm assuming that 80% of the searchable content would be coming from SQL Server.
Here are a couple of resources to started with SQL Server fulltext:
对于.Net，您可以查看RavenDB，它使用lucene作为索引存储，并将为您提供以下搜索功能Lucene 作为奖励。它可能更容易使用。在我看来，API 肯定更灵活、更好。但您应该考虑存储开销。
根据您的需要，您可以在 SQL Server 中启用全文搜索，为您提供 SQL 的附加查询功能。这样您就不需要管理数据库数据之外的另一个索引。如果您的数据驻留在多个存储库中，那么使用 Lucene 等外部索引可能是更好的方法。
至于其他全文搜索引擎，您可以使用 Microsoft Search Server Express，但您可能必须创建自己的内容连接器才能获取数据（同样取决于您的存储库）。
For .Net you can look into RavenDB which uses lucene as it's index storage, and will provide you with the search capabilities of Lucene as a bonus. It might be easier to use. Certainly more flexible and better API's imo. But you should look into the storage overhead.
Depending on your need you can turn on Full Text Search in SQL Server which gives you additional query capabilities from SQL. This way you don't need to manage another index outside your database data. If your data resides in several repositories, then using an external index like Lucene might be a better approach.
As for other full text search engines you have Microsoft Search Server Express, but you might have to create your own content connector to get the data in (again depending on your repositories).
仅仅说“使用全文”是不够的。他的解决方案不一定是在每个实体类型中进行更高级的文本搜索。他需要能够根据查询字符串查询任何类型实体的索引。我可以看到使用 NHibernate.Search 作为填充 Lucene 索引的方法，但不知道它的功能是否支持搜索索引，而不管索引文档类型如何（NHibernate 类被保留）。因此，您可能必须更直接地查询 Lucene 索引并解释结果以通过 NHibernate 本身显示或直接检索 SQL Server DB 中的底层对象。
Simply saying "use fulltext" isn't enough. His solution is not necessarily about having more advanced text searching within each entity type. He needs to be able to query the index for any type of entity based upon the query string. I could see using NHibernate.Search as the method to populate a Lucene index, but don't know if the capabilities of it support searching the index irrespective of the index document type (the NHibernate class being persisted). So you may have to query the Lucene index more directly and interpret the results for display or direct retrieval of the underlying object in the SQL server DB via NHibernate itself.