我的团队正在与使用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所需的弹性基础架构。
就是说- SOLR对于某些任务有很多明显的优势：（请参阅http://wiki.apache.org/solr/WhyUseSolr）-松散查询更容易运行并返回有意义的结果。索引是默认情况下进行的操作，因此大多数任意查询都可以非常有效地运行（与RDBMS不同，在RDBMS之后，您通常必须对事实进行优化和反规范化）。
结论： 即使可以将SOLR用作RDBMS，您也可能发现（如我所知）最终“没有免费的午餐”，并且节省了超酷的lucene文本搜索和高性能的内存中的成本索引编制通常是由于灵活性较低和采用新的数据访问工作流而付出的。
