我的团队正在与使用Solr作为搜索索引的第三方CMS合作.我注意到，作者似乎将Solr用作某种数据库，因为返回的每个文档都包含两个字段:
基本上，它会对Solr进行搜索，下载对象的XML表示，然后从XML中实例化对象，而不是使用id在数据库中查找.
我的直觉告诉我这是一个糟糕的做法.Solr是一个搜索索引，而不是数据库...因此，对我来说，对Solr执行复杂的搜索，获取文档ID，然后从数据库中取出相应的行更有意义.
当前的实现是否完美可靠，或者是否有数据支持这样一种观点，即重构的时机已经成熟？
EDIT:当我说"XML表示"时，我指的是一个存储字段，其中包含对象所有属性的XML字符串，而不是多个存储字段.
是的，您可以将SOLR用作数据库，但有一些非常严重的警告:
SOLR最常见的访问模式是通过http，它对批处理查询的响应不是特别好.此外，SOLR不会流式传输数据——因此您不能一次懒洋洋地遍历数百万条记录.This means you have to be very thoughtful when you design large scale data access patterns with SOLR.
尽管SOLR性能水平扩展(更多机器、更多内核等)以及垂直(更多的内存，更好的机器等)，its querying capabilities are severely limited compared to those of a mature RDBMS.也就是说，有一些很好的功能，比如字段统计查询，非常方便.
习惯于使用关系数据库的开发人员在SOLR范例中使用相同的DAO设计模式时经常会遇到问题，因为SOLR在查询中使用过滤器的方式.There will be a learning curve for developing the right approach to building an application that uses SOLR for part of its large queries or statefull modifications
"有进取心"的工具可以容纳advanced session management and statefull entities that many advanced web-frameworks (Ruby, Hibernate, ...) offer will have to be thrown completely out the window人.
关系数据库旨在处理复杂的数据和关系——因此，它们伴随着最先进的度量和自动化分析工具.In SOLR, I've found myself writing such tools and manually stress-testing alot, which can be a time sink
加入:这是个大杀手.关系数据库支持构建和优化视图和查询的方法，这些视图和查询基于简单谓词连接元组.In SOLR, there aren't any robust methods for joining data across indices.
弹性:为了实现高可用性，SolrCloud在底层使用了一个分布式文件系统(即HCFS).该模型与关系数据库的模型大不相同，关系数据库通常使用从机和主机或RAID等实现弹性.因此，如果你想让SOLR具备云可伸缩性和抗干扰性，你必须准备好提供SOLR所需的弹性基础设施.
也就是说，对于某些任务，SOLR有很多明显的优势:(见http://wiki.apache.org/solr/WhyUseSolr)——松散查询更容易运行并返回有意义的结果.索引是默认情况下完成的，因此大多数任意查询都可以非常有效地运行(与RDBMS不同，RDBMS通常需要在事后进行优化和反规范化).
Conclusion:尽管您可以将SOLR用作RDBMS，但您可能会发现(正如我所做的那样)最终"没有免费午餐"——超级酷的lucene文本搜索和高性能内存索引的成本节约通常是由灵活性降低和采用新的数据访问工作流来支付的.