java - 使用 Solr 搜索索引作为数据库 - 这是 "wrong"吗？

Question

我的团队正在与使用 Solr 作为搜索索引的第三方 CMS 合作。我注意到作者似乎在使用 Solr 作为各种数据库，因为返回的每个文档都包含两个字段:

1. Solr 文档 ID(基本上是类名和数据库 ID)
2. 整个对象的 XML 表示

所以基本上它对 Solr 进行搜索，下载对象的 XML 表示，然后从 XML 实例化对象，而不是使用 id 在数据库中查找它。

我的直觉告诉我这是一种不好的做法。 Solr 是一个搜索索引，而不是数据库……所以对我来说，对 Solr 执行复杂的搜索、获取文档 id，然后从数据库中提取相应的行更有意义。

当前的实现是否完美，或者是否有数据支持重构成熟的想法？

编辑:当我说“XML 表示”时 - 我的意思是一个存储字段，其中包含所有对象属性的 XML 字符串，而不是多个存储字段。

Answer 1

是的，您可以将 SOLR 用作数据库，但有一些非常严重的警告:

1. SOLR 最常见的访问模式，即通过 http 对批量查询的响应不是特别好。此外，SOLR 不会流式传输数据——因此您不能一次懒惰地遍历数百万条记录。 这意味着您在使用 SOLR 设计大规模数据访问模式时必须非常周到。

2. 虽然 SOLR 性能可以横向(更多机器、更多内核等)以及纵向(更多 RAM、更好机器等)扩展，但 与成熟的关系型数据库。也就是说，有一些很棒的功能，比如字段统计查询，非常方便。

3. 习惯使用关系数据库的开发人员在 SOLR 范式中使用相同的 DAO 设计模式时经常会遇到问题，因为 SOLR 在查询中使用过滤器的方式。 将有一个学习曲线来开发正确的方法来构建使用 SOLR 进行部分大型查询或全状态修改的应用程序。

4. 允许许多高级 Web 框架(Ruby、Hibernate 等)提供的高级 session 管理和有状态实体的“企业”工具将不得不完全抛弃强>。

5. 关系数据库旨在处理复杂的数据和关系 - 因此它们伴随着最先进的指标和自动分析工具。 在 SOLR 中，我发现自己编写了这样的工具并进行了很多手动压力测试，这可能会浪费时间。

6. 加入:这是大 killer 。关系数据库支持构建和优化基于简单谓词连接元组的 View 和查询的方法。 在 SOLR 中，没有任何可靠的方法可以跨索引连接数据。

7. 弹性:为实现高可用性，SolrCloud 在底层使用分布式文件系统(即 HCFS)。这种模型与关系数据库的模型完全不同，关系数据库通常使用从属和主控或 RAID 等来实现弹性。因此，如果您希望它具有云可扩展性和抗性，您必须准备好提供 SOLR 所需的弹性基础设施。

也就是说 - SOLR 对于某些任务有很多明显的优势:(参见 http://wiki.apache.org/solr/WhyUseSolr ) - 松散的查询更容易运行并返回有意义的结果。索引是默认完成的，因此大多数任意查询都非常有效地运行(与 RDBMS 不同，您通常必须在事后进行优化和反规范化)。

结论:尽管您可以将 SOLR 用作 RDBMS，但您可能会发现(就像我一样)最终“没有免费的午餐”——以及超酷的 lucene 文本的成本节省- 搜索和高性能的内存索引通常以较低的灵 active 和采用新的数据访问工作流程为代价。