首页 文章

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

提问于
浏览
52

我的团队正在与使用Solr作为搜索索引的第三方CMS合作 . 我注意到,似乎作者使用Solr作为各种数据库,因为返回的每个文档都包含两个字段:

  • Solr文档ID(基本上是类名和数据库ID)

  • 整个对象的XML表示形式

所以基本上它运行对Solr的搜索,下载对象的XML表示,然后从XML实例化对象,而不是使用id在数据库中查找它 .

我的直觉告诉我这是一个不好的做法 . Solr是一个搜索索引,而不是一个数据库......所以对我来说更有意义的是对Solr执行复杂的搜索,获取文档ID,然后将相应的行拉出数据库 .

当前的实现是否完美无缺,或者是否有数据支持这种重构成熟的想法?

EDIT: 当我说"XML representation"时 - 我指的是一个存储字段,其中包含所有对象属性的XML字符串,而不是多个存储字段 .

4 回答

  • 29

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

    • SOLR 's most common access pattern, which is over http doesnt respond particularly well to batch querying. Furthermore, SOLR does NOT stream data --- so you can'懒洋洋地一次遍历数百万条记录 . This means you have to be very thoughtful when you design large scale data access patterns with SOLR.

    • 虽然SOLR性能可以水平扩展(更多机器,更多核心等)以及垂直(更多RAM,更好的机器等), its querying capabilities are severely limited compared to those of a mature RDBMS . 也就是说,有一些很好的功能,比如现场统计查询,非常方便 .

    • 由于SOLR在查询中使用过滤器的方式,习惯于使用关系数据库的开发人员在SOLR范例中使用相同的DAO设计模式时经常会遇到问题 . 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 的"enterprisy"工具 .

    • 关系数据库旨在处理复杂的数据和关系 - 因此它们伴随着最先进的指标和自动分析工具 . 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等来实现弹性 . 因此,如果您希望它具有 Cloud 可扩展性和抗拒性,那么您必须准备好提供SOLR所需的弹性基础架构 .

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

    Conclusion: 即使你可以使用SOLR作为RDBMS,你可能会发现(我有)最终有"no free lunch" - 并且通常支付超酷的lucene文本搜索和高性能内存索引的成本节省因为灵活性较低并采用新的数据访问工作流程 .

  • 2

    我已经看到类似的事情,因为它允许非常快速的查找 . 我们将数据从我们的Lucene索引移到快速键值存储中,以遵循DRY原则并减小索引的大小 . 对于这种事情,没有一个严格的规则 .

  • 66

    根据您的应用,将Solr用作数据库是完全合理的 . 事实上,这几乎是guardian.co.uk is doing .

    这本身就是不错的做法 . 如果你以错误的方式使用它,就像任何级别的任何其他工具一样,即使是GOTO也是如此 .

    当你说"An XML representation..."我假设你是're talking about having multiple stored Solr fields and retrieving this using Solr'的XML格式,而不仅仅是一个大的XML内容领域(这将是一个可怕的使用Solr) . Solr使用XML作为默认响应格式这一事实在很大程度上是无关紧要的,您也可以使用binary protocol,因此在这方面它与传统的关系数据库相当 .

    最终,它需要's up to your application' . Solr主要是一个文本搜索引擎,但也可以作为许多应用程序的NoSQL数据库 .

  • 2

    这可能是出于性能原因而做的,如果它不会导致任何问题我会不理会 . 在传统数据库和solr索引中应该有一个很大的灰色区域 . 我似乎人们对此做了类似的事情(通常是键值对或json而不是xml)用于UI表示,并且只有在需要更新/删除时才从数据库中获取真实对象 . 但所有的阅读都只是去索尔 .

相关问题