用于处理动态分类的专用多面搜索引擎 - 仅有助于提高性能还是提高灵活性？答案

【问题标题】：Dedicated faceted search engine for dealing with dynamic taxonomies - helps just with performance or also flexibilty?用于处理动态分类的专用多面搜索引擎 - 仅有助于提高性能还是提高灵活性？
【发布时间】：2011-01-06 01:44:23
【问题描述】：

我一直在考虑使用类似 ebay 的分类法和依赖于特定产品类别的属性来建模典型的电子商务网站。

第一次尝试是在 EAV 和 Table Per Class 数据库继承建模之间进行选择。我选择后者是因为性能，但这意味着为每个特定（类别树中的叶子）产品类别创建专用表，并将特定类别属性（如电视的分辨率）建模为单独的列。

如果您需要将属性添加到现有类别或添加新类别，则此设置虽然高效，但并不灵活。对于每个此类更改，都需要以下内容：

更改/创建表
用于按特定属性过滤此类类别的新表单
用于生成用于搜索和过滤的数据库查询的新代码
一些新的视图模型/DTO 和用于展示新类别产品的视图

为了应对这种复杂性，我认为需要在 xml 甚至 excel 文件中（甚至在应用程序之外）对这些属性进行某种元表示，以便在每次更改时自动生成所有提到的代码（sql/ orm 查询、应用程序代码、模板）。所以它可以帮助开发，但仍然需要测试和额外的部署。

那时我了解到 ebay 并没有真正使用关系数据库进行搜索，而且他们的分类非常灵活，可以很快添加新的叶类别。此外，它们的类别可能不是在关系数据库中建模的分层树中的类别，而只是搜索属性（方面）。

在快速浏览了最有希望的专用分面搜索设置（单独的 Solr 实例）后，我不确定它是否可以帮助我灵活地应对分类变化，因为通常 Solr 只是以某种方式反映关系数据库，因此特定的类别属性会仍然必须在 DB 中建模为 DBMS 元数据，例如。用于过滤属性的动态生成 UI 表单会很困难，除非：

1) 我会使用 EAV fasion 将数据保存在 RDBMS 中，并通过使用 SOLR 搜索克服其性能问题（但仍然存在 EAV 混乱、没有数据完整性执行等问题）

2) 我会在 RDBMS 中只保留属性字典（即它们的名称和类型），并将特定属性值存储在 SOLR 中，使用它作为一种非关系数据存储，而不是搜索工具。我也不相信这个解决方案（即使它是可能的），因为应用程序将与 solr 紧密耦合（即产品版本管理员 CRUD 将直接与 SOLR 交互）。

你的想法是什么？您认为对于任何类型的（高性能）分类法灵活性代码生成是不可避免的吗？你会怎么处理？也许只是为了代码生成目的，在数据库中以 EAV 方式的一些单独的数据字典？我想我也可以使用 MongoDB 之类的东西，但是 UI 代码生成（运行时与否）仍然需要某种元数据。

这里有很多问题，但我不想把它分解成更小的问题，因为在处理更大类的此类问题时，我对通用设计方法感兴趣。

【问题讨论】：

标签： database-design solr nosql faceted-search

【解决方案1】：

我并没有声称对所有这些都有明确的答案（这是一个相当开放的问题，您应该尝试将其分解为较小的部分，这取决于您的实际要求，实际上我很想投票关闭它）但我会评论一些事情：

我会忘记在 RDBMS 上对此进行建模。 Faceted search just doesn't work in a relational schema。
IMO 这不是代码生成的正确位置。您应该设计您的代码，使其不会随数据更改而更改（我不是在谈论 schema 更改）。
在 Excel 电子表格上存储元数据/属性似乎是个非常糟糕的主意。我会构建一个 UI 来编辑它，它将存储在 Solr / MongoDB / CouchDB / 任何你选择管理它的地方。
Solr 不“只是镜像关系数据库”。事实上，Solr 完全独立于关系数据库。最常见的情况之一将数据从 RDBMS 转储到 Solr（过程中的非规范化数据），但 Solr 足够灵活，无需任何关系数据源即可工作。
Hierarchical faceting in Solr 仍然是研究中的一个悬而未决的问题。目前有两种不同的方法正在研究中（SOLR-64、SOLR-792）

【讨论】：

广告 1：分面搜索/导航本身不是我的首要任务，我可以使用具有不同输入数据类型（字符串、价格、范围等）的常规“高级搜索”表单。我只是在考虑方面是否有助于实现灵活性。广告 2：什么是数据，什么是模式取决于一个观点。在 EAV 中，一切都是数据，OTOH 如果我选择使用“分辨率”作为列，它就会变成模式。如果我想将新的属性类型添加到电视类别（例如 USB 端口的数量），它也可以描述为架构更改。 ad 4. 有趣，你知道这方面的任何例子吗？
1.如果您想要分层类别，那么不，因为 5. 2. 我承认这是主观的，但 IMO 如果您必须生成代码来容纳新类别，那么它是架构更改，不是对您的应用程序的数据更改。 4. 任何基于爬虫的应用程序，例如谷歌或lucidimagination.com/About-Search。

【解决方案2】：

如果您为不同类型的产品设置不同类型的类别会怎样？

以 eBay 为例，我们的 Products 可以是 Books 或 TV/Displays。

书籍有书名和 ISBN，可能属于科幻类、色情类、非小说类或自传类。或者，也许您有一本书属于非小说类、自传色情类。

显示器具有屏幕分辨率和功耗 (?)，并且可能属于纯平屏幕类别、CRT 类别或高清类别。

从纯粹的关系的角度来看，您可以也许这样建模：

[Product]-(1)------(1)-[  Book  ]-(n)------(m)-[ book_category ]
| id    |              | title  |              |  name         |
| price |              | ISBN   |
| ...   |
| ...   |-(1)---(1)-[   display  ]-(n)------(m)-[ display_category ]
                    | resolution |              |  name            |
                    |   watts    |

您将拥有不同的属性和类别，而不是建模attributes dependent on a particular product category，这取决于产品的类型/类。

见supertypes & subtypes

【讨论】：