I database NoSQL sono la scelta migliore per interrogare in modo più efficiente grandi quantità di dati?

3

Stiamo progettando di creare un sito web di viaggi in cui integreremo più API (ad esempio DOTW, GTA, Expedia) per gli hotel. Inizialmente ho provato a usare MySQL ma poiché ci sono enormi quantità di dati negli hotel e può contenere numerose relazioni "da uno a molti" con immagini, servizi e camere, la ricerca diventa molto lenta quando disponiamo di dati per circa 200000 hotel. Anche il recupero di tutti i dettagli per un solo hotel può comportare una query JOIN da almeno quattro tabelle e la scansione su tutti i record degli hotel. Quindi stiamo progettando di migrare il nostro schema di prodotto su qualsiasi database NoSQL per rendere la nostra ricerca il più veloce possibile.

Inoltre a volte abbiamo bisogno di eseguire alcuni scheduler sul nostro database per eliminare i duplicati dal nostro database e anche per aggiornare gli hotel appena aggiunti che vengono inviati dai nostri fornitori.

Il nostro stack tecnologico è fondamentalmente su Java, J2EE insieme a Springs e Hibernate.

Ho letto di MongoDB, Cassandra, Redis ed ElasticSearch, ma ora sono confuso se semplicemente usando questi strumenti puoi ottimizzare le prestazioni di ricerca del sito web. In caso affermativo, quali caratteristiche differiscono tra questi strumenti che potrebbero aiutarmi a prendere una decisione?

    
posta Ankur Jain 09.01.2015 - 10:34
fonte

4 risposte

4

Penso che i risultati della ricerca possano migliorare notevolmente attraverso una serie di tecniche o approcci di progettazione di database che miglioreranno le prestazioni nel tipico RDBMS. Suggerisco di esaminare e possibilmente prototipare i seguenti miglioramenti per vedere se ti aiutano nei test delle prestazioni prima di impegnarti in una tecnologia di database completamente nuova che richiederà una grande quantità di nuovi apprendimenti ed esperienze da padroneggiare.

In sostanza, si vuole evitare la mentalità di un "Magic Bullet". C'è un equivoco che NoSQL può in qualche modo risolvere magicamente tutti i nostri problemi e problemi di prestazioni con RDBMS e che potrebbe essere vero a volte, ma dovresti provare a migliorare prima la progettazione del tuo database.

Identifica i tuoi requisiti non funzionali

Identifica in modo specifico i tuoi requisiti non funzionali accettabili per le prestazioni. Determina il tempo di attesa medio massimo della query e utilizzalo come obiettivo. Se riesci a modificare la progettazione del tuo database per ottenere ciò, non devi rearchitect il tuo software in una soluzione NonSQL.

Evita colonne binarie

Sembra che con la tabella Image sia presente un supporto di tipo binario memorizzato nelle tabelle del database. Sebbene questo dipenda in gran parte dal fatto che il database scelto implementi le colonne binarie, è generalmente accettato che le colonne binarie possano danneggiare le prestazioni delle tue query. Le colonne binarie generalmente invalidano i vantaggi che un indice su una colonna della tabella può fornire. Se non mi credi, unisciti alla tabella Image ed esegui un piano di spiegazioni e nota come probabilmente non viene utilizzato l'indice.

Utilizza una rete di Content Delivery

Invece di memorizzare immagini e contenuti multimediali nei record del database, memorizzare un URL che un'applicazione può utilizzare per recuperare quell'immagine, magari in un browser. Tale URL può puntare a un'immagine unica che viene archiviata e gestita in una rete di Content Delivery. Esistono numerosi servizi cloud in grado di fornire questo o è possibile creare il proprio con un numero di strumenti. Ciò dovrebbe rendere tutti gli aspetti della tua applicazione molto più efficienti.

Valuta gli indici della tabella

Assicurati che se non stai usando gli indici li costruisci per le colonne su cui generalmente filtri o ti unisci contro. Per essere onesti, 4 tavoli non sono un gran numero di join per un tavolo, quindi se segui queste linee guida dovresti vedere almeno un modesto miglioramento delle prestazioni.

Se segui queste linee guida e non riesci ancora a raggiungere i tuoi requisiti di performance, forse puoi valutare varie soluzioni NoSQL e cercare funzionalità che potrebbero aiutarti.

    
risposta data 09.01.2015 - 16:43
fonte
4

Even fetching all details for just one hotel may results in a JOIN query from at least four tables, and scanning over all hotels records.

Una query di quattro join è assolutamente banale se si hanno gli indici appropriati per tutti i join.

La seconda parte di questa domanda è molto più preoccupante. Perché la scansione su tutti i record? È a causa di indici mancanti? o hai bisogno di alcuni dati aggregati? forse confrontare con una media, dare un indice di classifica, qualcosa di simile? In tal caso, passare a NoSQL non sarà d'aiuto; ciò di cui hai bisogno è precalcolare tali aggregati in modo da poter ricavare rapidamente i dati per ciascun hotel.

    
risposta data 09.01.2015 - 17:58
fonte
2

NoSQL generalmente non è molto buono con i dati relazionali. NoSQL è spesso ottimo per dati non relazionali ma strutturati come documenti o serie storiche.

Le tue relazioni "da uno a molti" possono assomigliare a un documento: ad esempio, un documento "hotel" può trasportare tutte le sue immagini, informazioni sulla camera, ecc. memorizzate insieme e recuperate con una sola operazione.

D'altra parte, se si vede la necessità di un% dijoin SQL, non esitare e utilizzare un database SQL. Questi sono dannatamente efficienti con i join e sono abbastanza bravi a tirare grandi quantità di dati in una query.

Le ricerche

WRT "diventano molto lente", è difficile dire cosa è successo senza vedere prima la struttura del DB. Solitamente aggiungere un indice rilevante (o rilasciare un irrilevante) può velocizzare le cose. Anche la rielaborazione dello schema per rendere efficienti le poche query più importanti è nota.

Non penso che NoSQL ti aiuterà troppo nella ricerca, almeno non prima che potessi vedere i tipi di ricerche che stai per eseguire.

    
risposta data 09.01.2015 - 16:44
fonte
2

Perché o / o?

Ho lavorato con successo con un approccio ibrido, usando un db relazionale (SQL Server, ma scegli il tuo preferito) per contenere dati che richiedono una struttura relazionale - la maggior parte di questi sono gli ID che collegano tutti i vari oggetti del dominio, molto poco dati testuali e certamente no blob - e un nosql db (Dynamo) per contenere grandi dati relativamente non strutturati, in genere documenti JSON raccolti da fonti di terze parti. Ovviamente la codifica è più complessa ma ti consente di ottenere il meglio da entrambi i mondi.

Ovviamente può essere che un approccio puro sia in definitiva il migliore per te, ma l'ibrido può anche aiutare nel refactoring passo-passo.

    
risposta data 09.01.2015 - 17:54
fonte

Leggi altre domande sui tag