O mecanismo de pesquisa facetado dedicado para lidar com taxonomias dinâmicas - ajuda apenas com desempenho ou também flexibilidade?

Question

Há algum tempo, penso em modelar o site de comércio eletrônico típico com taxonomia semelhante ao eBay e atributos dependentes de uma categoria de produto específica.

A primeira tentativa foi escolher entre o EAV e a tabela por modelagem de herança de DB de classe. Eu escolhi o último por causa do desempenho, mas o que isso significava foi criar uma tabela dedicada para cada categoria de produto específica (folha na categoria) com atributos de categoria específicos (como resolução para TVs) modelados como uma coluna separada.

Embora o desempenho, essa configuração não é flexível se você precisar adicionar atributos às categorias existentes ou adicionar novas categorias. Para cada uma dessas mudanças, é necessário a seguir:

• ALTER/CREATE TABLE
• Novo formulário para filtrar com essa categoria por atributos específicos
• Novo código para gerar consultas de banco de dados para pesquisa e filtragem
• Alguns novos ViewModels/DTOs e vistas para apresentar produtos de novas categorias

Para lidar com essa complexidade, acho que é necessário algum tipo de meta representação desses atributos (mesmo fora do aplicativo) no arquivo XML ou mesmo do Excel, para que em cada alteração todo o código mencionado possa ser gerado automaticamente (consultas SQL/ORM, código do aplicativo, modelos). Portanto, pode ajudar no desenvolvimento, mas ainda é necessário testar e implantação extra.

Nesse ponto, aprendi que o eBay realmente não usa o banco de dados relacional para pesquisa e que sua taxonomia é tão flexível, que eles podem adicionar rapidamente novas categorias de folhas. Além disso, suas categorias provavelmente não são categorias de uma árvore hierárquica modelada no banco de dados relacional, mas apenas os atributos de pesquisa (facetas).

Depois de dar uma rápida olhada na configuração de pesquisa facetada mais promissora (instância separada do Solr), não tenho certeza se isso poderia me ajudar a ser flexível às mudanças de taxonomia, pois geralmente o solr apenas reflete o banco de dados relacional, portanto, atributos de categoria específicos ainda precisam ser modelado em dB como metadados DBMS, então, por exemplo. Formulários de interface do usuário de geração dinâmica para filtrar atributos seriam difíceis, a menos que:

1) Eu manteria os dados no RDBMS usando a fasion e superava seus problemas de desempenho com o uso da pesquisa de Solr (mas ainda haveria problemas com a bagunça EAV, sem aplicação da integridade de dados etc.)

2) Eu manteria apenas o dicionário de atributos (ou seja, apenas seus nomes e tipos) no RDBMS e armazenava os valores de atributos específicos no Solr, usando-o como tipo de armazenamento de dados não relacionais, além do recurso de pesquisa. Também não estou convencido de que essa solução (mesmo que seja possível), pois a aplicação seria acoplada a SOLR (por exemplo, o Admin Crud da edição de produtos interagiria diretamente com o Solr).

Quais são seus pensamentos? Você acha que para qualquer tipo desse tipo de geração de código de flexibilidade de taxonomia (Performant) é inevitável? Como você lidaria com isso? Talvez algum dicionário de dados separado na moda EAV em DB apenas para fins de geração de código? Acho que também poderia usar algo como o MongoDB, mas a geração de código da interface do usuário (tempo de execução ou não) ainda precisaria de algum tipo de metadados.

Há muitas perguntas aqui, mas eu não queria dividi -lo em perguntas menores, pois estou interessado em uma abordagem geral de design ao lidar com uma classe maior de tais problemas.

Answer 1

Não afirmo ter uma resposta definitiva para tudo isso (é uma pergunta bastante aberta que você deve tentar invadir partes menores e depende de seus requisitos reais, na verdade estou tentado a votar para fechá-lo ) Mas vou comentar algumas coisas:

1. Eu esqueceria de modelar isso em um RDBMS. A pesquisa facetada simplesmente não funciona em um esquema relacional.
2. IMO, este não é o lugar certo para a geração de código. Você deve projetar seu código para que ele não mude com as alterações de dados (não estou falando esquema mudanças).
3. O armazenamento de metadados / atributos em uma planilha do Excel parece uma idéia muito ruim. Eu construiria uma interface do usuário para editar isso, que seria armazenado no Solr / MongoDB / CouchDB / o que você escolher para gerenciar isso.
4. Solr não "Apenas espelhe o banco de dados relacional". De fato, o Solr é completamente independente dos bancos de dados relacionais. Um dos casos mais comuns é Dumping Dados de um RDBMS para SOLR (desnormalizando os dados no processo), mas o Solr é flexível o suficiente para funcionar sem nenhuma fonte de dados relacional.
5. Faceting hierárquico em Solr ainda é uma questão em aberto na pesquisa. Atualmente, existem duas abordagens separadas sendo pesquisadas (Solr-64, Solr-792)

Answer 2

E se você tivesse diferentes tipos de categorias para diferentes tipos de produtos?

Tomando o exemplo do eBay, teríamos Produtos isso pode ser Livros ou TV/Displays.

Os livros têm título e ISBN, e podem estar na categoria de ficção científica, ou na categoria erótica, ou na categoria de não ficção, ou categoria autobiográfica. Ou talvez você tenha um livro que esteja na não ficção, categorias eróticas autobiográficas.

Os monitores têm resolução de tela e consumo de Watt (?), E podem estar na categoria de tela plana, categoria CRT ou HD.

Do ponto de vista puramente relacional, você poderia pode ser modele isso assim:

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

Em vez de modelar attributes dependent on a particular product category, você teria propriedades diferentes e categorias dependente do Tipo/classe do produto.

Ver Supertipo e subtipos