我的团队正在与使用Solr作为搜索索引的第三方CMS合作。我注意到，作者似乎正在使用Solr作为某种数据库，因为返回的每个文档都包含两个字段：
因此，基本上，它对Solr运行搜索，下载对象的XML表示形式，然后从XML实例化对象，而不是使用id在数据库中查找它。
我的直觉告诉我，这是一种不好的做法。Solr是一个搜索索引，而不是一个数据库...因此，对我来说，对Solr执行复杂的搜索，获取文档ID，然后从数据库中提取相应的行更有意义。
当前的实现是否完全合理，或者是否有数据支持重构时机已经成熟的想法？
编辑：当我说“XML表示形式”时 - 我的意思是一个存储的字段，其中包含对象所有属性的XML字符串，而不是多个存储字段。
是的，您可以使用SOLR作为数据库，但有一些非常严重的警告：
SOLR最常见的访问模式是通过http，对批量查询的响应不是特别好。此外，SOLR不会---流式传输数据，因此您无法一次懒惰地迭代数百万条记录。这意味着在使用 SOLR 设计大规模数据访问模式时，您必须非常周到。
尽管SOLR性能可以水平扩展（更多机器，更多内核等）以及垂直（更多RAM，更好的机器等），但与成熟的RDBMS相比，其查询功能受到严重限制。也就是说，有一些出色的功能，例如字段统计信息查询，非常方便。
习惯于使用关系数据库的开发人员在 SOLR 范例中使用相同的 DAO 设计模式时，经常会遇到问题，因为 SOLR 在查询中使用筛选器的方式。将有一个学习曲线，用于开发正确的方法来构建使用SOLR进行部分大型查询或状态修改的应用程序。
允许高级会话管理和状态完整实体的“进取”工具，许多高级Web框架（Ruby，Hibernate等）必须完全抛出窗外。
关系数据库旨在处理复杂的数据和关系 - 因此它们伴随着最先进的指标和自动化分析工具。在SOLR中，我发现自己编写了这样的工具并手动进行了大量压力测试，这可能会浪费时间。
加盟：这是大杀手。关系数据库支持用于构建和优化基于简单谓词连接元组的视图和查询的方法。在 SOLR 中，没有任何可靠的方法可以跨索引联接数据。
弹性：为了实现高可用性，SolrCloud在下面使用分布式文件系统（即HCFS）。此模型与关系数据库的模型完全不同，关系数据库通常使用从属和主数据库或 RAID 等实现弹性。因此，您必须准备好提供SOLR所需的弹性基础架构，如果您希望它具有云可扩展性和抗性。
也就是说 - 对于某些任务，SOLR有很多明显的优势：（参见 http://wiki.apache.org/solr/WhyUseSolr） - 松散查询更容易运行并返回有意义的结果。索引是默认完成的，因此大多数任意查询都非常有效地运行（与RDBMS不同，RDBMS通常必须在事后进行优化和非规范化）。
结论：尽管您可以将SOLR用作RDBMS，但您可能会发现（像我一样）最终“没有免费的午餐” - 并且超酷的lucene文本搜索和高性能的内存中索引的成本节省通常通过灵活性降低和采用新的数据访问工作流来支付。
使用Solr作为数据库是完全合理的，具体取决于您的应用程序。事实上，这几乎就是 guardian.co.uk 正在做的事情。
这本身绝对不是坏的做法。如果你以错误的方式使用它，就像任何级别的任何其他工具一样，甚至是GOTO，它只会很糟糕。
当您说“XML 表示形式...”时我假设您正在谈论拥有多个存储的Solr字段并使用Solr的XML格式检索它，而不仅仅是一个大的XML内容字段（这将是Solr的可怕用法）。Solr使用XML作为默认响应格式的事实在很大程度上是无关紧要的，你也可以使用二进制协议，因此在这方面它与传统的关系数据库非常相似。
最终，这取决于您的应用程序的需求。Solr主要是一个文本搜索引擎，但也可以作为许多应用程序的NoSQL数据库。
