Cos’\u00c8 lo Sharding dei Database?<\/h2>\n
Lo sharding \u00e8 una tecnica di ottimizzazione che distribuisce le tabelle su altri server di database. \u00c8 simile al partizionamento, nel senso che entrambi prevedono la suddivisione dei dati in sottoinsiemi pi\u00f9 piccoli. La differenza \u00e8 che lo sharding distribuisce questi sottoinsiemi su server diversi, mentre il partizionamento li memorizza in un unico database. Questi server usano lo stesso motore di database e lo stesso tipo di hardware per ottenere un livello di prestazioni simile per tutti gli shard.<\/p>\n
Lo sharding mira a realizzare un’architettura share-nothing, eliminando i colli di bottiglia dell’elaborazione e i singoli punti di errore.<\/p>\n Lo sharding pu\u00f2 essere implementato in due modi: in orizzontale<\/a> e in verticale. Lo sharding orizzontale divide la tabella in base alle righe, mentre quello verticale in base alle colonne.<\/p>\n In questo senso, lo sharding \u00e8 come il partizionamento, che divide le tabelle di grandi dimensioni in tabelle pi\u00f9 piccole.<\/p>\n Lo sharding orizzontale \u00e8 efficace per i database in cui la maggior parte delle query restituisce un sottoinsieme di righe, come per esempio un database di clienti che restituisce dati (come nome, indirizzo, email e cos\u00ec via) in una sola volta.<\/p>\n Lo sharding verticale \u00e8 efficace per i database le cui query restituiscono singole colonne. Per esempio, se il database dei clienti restituisce il nome o l’email del cliente separatamente, potete separare il nome e l’email in cluster diversi.<\/p>\n Di seguito vediamo alcuni dei vantaggi dello sharding dei database.<\/p>\n Potete scalare il vostro database in senso verticale o orizzontale. La scalabilit\u00e0 verticale si riferisce all’aggiunta di pi\u00f9 unit\u00e0 di elaborazione centrale (CPU) e memoria ad accesso casuale (RAM) al server per migliorare le prestazioni. Il vertical scaling \u00e8 una soluzione utile per i database di piccole e medie dimensioni. Tuttavia, quando i dati crescono, il vertical scaling diventa impraticabile. Non c’\u00e8 molta potenza che si possa aggiungere a un singolo server.<\/p>\n Il ridimensionamento orizzontale \u00e8 pi\u00f9 flessibile. Vi permette di scalare il vostro database in base alle esigenze aggiungendo altri server al sistema. Ognuno di questi server fornisce risorse a diversi shard del database. Questo distribuisce il carico di lavoro e migliora la capacit\u00e0 del sistema di gestire un numero maggiore di richieste.<\/p>\n Gli shard hanno solo poche righe e colonne. Per questo motivo, l’elaborazione delle query del database<\/a> richiede meno tempo. Al contrario, un’interrogazione su un database non shardato potrebbe richiedere una ricerca su centinaia o addirittura migliaia di righe.<\/p>\n Le interruzioni del database si verificano per vari motivi, tra cui la cancellazione accidentale dei dati, gli errori di connessione e gli attacchi di cybersecurity. Lo sharding riduce al minimo gli effetti delle interruzioni. Poich\u00e9 ogni shard \u00e8 autonomo, solo lo shard interessato subisce un’interruzione. Per esempio, se avete quattro shard e si verifica un’interruzione in uno di essi, solo il 25% delle operazioni ne risentir\u00e0.<\/p>\n Sebbene lo sharding migliori l’affidabilit\u00e0 e la disponibilit\u00e0 di un database, la sua implementazione \u00e8 complessa<\/a>. L’utilizzo di un’architettura di sharding sbagliata pu\u00f2 rallentare le prestazioni e causare la perdita di dati.<\/p>\n Verificate di scegliere una tecnica di sharding che permetta una distribuzione equilibrata dei dati su tutti gli shard. Senza questo equilibrio, rischiate di creare degli hotspot del database, che si verificano quando uno shard memorizza la maggior parte dei dati mentre gli altri shard rimangono praticamente vuoti. Questo riduce il throughput di scrittura del singolo shard.<\/p>\n Per risolvere questo problema, potreste partizionare ulteriormente lo shard non bilanciato, ma questo processo \u00e8 impegnativo e potrebbe causare la chiusura del database durante la migrazione dei dati.<\/p>\n Un altro inconveniente dello sharding \u00e8 che le unioni SQL che coinvolgono pi\u00f9 tabelle in shard diversi possono diventare troppo lente e peggiorare le prestazioni. Tuttavia, con la giusta architettura, potete evitare questo problema.<\/p>\n Potete implementare lo sharding utilizzando tre architetture:<\/p>\n L’architettura che scegliete dipende dal vostro caso d’uso.<\/p>\n In un’architettura di sharding basata su chiavi o hashed<\/a>, un’applicazione di database usa una chiave di shard per individuare uno shard. Una funzione di hashing esegue l’hashing del valore della chiave di sharding e l’output mappa i dati in un determinato shard. Una semplice funzione di hashing pu\u00f2 essere il modulo della chiave e il numero di shard.<\/p>\n La funzione di hash pu\u00f2 accettare pi\u00f9 di una chiave di sharding. Per questo motivo, lo sharding basato sulle chiavi \u00e8 adatto ai record di dati che possono avere chiavi condivise. La distribuzione algoritmica dei dati riduce al minimo la possibilit\u00e0 di creare hotspot del database in cui uno shard contiene pi\u00f9 dati dell’altro.<\/p>\n Tuttavia, poich\u00e9 la distribuzione si basa solo sulla funzione di hashing, \u00e8 impossibile raggruppare logicamente i dati. Di conseguenza, le operazioni di database che richiedono dati da pi\u00f9 shard possono essere inefficienti perch\u00e9 richiedono la lettura dei dati da ogni shard.<\/p>\n Lo sharding basato sull\u2019intervallo<\/a> prevede lo sharding di un database in base a un intervallo di valori specificato.<\/p>\n Usa una chiave di sharding per determinare a quale shard assegnare un valore. L’applicazione di database controlla lo shard che corrisponde alla chiave di sharding in una tabella di ricerca e memorizza i dati. Per questo motivo, lo sharding basato sul range \u00e8 facile da progettare e implementare.<\/p>\n Per esempio, potete usare il valore dell’ID utente in un database di utenti come chiave di sharding. Potreste archiviare gli utenti con ID compreso tra 0 e 2.000 in uno shard, quelli tra 2.000 e 4.000 in un altro shard e cos\u00ec via.<\/p>\n Lo sharding basato sull’intervallo pu\u00f2 causare hotspot nel database. Considera un database di utenti in cui la maggior parte dei tuoi ID si trova tra 2.001 e 4.000. Il processo li assegna a un unico shard, creando uno squilibrio nel tempo. Lo sharding basato sull’intervallo, quindi, funziona meglio per i dati distribuiti in modo uniforme.<\/p>\n Lo sharding basato su directory<\/a> raggruppa i dati logicamente correlati nello stesso shard. Usa una tabella di ricerca contenente un elenco di mappature per ogni entit\u00e0 del database. Ogni mappatura corrisponde a uno shard del database.<\/p>\n Lo sharding basato su directory \u00e8 pi\u00f9 flessibile di quello basato su range o chiavi perch\u00e9 potete aggiungere dati agli shard in modo dinamico. Non ci sono funzioni di sharding da seguire o valori di intervallo da rispettare. Questa flessibilit\u00e0 aumenta l’efficienza del database: potete archiviare dati correlati in un unico shard, il che significa che l’esecuzione di query comuni richiede meno tempo.<\/p>\n Per esempio, se usate uno sharding basato su directory e raggruppate gli utenti in base alla loro posizione, recuperando gli utenti da un luogo particolare, interrogherete un solo shard.<\/p>\n La maggior parte dei moderni motori di database supporta lo sharding dei database. Uno di questi motori di database \u00e8 MariaDB, un fork di MySQL supportato commercialmente. \u00c8 un sistema di database open-source ad alte prestazioni adottato da aziende come IBM, GitHub e Wikimedia. Fa anche parte dello stack di server ad alte prestazioni di Kinsta.<\/p>\n MariaDB offre funzioni di sharding integrate grazie allo spider storage engine<\/a>. Lo spider storage engine \u00e8 un motore di formazione di cluster che supporta il partizionamento e le transazioni ad architettura estesa (XA). Vi permette di trattare tabelle remote di istanze diverse come se fossero nella stessa istanza. Una volta creata una tabella nello spider storage engine, la tabella si collega a un’altra tabella nel server MariaDB remoto. Una volta stabilita la connessione, il motore di archiviazione condivide il collegamento con tutte le tabelle che fanno parte della stessa transazione.<\/p>\n Lo sharding del database \u00e8 una tecnica di scalabilit\u00e0 che suddivide le tabelle in sottoinsiemi pi\u00f9 piccoli e li distribuisce a diversi server chiamati shard. Lo sharding pu\u00f2 essere implementato in vari modi, come lo sharding basato su chiavi, lo sharding basato su range e lo sharding basato su directory.<\/p>\n Sebbene lo sharding migliori la scalabilit\u00e0, l’affidabilit\u00e0 e la disponibilit\u00e0 di un database, \u00e8 molto complesso da implementare. Inoltre, una volta creato uno shard, non \u00e8 facile riportare il database allo stato non shardato. Per questo motivo, meglio lo sharding per l’ottimizzazione solo quando avete la sicurezza che le altre opzioni di scalabilit\u00e0 non funzionano.<\/p>\n Che la vostra attivit\u00e0 sia una no-profit<\/a> o un’impresa di livello enterprise<\/a>, le soluzioni esperte di Kinsta possono eliminare le preoccupazioni legate all’hosting del sito, e vi permettono di concentrarvi su ci\u00f2 che conta di pi\u00f9.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" La creazione di un sito web \u00e8 il primo passo per costruire la vostra presenza su Internet. Per prosperare a lungo termine, dovete anche assicurarvi che …<\/p>\n","protected":false},"author":117,"featured_media":62011,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[25992],"class_list":["post-61818","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-suggerimenti-tecnici"],"yoast_head":"\n![\"Illustrazione](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/11\/database-sharding-example.png\")
Vantaggi dello Sharding dei Database<\/h2>\n
Miglioramento della Scalabilit\u00e0 Orizzontale<\/h3>\n
Tempi di Risposta alle Query Pi\u00f9 Rapidi<\/h3>\n
Maggiore Affidabilit\u00e0 in Caso di Interruzioni di Servizio<\/h3>\n
Gli Svantaggi dello Sharding<\/h2>\n
Architetture di Sharding<\/h2>\n
\n
Sharding Basato su Chiavi<\/h3>\n
Sharding Basato sull’Intervallo<\/h3>\n
Sharding Basato su Directory<\/h3>\n
Sharding del Database con Kinsta<\/h2>\n
Riepilogo<\/h2>\n