php - 这个系统有什么更好的 solr 查询？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

8年前关闭。




Improve this question




我聘请了一位 db 顾问，他一直建议使用 solr 来处理我当前完全 mysql 系统的全文搜索方面，以加快通常很慢的搜索速度(每次搜索最多 30 秒)。

他/我们的大部分时间都花在了 a) 调整 mysql 设置以挤出额外的性能，以及 b) 安装 solr。然而，现在我们已经接近尾声，前几个 solr 测试查询似乎失败了。

首先，这是我当前完全 Mysql 设置的相关 3 个表，以及我们试图用 MySQL/Solr 方法替换的完全 MySQL 查询。然后是我们正在测试的 Solr 查询。

表 1 - 存储全文搜索记录的主表。它们由songID 列、Artist 列和Title 列组成。 INDEXES - songID primary、Artist Fulltext(非唯一)、Artist btree(非唯一)、Title Fulltext(非唯一)、Title btree(非唯一)

表 2 - 用于存储 DJ 歌曲列表。它引用了上表的 ID。一些 DJ 有 150,000 多首歌曲，因此这里有 150,000 多行引用表 1 中的歌曲。 TABLE2 也有一个 ID 列，加上一个歌曲版本列(命名版本)，因此 DJ 可以将自己的版本引用应用于同一首歌曲的多个版本(即同一首歌曲的多行，每行具有不同的版本数据)。 INDEXES - ID primary，djID btree(非唯一)，songID btree(非唯一)。

表 3 - 一个标签映射表，它包含对 TABLE2 中 ID 的引用和标签的 ID(在另一个名为 TAGS 的表中)。它将每首歌曲的标签存储在 TABLE2 中，用于流派、语言、年代，此外 DJ 可以有多个歌曲列表(标记为 List1、List2 等)，因此引用每首歌曲所属的歌曲列表。潜在地，每个 DJ 每首歌曲最多可以有大约 12 个标签。 INDEXES - rowID primary，ID btree(非唯一)，tag_id(非唯一)

这是艺术家关键字“beatles”的当前 mysql 搜索查询，唯一涉及的标签是告诉我们只选择 DJ 33 的 List1 中歌曲的匹配项:

"SELECT t1.*, t2.version 
FROM  table1 t1, table2 t2, tagmap tm, tag t
WHERE MATCH (t1.Artist) AGAINST ('+beatles* ' IN BOOLEAN MODE) 
AND tm.tag_id = t.tag_id
AND (t.name IN ('List1'))
AND t2.ID = tm.ID
AND t2.songID = t1.songID
AND t2.djID = '33'
GROUP BY t2.ID
HAVING COUNT( tm.tag_id )=1
ORDER BY t1.Artist, t1.Title ASC LIMIT {$lastRowNum},{$limit1}";// pagination blah

它有效，但在大于 5000 的列表上，它很慢。

他提出的 SOLR 解决方案:

为 TABLE1

中的歌曲制作 solr 索引

在搜索过程中，在 mysql 中的 TABLE2 中查询属于相关 DJ 的歌曲 ID

为 Artist 上的关键字创建一个 solr 查询，并将 DJ 的歌曲 ID 注入(inject)其中...

.../solr/select/?q=id:(3688804 3688807) AND 艺术家:beatles&wt=json

(我留下了网址，还有空格和括号，所以在这里很容易查看，但它们在工作代码中被替换为 %20 等)

上面这个只有 2 个歌曲 ID 的示例似乎可以工作，但在测试中，一旦您开始向其中添加大约 1000 多个歌曲 ID，查询就会失败。考虑到一些 DJ 有 150,000 多首歌曲，因此可能有 150,000 多首独特的歌曲 ID 可以注入(inject)到 solr 查询中，这似乎是一个有缺陷的解决方案。

另外，我不知道标签将如何进入查询过程。

谢谢参观。

Answer 1

我建议您使用 Solr，但实现方式略有不同。

您所有的数据库规范化都适用于事务系统(即添加歌曲、创建播放列表等)

搜索在非规范化数据结构上效果最好。您可以只创建一个表示您的搜索结果的 Solr 模式并使用 SQL 查询填充它。

查询仍然效率低下，但它不需要在每次搜索时都运行(即实时)。相反，您可以每晚批量填充索引，并在歌曲/播放列表等发生变化时进行滴流变化。

我在这个 here 上写了一些东西.希望这可以帮助。