【问题标题】:How to search over huge non-text based data sets?如何搜索庞大的非基于文本的数据集?
【发布时间】:2011-08-24 15:22:22
【问题描述】:

在我正在工作的一个项目中,客户有一个旧的和海量(TB 级)的 RDBMS。各种查询都很慢,没有时间修复/重构模式。我已经确定了需要优化的常见查询集。该集合分为两部分:全文查询和元数据查询。

我的计划是从他们的数据库中提取数据并将其分区到两个不同的存储系统中,每个系统都针对特定的查询集进行了优化。

对于全文搜索,Solr 是最有意义的引擎。它的分片和复制功能非常适合解决一半的问题。

对于元数据查询,我不确定该采取什么途径。目前,我正在考虑使用具有极度非规范化模式的 RDBMS,该模式表示来自“权威”RDBMS 的特定数据子集。但是,我的客户担心与已经包含它们的 Solr 相比,此类子系统缺乏分片和复制,以及设置此类功能的困难/复杂性。在这种情况下,元数据采用整数、日期、布尔值、位和字符串的形式(最大大小为 10 个字符)。

是否有具有内置分片和复制功能的数据库存储系统可能对查询所述元数据特别有用?也许有一个提供良好查询引擎的无 sql 解决方案?

请点亮。

补充/回复:

Solr 可用于元数据,但是元数据是易失的。因此,我必须经常提交索引。这会导致搜索性能下降很快。

【问题讨论】:

  • 啊,你不想在 Solr 中进行元数据查询有什么特别的原因吗?它也非常有能力处理所有其他数据类型。
  • Solr 可用于元数据,但是元数据是易失的。因此,我必须经常提交索引。这将导致搜索性能下降得非常快。嗯,也许某种缓解这个问题的索引管理策略可以产生预期的结果?我会考虑的。
  • 啊。我的印象是数据库主要是历史的和静态的,而不是快速变化的。您开始徘徊在分布式搜索领域:我希望您必须在其他解决方案之上推出自己的索引管理(或者如果您有预算,请付钱给其他人为您推出它:))
  • 元数据有多少数据?
  • @Charles,很好的问题,元数据大约为数百 GB,不到 1 TB 的存储空间。粗略地说,在任何给定时间点都是 500GB-1000GB。这种特殊性是因为我打算执行某种归档策略来在实时搜索和基于工作的搜索之间划清界限(例如,您的搜索需要一些时间来处理,几分钟后回来查看您的结果)。当然,在这个问题的背景下,我正在解决近实时用例。

标签: c# search solr nosql ravendb


【解决方案1】:

MongoDB 用于您的元数据存储:

但是,缺点是您不能执行连接。明智地对数据进行非规范化处理,以免发生这种情况。

【讨论】:

  • AFAIK MongoDB 不包括全文搜索,这是 OP 的要求之一!
  • 他已经找到了解决方案的全文,他正在寻找一个单独的系统来搜索元数据。
  • 集成并非易事...我建议的引擎提供两种功能,集成
【解决方案2】:

如果您使用elasticsearch,您可以简单地将元数据添加为 json 文档的额外键:

{
    "message": ... your full text,
    "date": "2009-11-15T14:12:12",
    ...
}

然后您可以同时使用两者进行搜索。否则,如果您仍想使用两种系统方法,monogoDB 是一个具有自动分片的文档存储,具有一些非常先进的查询机制(字段、map-reduce、快速查询的索引)。

【讨论】:

    【解决方案3】:

    我确信您知道您不会在任何频繁更新的系统上获得快速查询时间。要针对 RDBMS 实现自己的分片,您需要找到一些键来拆分记录并填充多个数据库。然后,您可以同时查询它们,以 map reduce 方式获取和处理数据。这将允许您随着数据的增长而增加机器的数量,并且可能允许您提高操作的速度。通过谷歌快速搜索,MongoDB 和 Hadoop 都提供了这种 map/reduce 功能,我对两者都不熟悉。

    动态生成复杂的长时间运行的报告并不少见。然而,当报告完成生成时,这通常伴随着电子邮件通知。它为与人类交互提供了一种良好的推送通知格式。此外,如果这些报告是周期性的(例如每周、每月等),您仍然可以在这些报告准备好后使用电子邮件通知,唯一的区别是生成的启动时间是自动的。

    【讨论】:

    • 又一个 ninja downvote。请发表评论,以便我知道我收到它的原因。
    【解决方案4】:

    RavenDB:

    缺点:它是 AGPL 许可的。根据您的开发/服务器环境,您可以认为它在 .NET 上运行是一个骗局。此外,我不知道 .NET 以外的其他平台的客户端状态。

    Solandra:

    • 集成 Solr 和 Cassandra
    • 由 Solr 管理的全文搜索
    • 由 Cassandra 管理的复制和分片

    缺点:尚未发布。

    ElasticSearch:

    ElasticSearch 看起来类似于 RavenDB,但似乎 emphasize full-text search RavenDB 强调它是一个通用的 NoSQL 数据库。

    【讨论】:

    • 这些数据库是否自动管理 lucene 索引(在后台)? (例如,索引碎片是否仍然需要代码处理)如果对于这些数据库的搜索依赖于 lucene,那么针对我的两个查询需求量身定制两个不同的 Solr 部署不是更好吗?对于通过使用您推荐的数据库而不是 Solr 获得的额外价值,我有点困惑,无论如何我最终都会使用。感谢您的帮助!
    • @Newbie:我对这两个数据库都没有第一手经验(尽管我确实有 Solr 经验),但他们声称对近实时搜索有很好的支持(你的最后一个要求)
    • @Newbie:添加了ElasticSearch,它还声称可以进行近实时搜索
    • @Newbie; RavenDb 在后台工作人员上处理其 Lucene 索引,这提供了最终一致性的概念,这意味着它们可能是陈旧的,但仍然提供结果。但是,您可以编写 Map/Reduce 索引,并且使用称为实时投影的功能,您可以将数据的子集和项目映射到索引中,还可以组合来自多种文档类型的数据。
    猜你喜欢
    • 2013-10-31
    • 1970-01-01
    • 1970-01-01
    • 2011-04-10
    • 1970-01-01
    • 2022-01-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多