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