Cos'è lo sharding e perché è importante?

Penso di capire che lo sharding sta riportando i tuoi dati suddivisi (i frammenti) in un facile da gestire con aggregato che ha senso nel contesto. È corretto?

Aggiornamento : immagino che sto lottando qui. A mio avviso, il livello dell'applicazione non dovrebbe avere attività commerciali che determinano dove archiviare i dati. Nella migliore delle ipotesi dovrebbe essere un client shard di qualche tipo. Entrambe le risposte hanno risposto all'aspetto cosa ma non al perché è importante. Quali implicazioni ha al di fuori degli evidenti miglioramenti delle prestazioni? Questi guadagni sono sufficienti per compensare la violazione MVC? Lo sharding è per lo più importante in applicazioni su larga scala o si applica a applicazioni su scala più piccola?

Il frammento è solo un altro nome per "partizionamento orizzontale" di un database. Potresti voler cercare quel termine per renderlo più chiaro.

Da Wikipedia :

Il partizionamento orizzontale è un principio di progettazione in base al quale le righe di una tabella del database vengono mantenute separatamente, anziché divise per colonne (come per la normalizzazione). Ogni partizione fa parte di un frammento, che a sua volta può trovarsi su un server di database separato o su una posizione fisica. Il vantaggio è che il numero di righe in ogni tabella è ridotto (questo riduce le dimensioni dell'indice, quindi migliora le prestazioni di ricerca). Se lo sharding si basa su alcuni aspetti del mondo reale dei dati (ad es. Clienti europei contro clienti americani), potrebbe essere possibile inferire l'appartenenza al frammento appropriata in modo semplice e automatico e interrogare solo il frammento rilevante.

Altre informazioni sullo sharding:

Innanzitutto, ogni server di database è identico, con la stessa struttura di tabella. In secondo luogo, i record di dati sono logicamente suddivisi in un database frammentato. A differenza del database partizionato, ogni set di dati completo esiste in un solo frammento (a meno che non ci sia il mirroring per backup / ridondanza) con tutte le operazioni CRUD eseguite proprio in quel database. Potrebbe non piacerti la terminologia utilizzata, ma ciò rappresenta un modo diverso di organizzare un database logico in parti più piccole.

Aggiornamento: non romperete MVC. Il lavoro per determinare il frammento corretto dove archiviare i dati sarebbe svolto in modo trasparente dal livello di accesso ai dati. Lì dovresti determinare il frammento corretto in base ai criteri che hai usato per frammentare il tuo database. (Dato che devi frammentare manualmente il database in alcuni frammenti diversi in base ad alcuni aspetti concreti della tua applicazione.) Quindi devi fare attenzione quando carichi e memorizzi i dati da / nel database per usare il frammento corretto.

Forse questo esempio con il codice Java lo rende in qualche modo più chiaro (riguarda il progetto Hibernate Shards ), come funzionerebbe in uno scenario del mondo reale.

Per affrontare il " why sharding": è principalmente solo per applicazioni su larga scala, con molti dati. Innanzitutto, aiuta a ridurre al minimo i tempi di risposta per le query del database. In secondo luogo, è possibile utilizzare macchine più "economiche" più economiche per l'hosting dei dati, anziché un server di grandi dimensioni, che potrebbe non essere più sufficiente.

Se hai domande su un DBMS per il quale la località è piuttosto limitata (ad esempio, un utente attiva solo selezioni con un 'dove username = $ my_username') ha senso mettere tutti i nomi utente che iniziano con AM su un server e tutti dalla Nuova Zelanda dall'altra. Con questo ti avvicini al ridimensionamento lineare per alcune query.

Per farla breve : lo sharding è sostanzialmente il processo di distribuzione di tabelle su server diversi al fine di bilanciare il carico su entrambi allo stesso modo.

Certo, è molto più complicato nella realtà. :)

La frammentazione è un partizionamento orizzontale (per quanto riguarda le righe ) rispetto al partizionamento verticale (per quanto riguarda le colonne ) che è la normalizzazione . Separa database molto grandi in parti più piccole, più veloci e più facilmente gestibili chiamate frammenti di dati. È un meccanismo per ottenere sistemi distribuiti.

Perché abbiamo bisogno di sistemi distribuiti?

• Maggiore disponibilità.
• Espansione più semplice.
• Economia: costa meno creare una rete di computer più piccoli con la potenza di un singolo computer di grandi dimensioni.

Puoi leggere di più qui: Vantaggi del database distribuito

In che modo lo sharding aiuta a raggiungere il sistema distribuito?

È possibile partizionare un indice di ricerca in N partizioni e caricare ciascun indice su un server separato. Se si esegue una query su un server, si otterrà 1/9 dei risultati. Quindi, per ottenere un set di risultati completo, un tipico sistema di ricerca distribuito utilizza un aggregatore che accumulerà risultati da ciascun server e li combinerà. Un aggregatore distribuisce anche query su ciascun server. Questo programma aggregatore si chiama MapReduce nella terminologia dei big data. In altre parole, Distributed Systems = Sharding + MapReduce (anche se ci sono anche altre cose).

Una rappresentazione visiva di seguito.

Lo sharding è per lo più importante in applicazioni su larga scala o si applica a applicazioni su scala più piccola?

La frammentazione è una preoccupazione se e solo se le tue esigenze superano ciò che può essere servito da un singolo server di database. È uno strumento ideale se disponi di dati condivisibili e hai requisiti di scalabilità e prestazioni incredibilmente elevati. Immagino che in tutti i miei 12 anni sono stato un professionista del software, ho riscontrato una situazione che avrebbe potuto beneficiare della condivisione. È una tecnica avanzata con applicabilità molto limitata.

Inoltre, il futuro sarà probabilmente qualcosa di divertente ed eccitante come un enorme "nuvola" di oggetti che cancella tutte le potenziali limitazioni delle prestazioni, giusto? :)

Lo Sharding è stato originariamente coniato dagli ingegneri di Google e puoi vederlo usato abbastanza pesantemente durante la scrittura di applicazioni su Google App Engine. Poiché ci sono forti limitazioni sulla quantità di risorse che le query possono utilizzare e poiché le query stesse hanno limitazioni rigorose, lo sharding non è solo incoraggiato, ma quasi applicato dall'architettura.

Un altro luogo in cui è possibile utilizzare lo sharding è ridurre la contesa sulle entità di dati. È particolarmente importante quando si creano sistemi scalabili fare attenzione a quei dati che vengono scritti spesso perché sono sempre il collo di bottiglia. Una buona soluzione è quella di frammentare quella specifica entità e scrivere su più copie, quindi leggere il totale. Un esempio di questo "contatore frammentato con GAE: http://code.google.com/appengine/articles/sharding_counters.html

Il coccio fa ben più del semplice partizionamento orizzontale. Secondo l' articolo di Wikipedia ,

Il partizionamento orizzontale divide una o più tabelle per riga, generalmente all'interno di una singola istanza di uno schema e di un server di database. Può offrire un vantaggio riducendo le dimensioni dell'indice (e quindi lo sforzo di ricerca) a condizione che esista un modo ovvio, solido e implicito per identificare in quale partizione verrà trovata una determinata riga, senza prima dover cercare nell'indice, ad esempio il classico esempio delle tabelle "ClientiEst" e "ClientiOvest", dove il loro codice postale indica già dove saranno trovati.

La frammentazione va oltre questo: suddivide le tabelle problematiche allo stesso modo, ma lo fa su più istanze potenzialmente dello schema. L'ovvio vantaggio sarebbe che il carico di ricerca per la grande tabella partizionata può ora essere suddiviso su più server (logici o fisici), non solo su più indici sullo stesso server logico.

Anche,

Dividere i frammenti tra più istanze isolate richiede molto più che un semplice partizionamento orizzontale. Gli auspicati guadagni in termini di efficienza andrebbero persi, se l'interrogazione del database richiedesse la query di entrambe le istanze, solo per recuperare una semplice tabella dimensionale. Oltre al partizionamento, lo sharding suddivide quindi grandi tabelle partizionabili tra i server, mentre le tabelle più piccole vengono replicate come unità complete

A mio avviso, il livello dell'applicazione non dovrebbe avere attività commerciali che determinano dove archiviare i dati

Questa è una buona regola, ma come la maggior parte delle cose non sempre corretta.

Quando fai la tua architettura, inizi con responsabilità e collaborazioni. Una volta determinata l'architettura funzionale, è necessario bilanciare le forze non funzionali.

Se una di queste forze non funzionali è un'enorme scalabilità, devi adattare la tua architettura per soddisfare questa forza anche se ciò significa che l'astrazione di archiviazione dei dati ora perde nel livello dell'applicazione.