3

我们有一个托管近 10000 个域的电子邮件服务，因此我们将消息的标头存储在 SQL Server 数据库中。

我需要实现一个在消息正文中搜索关键字的应用程序。消息作为文件存储在 NAS 存储系统上。

作为概念证明，我实现了一个基于 SQL 服务器的搜索系统，我将解析消息并将所有单词与成员 ID 和消息 ID 一起存储在数据库表中。该数据库位于标头数据库的单独服务器上。

该系统的问题在于，在仅处理一个域上的消息后，我最终得到了一个包含 6 亿行的表。显然，这不是一个非常可扩展的解决方案。

由于标头存储在 SQL Server 表中，因此我需要将搜索应用程序中的 messageID 连接到标头表中，以显示包含搜索关键字的消息。

关于更好的架构的任何建议？使用 SQL Server 有更好的选择吗？我们每天收到超过 2000 万条消息。我们是一家小公司，在服务器、维护等方面资源有限。

谢谢

4

8 回答 8

4

看看Hadoop。它是一个完整的“map-reduce”框架，用于处理受 Google 启发的庞大数据集。它认为（但我可能错了）Rackspace 正在使用它为他们的客户进行电子邮件搜索。

于 2009-08-14T19:28:11.883 回答
3

lucene.net会帮助你很多，但无论你如何处理，这将是很多工作。

于 2009-08-14T19:16:56.820 回答
2

考虑不为此使用 SQL。它没有帮助。

用于搜索标题文本的 GREP 和其他平面文件技术更快、更简单。

于 2009-08-14T19:20:59.510 回答
1

您还可以查看可能对您有用的 java lucene 内容。Katta （分布式 lucene 索引）和Solr（可以使用 rsync 进行索引同步）都可能有用。虽然我不认为两者都非常优雅，但在开始实际开发之前使用已经构建并已知可以工作的东西通常会更好。在不了解更多细节的情况下，很难做出更具体的建议。

于 2009-08-14T19:26:05.007 回答
1

如果您可以分解 6 亿行，请查看数据库分片。跨所有行的任何查询都会很慢。至少你可以通过语言分手。如果它们都是英语，那么，找到一些方法来拆分基于常见搜索有意义的数据。我只是在这里猜测，但也许域可以按 TLD（.com、.net、.org 等）分组。

对于全文搜索，比较 SQL Server vs Lucene.NET vs cLucene vs MySQL vs PostgreSQL。请注意，如果您不需要对结果进行排名，则全文搜索会更快。如果数据库仍然很慢，请查看性能调整，如果失败，请查看基于 Linux 的数据库。

http://incubator.apache.org/lucene.net/

http://sourceforge.net/projects/clucene/

于 2009-08-14T20:04:37.100 回答
0

查看 SQL Server 全文搜索服务/功能。我自己没有用过，但我曾经读过 Stack Overflow 使用它。

于 2009-08-14T19:36:43.660 回答
0

我想知道 BigTable ( http://en.wikipedia.org/wiki/BigTable ) 是否进行搜索。

于 2009-08-14T19:33:25.523 回答
0

三个解决方案：

  1. 使用已经存在的文本搜索引擎（lucene 是被提及最多的，还有几个）
    • 将整个消息存储在 SQL 数据库中，并使用包含的全文搜索（现在大多数数据库都有）。
    • 不要为每个单词出现创建一个新记录，只需在单词记录中的一个大字段中添加一个新值。如果您不对该表使用 SQL，则更好的是使用键值存储，其中键是单词，值是出现的列表。检查一些倒排索引书目以获得灵感

但老实说，我认为唯一合理的方法是#1

于 2009-08-14T20:04:02.967 回答