Solr（或其他多面搜索引擎）中的搜索/导航，正确的方法是什么？

Question

对于 Mysql 的使用应该在哪里结束以及 SOLR 应该从哪里开始，我有点困惑。

我有很多关系数据（就像电子商务网站，比如亚马逊）。

我首先将它放入 mysql，但遇到了大小/速度问题，而索引对这么多数据没有帮助。所以，我把所有这些数据都放到 SOLR 中，它真的很快。在某种程度上，SOLR 就像我目前的 MYSQL 数据库的缓存（其中包含多个通过 ID 链接的关系表）。

问题是我对一堆事情感到困惑。

1) 是否需要mysql数据库？我可以轻松地编辑数据并将其添加到 SOLR 表中吗？ Mysql 数据库只是增加了更多开销吗？

2) 最好如何进行分面并将其用于搜索导航？我目前将整个 mysql 数据库统一到一​​个平面 solr 文件中。考虑到一个条目可能具有的多对多关系时，如何最好地做到这一点？这一切都应该在 SOLR 中使用 PathHierarchyTokenizer 完成吗？我应该将多个方面塞进一个领域吗？

3) 是否需要在 MYSQL 中存储类别/方面，以便可以为这些页面创建 SEO 标题？我猜这不能在 SOLR 中完成，因为没有真正的页面概念作为方面？似乎需要某种静态存储/缓存方面，可以在其中添加其他信息，并且在 SOLR 中不这样做似乎是有道理的？

4) 还是应该只使用 SOLR 作为 MYSQL 数据库的缓存？所以我从mysql获取了所有的分类菜单，但是当一个URL查询发生时，它从SOLR获取了所有的产品？

很想听听其他人对此的看法，因为虽然 solr 又好又快，但与 DB 有很大的重叠，我正在努力弄清楚每个都有什么意义。

Answer 1

是否需要mysql数据库？

如果您需要事物之间的关系，那么 RDBMS 比 Solr 更好，因为 Solr 具有平面的、非规范化的世界视图。

Solr 通常不被视为记录源。如果您这样使用它，则所有字段都需要“存储”。考虑如何备份和恢复数据。

作为一个好的起点，将 Solr 用于其擅长的领域，即搜索。索引您需要索引的内容，存储您需要存储的内容。请记住，Solr 索引可以通过分析变得非常大，而更大的索引效率较低。