Perché usare MySQL per un sito Web di dizionari è una cattiva idea?

55

Sto progettando di progettare e impostare un database per memorizzare le voci del dizionario (di solito singole parole) e il loro significato in un'altra lingua. Quindi, ad esempio, il Glossario della tabella deve avere voce e definizione e ogni record di tabella ha un riferimento all'id di un record archiviato Tag(Ogni voce deve avere un tag o una categoria).

Dato che i miei dati hanno una struttura, ho pensato che usare un database SQL (come MySQL) non fosse una cattiva idea; ma la gente dice che MongoDB è molto meglio per le prestazioni.

Sul lato client, l'applicazione deve essere in grado di fornire una casella di ricerca con completamento automatico che utilizza un'API REST fornita dal back-end. È sicuro andare con MySQL in un tale scenario? o dovrei usare MongoDB o ElasticSearch di qualsiasi altra soluzione per questo? Centinaia di record dovrebbero essere archiviati e accessibili in questo modo.

— Aziz Az
fonte

79

Le persone che ti dicono cose non hanno fatto molte ricerche su questo. La lingua con il più grande vocabolario, l'inglese, ha meno di un milione di parole distinte. Questo rientra nell'ambito delle capacità prestazionali di un DB relazionale.

— TheCatWhisperer,

25

Non vedo nulla qui che mi faccia pensare che MySQL non funzioni bene per questo. Le prestazioni in una ricerca semplice non sarebbero un problema e hanno la ricerca full-text se devi percorrere quella strada.

— GrandmasterB,

46

Riguardo a "MongoDB è molto meglio per le prestazioni" —come affermazione non modificata senza chiarimento dell'ambito, questa è una sciocchezza di rango. Per un esempio, vedi Gli strumenti da riga di comando possono essere 235 volte più veloci del tuo Hadoop Cluster (che mi sono imbattuto in un link in The Website Obesity Crisis ).

— Wildcard il

82

Sono così stanco della gente che dice che i database relazionali sono cattivi e MongoDB è migliore perché è più veloce. È come dire che le auto sono cattive e dovremmo usare gli aeroplani perché viaggiano più velocemente. Il mio consiglio è di ignorare consigli come questo.

— Brandon,

13

@Brandon La cosa triste è che tutte le affermazioni "NoSQL sono molto più veloci" di solito si riducono a una spiegazione teorica del perché dovrebbero essere molto meglio, ma in pratica non si applica nemmeno a molti scenari del mondo reale. Vedi ad esempio qui . La loro suite di benchmark usata è open source e disponibile anche su github. Hell CERN gestisce bene il proprio PB di dati con un OracleDB.

— Voo

95

Non posso dirti perché sia una cattiva idea. Posso dirti una serie di ragioni per cui un database relazionale è una buona idea però.

Ricorda che non tutti consulta un dizionario per una definizione. Più volte, un dizionario viene utilizzato per trovare l'ortografia corretta. Ciò significa che non stai solo trovando un ago in un pagliaio , ma stai cercando nel pagliaio degli aghi simili a quello descritto dall'utente (se posso usare un linguaggio).

Non eseguirai solo ricerche chiave principali. Farai ricerche per parole chiave
Le parole possono essere correlate, sia nel significato che nell'ortografia ( leggi, leggi , rosso e canna )

Ogni volta che vedi la parola "correlati" pensa "Database relazionale"
Se hai bisogno di velocità, devi memorizzare nella cache il database relazionale, non un modello di dati relazionali interrotto
Un database correttamente normalizzato accelera le ricerche e le ricerche di chiavi primarie poiché sono disponibili pochi bit da esaminare.
Le persone che affermano che i database normalizzati sono più lenti si riferiscono allo 0,1% dei casi in cui ciò è vero. Nell'altro 99,9% dei casi non hanno effettivamente lavorato con un database veramente normalizzato per vedere le prestazioni in prima persona, quindi ignoratele. Ho lavorato con un database normalizzato. Lo adoro. Non voglio tornare indietro. E non sono un tipo di database. Sono un ragazzo C # / JavaScript / HTML / Ruby.
Le parole hanno un'origine. In effetti, molte parole nella stessa lingua possono avere la stessa origine, che è un'altra parola in una lingua diversa. Ad esempio, curriculum (la cosa che cariciamo sui siti Web dei recruiter in modo da poter ricevere telefonate ed e-mail incessanti per i prossimi 7 anni) è una parola francese.
Un dizionario definisce anche che tipo di parola è (sostantivo, verbo, aggettivo ect). Questo non è solo un pezzo di testo: "sostantivo" ha anche un significato. Inoltre con un database relazionale puoi dire cose come "dammi tutti i nomi per la lingua inglese" e poiché un database normalizzato utilizzerà chiavi esterne e le chiavi esterne hanno (o dovrebbero avere) indici, la ricerca sarà un gioco da ragazzi.
Pensa a come vengono pronunciate le parole. Soprattutto in inglese, molte parole hanno la stessa pronuncia (vedi il mio esempio sopra con read e reed, oppure read e red).

La pronuncia di una parola è, di per sé, un'altra parola. Un database relazionale ti permetterebbe di usare chiavi esterne per qualsiasi pronuncia. Tali informazioni non saranno duplicate in un database relazionale. Viene duplicato come un matto in un database no-SQL.
E ora parliamo di versioni plurali e singolari di parole. :) Pensa "barca" e "barche". O il fatto stesso che una parola sia "singolare" o "plurale".
Oh! E ora parliamo di passato passato, tempo presente, tempo futuro e participio presente (a dire il vero, non so quale sia la merda "participio presente". Penso che abbia qualcosa a che fare con le parole che terminano con "ing" in Inglese o qualcosa del genere).

Cerca "corri" e dovresti vedere gli altri tempi: corsa, corsa, corsa

In realtà, "teso" è un'altra relazione stessa.
L'inglese non lo fa molto, ma il genere è un'altra cosa che definisce una parola. Lingue come lo spagnolo hanno il suffisso per definire se l'oggetto del nome è maschio o femmina. Se è necessario riempire gli spazi vuoti per una frase, il genere è estremamente importante in molte lingue.

Dal momento che non puoi sempre fare affidamento sulle convenzioni linguistiche per determinare il genere (in spagnolo, le parole che terminano con "o" sono maschili / maschili, ma non è vero per tutte le parole), hai bisogno di un valore identificativo: maschio o femmina. Questa è un'altra relazione che un database normalizzato gestisce con grazia anche a milioni di record.

Con tutte le regole contorte e le relazioni tra le parole, e anche le diverse lingue, è difficile per me immaginare questo archivio di dati come un "archivio di documenti" come fornisce una soluzione senza SQL. Ci sono così tante e una così grande varietà di relazioni tra le parole e i loro componenti che un database relazionale è l'unica soluzione sensata.

— Greg Burghardt
fonte

7

Per il n. 1, l'indicizzazione è spesso uno dei punti di forza delle offerte non relazionali, non una debolezza.

— JimmyJames,

61

@JimmyJames Non pensare per un minuto che i sistemi relazionali non stiano usando gli stessi tipi di indici. Molte di queste tecniche furono pioniere in quel mondo.

— Blrfl,

14

"Ogni volta che vedi la parola" correlate "pensa" Database relazionale "". Non sono d'accordo Il "relazionale" nel "database relazionale" si riferisce alle tuple stesse. Correlato è un termine troppo ampio per questa affermazione per contenere qualsiasi acqua

— gardenhead

12

Ci sono anche database di grafici (mi viene in mente Neo4j) che sono esplicitamente focalizzati sulla traversata delle relazioni piuttosto che sull'esecuzione dei join tradizionali. Questo può essere vantaggioso dato che molti dizionari sono in realtà ragnatele di parole; ad esempio, il progetto WordNet utilizza il proprio formato grafico, anziché un RDMS tradizionale.

— Tucuxi,

4

Ho ridimensionato questa risposta solo per "Ogni volta che vedi la parola 'correlata' pensa 'Database relazionale'." È ridicolo . Adoro i database relazionali, ma il modello relazionale non è appropriato per tutti i tipi di relazioni. Anche la tua visione dei dati normalizzati è completamente sbagliata. La normalizzazione dei dati ottimizza le modifiche , poiché i dati non sono duplicati, non ricerche. (Ecco perché i DB di report non si normalizzano. Usano tecniche di modellazione dimensionale e schemi a stella.) Non credo che tu sappia di cosa stai parlando. Gli 80 voti confermano tutte le mie preoccupazioni riguardo ai consigli su questo sito.

— jpmc26,

27

Se vai con l'archivio valori-chiave (che ti offre un modello di programmazione più impoverito) e ti risulta che hai bisogno di più struttura (nel tuo caso, diciamo, aggiungendo una terza lingua), o devi fare query più complesse che coinvolgono join , passerai un sacco di tempo a riorganizzare le tue chiavi, denormalizzare i tuoi dati e / o scorrere tutti i dati per trovare ciò di cui hai bisogno.

Se si inizia con un database relazionale, è possibile elaborare la progettazione e il codice dell'applicazione e provarlo concentrandosi maggiormente sul modello di dati naturali per l'applicazione, piuttosto che inserendolo nel modulo valore-chiave.

Una volta stabilita l'applicazione, è possibile lavorare sulle prestazioni, misurando varie opzioni. Ci sono alcuni trucchi prestazionali da fare in SQL prima di dover cambiare tecnologia. Avrai imparato molto sulla tua applicazione e sarai in una posizione molto migliore per decidere se la relazione ti sta danneggiando e se il valore-chiave funzionerà per il tuo modello di dati.

Se si scopre che il valore-chiave è esattamente ciò di cui la tua applicazione ha bisogno, puoi passare senza aver sprecato un investimento significativo nel modello relazionale, mentre viceversa potresti finire per perdere tempo facendo fare al modello di valore-chiave cose che sono banale nel modello relazionale.

Considera il database relazionale come un acceleratore per progettare, scrivere e rendere operativa la tua applicazione, di fronte a requisiti in continua evoluzione mentre scopri di più sul tuo dominio e sugli utenti.

Quando hai milioni di utenti, dovrai quasi sicuramente riformattare il design, anche se all'inizio hai scelto il valore-chiave.

— Erik Eidt
fonte

13

L'epilogo in questo articolo descrive esattamente uno scenario di modifica dei requisiti che invalida un progetto. Descrive un'applicazione (reale) come "un caso d'uso perfetto per MongoDB", ma poi descrive come un cambiamento relativamente minore nei requisiti, che sarebbe stato banale da implementare in un RDBMS, richiedesse una discreta quantità di lavoro e l'avrebbe spostato ad un caso d'uso che (come spiegano le parti precedenti dell'articolo) non è un buon caso d'uso di Mongo.

— Derek Elkins,

5

L'articolo MongoDB di Sarah è esattamente quello che abbiamo passato con un prodotto 1.0 che avevamo realizzato usando questo prodotto; per 1.1 stavamo usando Postgres.

— Joe,

@DerekElkins, super riferimento, grazie!

— Erik Eidt,

1

"ma poi descrive come un cambiamento relativamente minore nei requisiti, che sarebbe stato banale da implementare in un RDBMS" Certo, ma è vero il contrario. Usiamo RDBMS al lavoro e affrontiamo problemi che sarebbero banali da risolvere in MongoDB. Stranamente, i requisiti software non sempre si adattano perfettamente alle capacità degli strumenti che utilizziamo.

— NPSF3000,

@ NPSF3000, sarebbe fantastico se tu potessi citare un riferimento, come un blog o un testo che ha elaborato questo!

— Erik Eidt,

10

Per un database così piccolo, probabilmente non farà molta differenza per le prestazioni. Un RDBMS standard non è un'idea terribile qui perché presumibilmente, ci dovrebbero essere molte più letture che scritture di una data voce. Le prestazioni non sembrano essere un driver primario per questo. Anche la memorizzazione nella cache nel livello dell'applicazione mitiga tali preoccupazioni.

L'altra considerazione è la replica e la resilienza. I database relazionali tendono ad essere progettati attorno a una singola istanza. Dovresti leggere il teorema della PAC e considerare ciò che conta di più per te.

— JimmyJames
fonte

Come si applica CAP a un'app Web relativamente normale? A seconda del kit è probabile che tu possa sostenere migliaia di connessioni in entrata e un livello di memorizzazione nella cache della pagina può aumentarlo di un ordine di grandezza. La PAC inizia a diventare qualcosa che devi considerare quando i sistemi distribuiti sono l' unico modo per raggiungere il tuo obiettivo.

— Ben

2

@Ben Resiliency è un obiettivo a sé stante. Se un singolo punto di errore non è accettabile per un'applicazione, le soluzioni distribuite offrono una soluzione. Le soluzioni non RDBMS tendono ad essere più orientate a questo. Non è semplicemente il volume da considerare. Latenza e disponibilità sono preoccupazioni. Se il tuo requisito è di avere il 99,9% di uptime. Puoi rimanere inattivo solo per circa 9 ore all'anno e perdere i dati in un db è catastrofico, quindi devi tenere conto di replica / backup / snapshot. È errato pensare che semplifichi necessariamente le cose.

— JimmyJames,

2

Questi database NoSQL sembrano sempre una buona idea all'inizio, ma ti verrà garantito di incorrere in problemi quando inizi a gestire casi limite (ad esempio, dove le parole chiave devono essere ricercate dal loro valore (o parte di), ad esempio.

Sarebbe un'opzione più sicura andare con un database relazionale all'inizio e poi denormalizzare in seguito. MySQL è fantastico per questo tipo di scopi (semplici database relazionali con ricerca testuale), non ci sono troppi casi d'uso in cui lo troverai alle prese con questo tipo di dati. Assicurati solo di avere gli indici impostati correttamente e scoprirai che funzionerà a un livello comparabile (o meglio quando esegui una ricerca di testo) a un database NoSQL e ti darà la flessibilità di modificare la logica dell'app senza essere legato a una struttura di dati concreta.

Man mano che trovi l'uso più comune dei tuoi dati (e se non ti accorgi che non soddisfa le tue esigenze di prestazione), puoi quindi procedere alla de-normalizzazione dei dati inviando a un formato impostato che può essere caricato (e recuperato da) uno schema NoSQL.

— joel.cass
fonte