Design della ricerca di prodotti nell'applicazione e-commerce?

Stai ottimizzando prematuramente strutture che saranno estremamente costose e di cui quasi certamente non avrai bisogno. L'unico modo in cui un nuovo sistema di e-commerce richiede la scalabilità e le prestazioni di Amazon è se lo stai scrivendo come rimpiazzo diretto per il sistema esistente di Amazon. Altrimenti, il tuo sistema sarà più piccolo (probabilmente di più ordini di grandezza) ed eseguirà meno transazioni al secondo (allo stesso modo) per il prossimo futuro.

Progetta ciò di cui hai bisogno ora, non quello che pensi possa aver bisogno di un anno o cinque lungo la linea. Ma progettalo con un'interfaccia astratta, quindi se hai bisogno di cambiarlo, puoi farlo senza preoccuparti che altre parti del sistema interagiscano con ît. Ecco come si costruisce un sistema scalabile.

Più in particolare, non iniziare con un design dettagliato. Inizialmente, un singolo server di database dovrebbe essere più che adeguato. Se trovi che è necessario ridimensionarlo, la replica è molto più semplice rispetto a sharding, quindi dovrebbe essere il tuo primo approccio. Aggiungere cache al front-end può essere d'aiuto, ma eseguirle sul tuo server front-end ... Le cache distribuite sono meno performanti e improbabili che siano necessarie.

Hai cercato di utilizzare una piattaforma di ricerca consolidata anziché un RDBMS per la ricerca in negozio del cliente?

Ad esempio Solr è open source e utilizzato da diverse aziende e strutture come Hybris in un contesto di e-commerce. Supporta concetti come sinonimi, tokenizzazione localizzata, derivazione o ricerca fuzzy out-of-the-box che richiederebbe un certo sforzo per replicare con un RDBMS. È anche abbastanza semplice scalare usando meccanismi come repliche e sharding. Rimuove la tensione dal tuo RDBMS, che può quindi concentrarsi sulla tracciatura dei dati operativi del prodotto.

Sembra molto complicato, molto incline a prestazioni scadenti e resistente alle principali strategie di sintonizzazione.

C'è una ragione per cui desideri creare un motore / strategia di caching da zero quando un RDBMS decente ne include uno come standard? All'interno di un RDBMS utilizzato principalmente come sorgente di lettura, i dati più utilizzati verranno memorizzati nella cache entro i primi minuti di funzionamento, dopodiché rimarrà disponibile fino a quando non sarà più tra i più utilizzati. Sì, dovrai fare un po 'di lavoro in SQL per avere query ben progettate che supportino le prestazioni del sistema, ma queste informazioni sono piuttosto ben documentate.

È possibile aggiungere più memoria al server del database, aggiungere più core del processore, scalare orizzontalmente aggiungendo istanze del database con mirroring, sebbene sia possibile trovare un'istanza del database in grado di supportare un lotto di server delle app in modo dovrai colpire enormi volumi prima che questo diventi necessario. Questo approccio avrà anche il vantaggio di evitare l'ottimizzazione prematura. Puoi scalare aggiungendo server Web, load balancer, cache e server di database come richiesto e in risposta a problemi del mondo reale piuttosto che creare un'architettura eccessivamente complicata e costosa per un sito web che non decolla come sperato o se lo fa, finisce con problemi in un'area che non avevi previsto.