Dedicato motore di ricerca sfaccettata per trattare con tassonomie dinamiche - aiuta solo con le prestazioni o anche flessibilità?

Question

Ci ho pensato per un po 'sulla modellazione tipico sito e-commerce con tassonomia ebay-like e attributi dipendente da una particolare categoria di prodotto.

In primo luogo si è cercato di scegliere tra EAV e la tabella per classe db eredità di modellazione. Ho scelto la seconda a causa della performance, ma cosa significava stava creando tavolo dedicato per ogni specifica (foglia nell'albero categoria) categoria di prodotto con categoria specifica gli attributi (come la risoluzione per i televisori) modellato come una colonna separata.

Mentre performante questa configurazione non è flessibile, se avete bisogno di aggiungere attributi alle categorie esistenti o l'aggiunta di nuove categorie. Per ciascuna di tali cambiamenti si necessita:

• Alter / create table
• Una nuova forma per il filtraggio withing tale categoria per attributi specifici
• Nuovo codice per la generazione di query db per la ricerca e il filtraggio
• Alcune nuove ViewModels / DTOs e punti di vista per la presentazione di prodotti da nuove categorie

Per far fronte a questa complessità penso che è necessario un qualche tipo di meta rappresentazione di quegli attributi (anche al di fuori dell'applicazione) in XML o anche file di Excel, in modo che ad ogni cambio tutti i codice di cui potrebbe essere generato automaticamente (SQL / query ORM, codice di applicazione, modelli). Così può aiutare con lo sviluppo, ma ancora il test ed è necessaria la distribuzione in più.

A quel punto ho imparato che eBay non usa davvero db relazionali per la ricerca, e che la loro tassonomia è così flessibile, che possano abbastanza rapidamente aggiungere nuove categorie foglia. Anche le loro categorie non sono probabilmente le categorie da un albero gerarchico modellato in db relazionali, ma solo attributi di ricerca (faccette).

Dopo una rapida occhiata in più promettente di installazione dedicato sfaccettata ricerca (esempio Solr separato) Io non sono sicuro se mi potrebbe aiutare a essere flessibili ai cambiamenti tassonomia dato che di solito Solr solo rispecchia in qualche modo DB relazionale, attributi categoria in modo specifico sarebbe devono ancora essere modellato nel DB come metadati DBMS, quindi ad es. forme di generazione UI dinamiche per attributi filtraggio sarebbe difficile a meno che:

1) Vorrei conservare i dati in RDBMS utilizzando EAV fasion e superare i suoi problemi di prestazioni con l'utilizzo di SOLR di ricerca (ma ci sarebbe ancora problemi con EAV disordine, senza l'integrità dei dati dell'ordine etc)

2) vorrei tenere solo il dizionario attributi (es. Solo i loro nomi e tipi) in RDBMS e memorizzare i valori degli attributi specifici in SOLR usando come tipo di archivio dati non relazionali a parte funzione di ricerca. Io non sono convinto di questa soluzione sia (anche se è possibile) dato che l'applicazione sarebbe accoppiato a stretto con solr (es. Edizione del prodotto amministratore CRUD sarebbe interagire con SOLR direttamente).

Quali sono i tuoi pensieri? Pensi che per ogni tipo di tale (performante) la generazione di codice tassonomia flessibilità è inevitabile? Come si gestisce questo? Forse qualche dizionario di dati separati in EAV moda nel DB solo per scopi di generazione di codice? Credo che avrei potuto anche usare qualcosa come MongoDB, ma il codice UI generazione (tempo di esecuzione o meno) sarebbe ancora bisogno di un qualche tipo di metadati.

C'è molta domanda qui, ma non ho voglia di suddividerlo in domande più piccoli visto che sono interessati ad un approccio generale di design quando si tratta di una classe più grande di tali problemi.

Answer 1

Non pretendo di avere una risposta definitiva a tutto questo (è una questione piuttosto aperto che si dovrebbe cercare di rompere in parti più piccole e dipende dalle vostre reali esigenze, infatti io sono tentato di voto per chiuderla), ma mi soffermerò su un paio di cose:

1. vorrei dimenticare modellare questo su un RDBMS. sfaccettata ricerca semplicemente non funziona in uno schema relazionale .
2. IMO questo non è il posto giusto per la generazione del codice. Si dovrebbe progettare il codice in modo che non cambia con le modifiche dei dati (non sto parlando di dello schema le modifiche).
3. Memorizzazione metadati / attributi su un foglio di calcolo Excel sembra una pessima idea. Mi piacerebbe costruire un interfaccia utente per modificare questo, che sarebbe stato memorizzato su Solr / MongoDB / CouchDB / qualunque cosa si sceglie di gestire questo.
4. Solr non "solo specchio relazionale DB". In realtà, Solr è completamente indipendente da database relazionali. Uno dei casi più comuni è Dati di dumping da un RDBMS per Solr (denormalizing dati nel processo), ma Solr è sufficientemente flessibile per lavorare senza alcuna fonte di dati relazionali.
5. sfaccettature gerarchica in Solr è ancora un problema aperto nella ricerca. Attualmente ci sono due approcci distinti oggetto di ricerca ( SOLR-64 , SOLR-792 )

Answer 2

Che cosa succede se si ha diversi tipi di categorie per i diversi tipi di prodotti?

Prendendo l'esempio eBay, avremmo Prodotti che possono essere sia Libri o TV / Display .

I libri hanno titolo e ISBN, e possono essere nella categoria sci-fi, o nella categoria erotico, o nella categoria non-fiction, o categoria autobiografica. O forse hai un libro che si trova nella saggistica, autobiografici categorie erotici.

Display hanno una risoluzione dello schermo e il consumo di watt-(?), E possono essere nella categoria a schermo piatto, categoria CRT, o categoria HD.

Da un punto di vista puramente relazionale, si potrebbe forse modello questo modo:

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

Invece di modellazione attributes dependent on a particular product category, si avrebbe diverse proprietà e categorie dipende dal Tipo / classe del prodotto.

supertipi & sottotipi