使用solr搜索索引作为数据库-这是“错误”的吗?

是的,您可以使用solr作为数据库,但有一些非常严重的警告:

1. Solr最常见的访问模式(通过HTTP)对批查询的响应不是很好。此外,solr不传输数据,因此您不能一次延迟地遍历数百万条记录。 这意味着您在使用SOLR设计大规模数据访问模式时必须非常慎重。

2. 尽管solr的性能可以横向(更多的机器、更多的内核等)和纵向(更多的RAM、更好的机器等)扩展, 与成熟的RDBMS相比,它的查询能力受到严重限制。 . 也就是说,有一些非常好的函数,比如字段统计查询,非常方便。

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

4. 允许 许多高级Web框架(Ruby、Hibernate等)提供的高级会话管理和状态完整实体必须完全抛出窗口。 .

5. 关系数据库是用来处理复杂的数据和关系的,因此它们伴随着最先进的度量标准和自动化的分析工具。 在Solr中,我发现自己编写了这样的工具,并手动进行了大量的压力测试,这可能是一个时间接收器。 .

6. 加入:这是个大杀手。关系数据库支持基于简单谓词连接元组的视图和查询的构建和优化方法。 在solr中,没有任何健壮的方法可以跨索引连接数据。

7. 弹性:为了实现高可用性,solrcloud使用底层的分布式文件系统(即HCF)。这个模型与关系数据库非常不同,关系数据库通常使用从服务器和主服务器或RAID等来实现弹性。因此,如果您希望它具有云可扩展性和抵抗性,您必须准备好提供Solr所需的弹性基础设施。

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

结论: 尽管您可以将Solr用作RDBMS,但您可能会发现(正如我所发现的)最终“没有免费午餐”,而且超级酷的Lucene文本搜索和高性能内存索引的成本节约通常是通过降低灵活性和采用新的数据访问工作流来支付的。

使用solr作为数据库是完全合理的,这取决于 你的 应用程序。事实上,这就是 guardian.co.uk is doing .

这绝对是 不 本身就是不好的做法。只有当你用错了方法,这才是不好的,就像任何级别的其他工具一样,甚至是goto。

当你说“一个XML表示……”时,我假设你说的是有多个存储的solr字段,并使用solr的XML格式来检索它,而不仅仅是一个大的XML内容字段(这将是solr的一个糟糕的用法)。Solr使用XML作为默认响应格式的事实在很大程度上是不相关的,您也可以使用 binary protocol 在这方面,它与传统的关系数据库相当。

最终,这取决于您的应用程序的需求。索尔 是 主要是一个文本搜索引擎,但也可以作为许多应用程序的NoSQL数据库。

这可能是出于性能的原因,如果它不会造成任何问题,我会让它单独存在。传统数据库与SOLR索引之间存在很大的灰色区域。对于UI表示,我觉得人们做了类似的事情(通常是键值对或JSON,而不是XML),并且只有在需要更新/删除时才从数据库中获取真正的对象。但所有的阅读都去索尔。

我见过类似的事情,因为它允许快速查找。我们将数据从我们的Lucene索引转移到一个快速的键值存储库中,以遵循干燥的原则,并减少索引的大小。这类事情没有硬性规定。