【问题标题】:Can someone explain Magentos Indexing feature in detail?有人可以详细解释 Magentos Indexing 功能吗?
【发布时间】:2011-06-24 03:17:54
【问题描述】:

我有点了解 Magento 中的索引是如何工作的,但我还没有看到任何好的文档。我有点想知道以下内容。

  • 工作原理
  • 它的目的是什么
  • 为什么重要
  • 每个人都应该了解哪些细节
  • 任何其他可以帮助人们完全理解索引是什么以及它在 Magento 中的使用方式的方法

我认为拥有这些信息对于我船上没有完全了解索引过程的其他人非常有用。

更新: 在对我的问题和 Ankur 的回答发表评论之后,我想我在我对普通数据库索引的了解中遗漏了一些东西。那么这只是 Magento 处理索引的版本吗?一般来说,在数据库索引方面得到我的答案对我来说更好吗,例如这里的链接 How does database indexing work?

【问题讨论】:

  • 不熟悉Magento,但是你的意思是数据在Magento中的存储方式吗?索引意味着 MySQL 索引,已经有大量可用信息。
  • 在 Magento 中,有很多索引表用于重新索引数据库中的数据。如果你说的是同一件事,我不是那么熟悉。也许是这样,也许我错过了一些关于正常 MySQL 索引的东西,如果这是同一件事。

标签: php mysql database magento indexing


【解决方案1】:

Magento 索引与普通数据库索引不同,更像是数据库非规范化 (http://en.wikipedia.org/wiki/Denormalization) 过程。在大多数情况下,它采用 EAV 结构并使其可用于平面表结构,这无疑可以更快地访问和搜索。

如果您的正常 EAV 查询将是 200 次左连接以获取目录中的所有产品以及其属性和分层导航值的数据,那么在“索引”后,该数据可通过非规范化数据结构获得,以便更快地查询/访问

【讨论】:

    【解决方案2】:

    Magento 的索引仅在精神上类似于数据库级索引。正如 Anton 所说,这是一个非规范化过程,以允许更快地运行站点。让我试着解释一下 Magento 数据库结构背后的一些想法,以及为什么它需要索引才能快速运行。

    在更“典型”的 MySQL 数据库中,用于存储目录产品的表的结构如下:

    PRODUCT:
        product_id INT
        sku        VARCHAR
        name       VARCHAR
        size       VARCHAR
        longdesc   VARCHAR
        shortdesc  VARCHAR
        ... etc ...
    

    这对于检索来说很快,但它给电子商务软件留下了一个基本问题:当你想添加更多属性时你会怎么做?如果你卖玩具,而不是尺寸栏,你需要age_range?好吧,您可以添加另一列,但应该清楚的是,在大型商店(例如沃尔玛)中,这将导致 90% 的行为空,并且几乎不可能尝试维护新属性。

    为了解决这个问题,Magento 将表格拆分为更小的单元。我不想在这个答案中重新创建整个 EAV 系统,所以请接受这个简化模型:

    PRODUCT:
        product_id INT
        sku        VARCHAR
    
    PRODUCT_ATTRIBUTE_VALUES
        product_id   INT
        attribute_id INT
        value        MISC
    
    PRODUCT_ATTRIBUTES
        attribute_id
        name
    

    现在可以随意添加属性,方法是在product_attributes 中输入新值,然后将相邻记录放入product_attribute_values。这基本上就是 Magento 所做的(对数据类型的尊重比我在这里展示的要多一点)。事实上,现在两个产品完全没有理由拥有相同的字段,因此我们可以创建具有不同属性集的整个产品类型

    但是,这种灵活性是有代价的。如果我想在我的系统中找到一件衬衫的color(一个简单的例子),我需要找到:

    1. 商品的product_id(在产品表中)
    2. attribute_id 对应于color(在属性表中)
    3. 最后是实际的value(在attribute_values 表中)

    Magento 以前是这样工作的,但速度非常慢。因此,为了获得更好的性能,他们做出了妥协:一旦店主定义了他们想要的属性,就从头开始生成大表。当某些东西发生变化时,从太空中对其进行核打击并重新生成它。这样,数据主要以我们很好的灵活格式存储,但从单个表中查询。

    这些生成的查找表是 Magento “索引”。当您重新索引时,您正在炸毁旧表并再次生成它。

    希望能澄清一点!

    谢谢, 乔

    【讨论】:

    • 那么,当您查找产品的价格时,是否会查询 catalog_product_index_price 而不是 catalog_product_entity_decimal 以及需要这样做的任何其他联接?
    • 是的,它将使用价格指数。这实际上考虑了另一种情况:最低和最高定价只能通过使用一些 PHP 代码来确定,但通常会显示在目录中。因此,通过使用索引,您可以在索引时计算它并重新使用价格索引的结果。
    • 好的,我现在明白了很多,现在我开始查看这些表实际上是从中提取的代码,它开始组合在一起。
    • 我要补充一点,目录页面和分层导航广泛使用索引。但我认为实际的产品页面不会。一旦您查看了实际的产品页面,我认为 magento 只是查看常规 eav 表来提取数据。
    • 这个答案基本上是关于 FLAT 表 - 而不是关于价格指数等。
    【解决方案3】:

    Magento 索引在某种程度上类似于普通的数据库索引,但不同的是在某些情况下您需要手动进行。

    当您进行索引时,例如目录索引,然后它会在单独的表中为不同类型的排序输入您的目录产品,一个小例子是商店,假设您有不同商店的产品和不同的详细信息,然后首先它会从单独的表中的复杂连接中获取记录(当你将执行索引时)

    另一个最好的例子是分层导航索引:如果您将运行分层导航索引,那么它将在产品数据库中检查所有商店的过滤器属性,然后在每个属性上,产品如何可用,它还将存储该值。

    如果您正在做一些直接的数据库更改或通过您自己的自定义代码,则主要需要这种类型的索引

    如果您对索引有其他疑问,请告诉我

    【讨论】:

      猜你喜欢
      • 2011-01-09
      • 2021-04-11
      • 1970-01-01
      • 2013-08-26
      • 1970-01-01
      • 2020-04-20
      • 1970-01-01
      • 2021-05-27
      • 2021-04-30
      相关资源
      最近更新 更多