MySQL的高级搜索引擎，不需要唯一的INT并涵盖多个表

Question

最近我开发了一个软件，它将日志文件从我们的在线生产环境下载到带有MySQL数据库的内部NAS设备，以便我们能够存储更多信息（在线空间很昂贵）。这件事已经运行了两个星期了，所以我们的数据库正在增长： 日志表的数量411 日志条目数48,000,513 约。表格大小：37.32 GB

每小时创建一个不同的logtable（每次超过100,000个条目），这就是为什么我们目前有411个。

我还为它创建了一个搜索界面，使用的索引表包含表名，表中的第一个和最后一个条目，这样在指定搜索日期时，事情就会非常顺利。

然而，当我搜索例如“站点X”没有指定日期范围，必须搜索超过400个表，并且每行包含一个大的XML消息，因此每天都在变慢。

我开始寻找更高级的搜索解决方案并发现它们与Sphinx和Solr，但我似乎无法把事情做对：

• 我找不到如何设置这些引擎来搜索所有表（它们都具有相同的结构）。 - 我可以通过动态创建一个巨大的视图，或者现在以编程方式合并表并在将来将新记录添加到单个表中来克服这个问题，因此这不是真正的大问题。
• 我尝试过Sphinx，但它需要一个整数作为主键 - 我们有GUID（在线表是MSSQL）...我总是可以添加一个数字索引来克服这个问题，但我不想： ）
• 我尝试了Solr，我把它设置为在411个表中的一个中进行搜索，但我没有得到任何结果。在进行索引之后，它告诉我X记录被索引（大约12,000），这似乎是正确的。但是，我没有找到如何实际搜索它。

我的问题的底线：

• 是否有一个更“方便”的GUI可用于在Solr上搜索，因为那是我除了搜索部分之外最远的那个
• 或者有没有办法用char（32）设置Sphinx作为索引？
• 是不是有某种搜索引擎为我处理所有这些“混乱”，因为我可以将所有内容合并到一个表中，它只需搜索一个表？
• 我应该研究一下其他搜索引擎（最好是免费的）吗？
• 创建一个大表来放松我的工作是不是一个好主意？因此粗略计算一年后它将包括1,248,013,338或970,32 GB（至少，因为每小时的日志文件数量只会增加）。如果我这样做完全是错误的，请告诉我。

我希望我能够澄清我的问题。提前谢谢。

编辑：与此同时，我能够设置Solr并能够搜索它。然而，它创建的索引几乎与原始表的大小相同..所以我想我应该坚持自己的自制搜索引擎..？

Answer 1

（对solr没有经验，所以无法帮助你）

  

或者有没有办法用char（32）设置Sphinx作为索引？

Sphinx只需要一个唯一的ID。它实际上不必匹配数据库主键！

• 您可以将它（真实的）存储在属性中，以便在搜索时将其恢复。

获取身份证的几种方法：

• 制作一个假的！

  sql_query_pre = SET @id = 1 sql_query = SELECT @id：= @ id + 1，...

• 使用哈希

  sql_query = SELECT CRC32（uuid），...

  虽然http://www.xaprb.com/blog/2008/03/09/a-very-fast-fnv-hash-function-for-mysql/可能更好，但在sphinx中与--enable-id64一起使用。碰撞的可能性很小（但不存在）

• 仅使用部分uuid。取决于如何创建原始文件 - 例如，如果它们具有共同的前缀。

• 如果使用innodb表存储数据，mysql将为数据创建一个整数id。请参阅http://dev.mysql.com/doc/refman/4.1/en/sorting-rows.html

（Sphinx也有一些技巧可以帮助索引大量的表。配置'文件'实际上可以是一个脚本。这样一来，脚本就可以输出大量非常相似的索引定义。索引，可以有很多'源'。所以一个索引，可以很容易地从多个源表中提取内容。这有帮助，因为虽然sphinx可以有数百个表，但是很多开销，所以可能值得对它们进行分组。每个索引说24个表/源。）