Che cosa ha a che fare con gli archivi di chiavi / valori per semplificare la suddivisione del database?
Perché se non utilizzo un archivio di chiavi / valori, posso facilmente ritagliare anche il mio database giusto?
(Come dire, posso facilmente dire che gli utenti con nomi che iniziano con questo personaggio avranno i loro dati memorizzati in questo server, e quelle stesse tabelle non sono archivi chiave / valore. fare con condivisione del database?)
Divulgazione - Sto lavorando per ScaleBase - chi costruisce una soluzione trasparente di Sharding del database.
Non penso davvero che questi due termini abbiano a che fare l'uno con l'altro. Per scalare i database relazionali (a.k.a database SQL) di solito si usa il sharding. Ma, se non hai bisogno del database relazionale, puoi usare le soluzioni NoSQL, alcune delle quali sono basate su valori-chiave (come la famosa Cassandra, ma vedi qui per ulteriori informazioni).
Quindi la prima è una soluzione per il ridimensionamento del database, la seconda è un'alternativa di database relazionale.
Non è tanto che il valore-chiave sia più facile da frammentare quanto è più difficile mantenere le migliori qualità dei database relazionali quando si taglia. Ad esempio se hai un campo unico, la sua unicità deve essere convalidata attraverso i frammenti. La convalida della chiave esterna deve anche attraversare i frammenti.
Anche le transazioni atomiche che devono controllare o toccare più server sono problematiche.
O si perdono le prestazioni e possibilmente si introducono complicazioni o si rinuncia a quelle funzionalità e si perde la maggior parte dei vantaggi dell'utilizzo di un database relazionale in primo luogo.
I database a valori-chiave presentano in genere meno funzioni rispetto ai database relazionali e tale semplicità rende il ridimensionamento anche più semplice. Puoi anche simulare un database relazionale, ma non è così che sono ottimizzati.
Se si escogitano le chiavi in modo prevedibile, è facile dividere i dati.
Potrebbe essere semplice come; Tutti i tasti che iniziano con "A" sono presenti nel server1, tutti i tasti che iniziano con "B" risiedono nel server2 ... Quindi devi solo dare un'occhiata alla chiave per sapere quale server dovresti interrogare.
Di solito utilizzi una qualche forma di hashing coerente sulla chiave per sapere quale server interrogare.
Non esiste una correlazione diretta, ma entrambi vengono spesso nel contesto di servizi su larga scala, ovvero "servizi cloud".
In quel tipo di sistema i dati devono essere distribuiti su più server (perché c'è troppo da gestire per un singolo server). Questo è ciò che significa "database sharding".
Nei sistemi su larga scala l'utilità delle soluzioni SQL diminuisce (perché il modello ACID non funziona bene quando distribuito su più macchine) e perde molti dei vantaggi rispetto ai sistemi più semplici come gli archivi di chiavi / valore. Il che rende gli store chiave / valore più attraenti dal momento che sono in genere più semplici ed economici da eseguire.
Vedi questi per maggiori dettagli: nosql ed eventuale consistenza tutorial su nosql
Rispondere direttamente alla tua domanda è difficile dividere un database relazionale, fisicamente può essere fatto in modo relativamente semplice se hai l'hardware corretto e un database di livello Enterpise (hai bisogno di Enterprise Edition di SQL Server, per esempio non della versione standard) . Ma farlo correttamente richiede qualcuno che comprenda i sistemi di database ad alte prestazioni e l'ottimizzazione delle prestazioni e qualcuno che comprenda a fondo la struttura dei dati (si desidera che gli elementi correlati finiscano nella stessa partizione). Il tuo attuale design può o non può prestarsi a partioning senza modifiche. Un database progettato senza i campi appropriati per eseguire il partizionamento avrebbe bisogno di essere aggiunti. Pianificare quale sia il modo migliore per partizionare, progettare le partions e testarle può richiedere molto tempo anche se il codice SQL effettivo per impostare le partizioni è relativamente semplice.
Esistono molti database relazionali di dimensioni terabyte e generalmente sono partizionati per le prestazioni. Tuttavia, per fare ciò correttamente, è necessario che qualcuno con competenze avanzate nel database non solo partiziona i dati ma si assicuri che le query siano ottimizzate per le prestazioni e che il progetto funzioni correttamente con il carico richiesto. Una struttura di dati mal progettata su hardware inadeguata rispetto a query mal progettate (ad esempio quelle con sottoquery correlate) non funzionerà mai, indipendentemente dal modo in cui si suddividono i dati. La maggior parte degli sviluppatori di applicazioni non ha le competenze necessarie per progettare correttamente questa roba e quindi si lamentano che i database relazionali non sono abbastanza veloci. Questo è solo un segno di incompetenza nella progettazione del database, non della reale capacità del database di esibirsi con un gran numero di utenti e un'enorme quantità di dati. Ho visto siti web mal progettati e performanti, vuol dire che Java o C # non possono essere utilizzati per produrre un sito ben progettato?
Se hai già i dati in un database relazionale, è probabilmente meglio assumere un esperto di database per configurare e gestire i tuoi database per una crescita che provi a convertire in una soluzione noSQL. La necessità di partizionare è irrilevante rispetto alla scelta di utilizzare un archivio di valori chiave. Vuoi solo usarli per alcuni casi speciali specifici. Per i dati che devono essere affidabili e coerenti internamente, un archivio di valori chiave è un disastro in attesa di accadere. Non dimenticare che esiste un costo enorme associato alla conversione dei dati relazionali in un nuovo tipo di metodo di archiviazione dei dati e verranno introdotti nuovi bug, alcuni dei quali possibili errori fatali. Se il tuo database corrente non è in grado di gestire il carico previsto (ed è proprio qui che mi viene in mente Access, hai notato mySQL e SQL Server entrambi in grado di gestire enormi database se progettati correttamente), allora è meno rischioso convertirlo in un'azienda più grande tipo di database relazionale piuttosto che convertire un archivio di valori-chiave.
Per i dati che possono perdere consistenza senza un problema enorme come i siti di social networking (è fastidioso se perdono il tuo ultimo post ma non sono critici per il business) o motori di ricerca (Google non sta andando fuori dal business perché ha perso il riferimenti al tuo sito web temporaneamente), quindi noSQL e gli archivi di valori chiave vanno bene, ma non troverai molte aziende che si fidano delle loro transazioni finanziarie importanti per questo tipo di data store e c'è una ragione per questo. Inoltre, l'uso di una struttura di valori-chiave all'interno di un database relazionale spesso causa problemi di prestazioni in quanto non ottimizzati per quel tipo di dati.
C'è un posto per entrambi i tipi di database, ma memorizzano due tipi di dati molto diversi. Non è tanto la velocità (che può essere ottimizzata per essere eccellente per entrambi i tipi di database da qualcuno che sa veramente cosa sta facendo) quanto riguarda il modo in cui i dati vengono utilizzati e interrogati e che tipo di controlli interni per la qualità dei dati e la coerenza sono necessari. E non vi è alcun motivo per cui non è possibile utilizzare entrambi nello stesso progetto, uno per i dati che non devono essere ATOMIC e uno per i dati transazionali di cui è necessario applicare le relazioni chiave.
Leggi altre domande sui tag database nosql mysql sql-server data