{"id":15719,"date":"2025-12-01T15:07:49","date_gmt":"2025-12-01T14:07:49","guid":{"rendered":"https:\/\/webhosting.de\/datenbank-sharding-replikation-webhosting-infrastruktur-skalierbar\/"},"modified":"2025-12-01T15:07:49","modified_gmt":"2025-12-01T14:07:49","slug":"database-sharding-replica-web-hosting-infrastruttura-scalabile","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/datenbank-sharding-replikation-webhosting-infrastruktur-skalierbar\/","title":{"rendered":"Sharding e replica dei database: quando conviene utilizzarli nel web hosting?"},"content":{"rendered":"<p>Mostro quando <strong>hosting di database sharding<\/strong> quando il web hosting offre una reale scalabilit\u00e0 e quando <strong>Replica<\/strong> Ho gi\u00e0 raggiunto tutti gli obiettivi. Stabilisco soglie concrete per la quantit\u00e0 di dati, il rapporto lettura\/scrittura e la disponibilit\u00e0, in modo da poter decidere con sicurezza l'architettura pi\u00f9 adatta.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>Prima di approfondire l'argomento, riassumo brevemente le decisioni pi\u00f9 importanti.<\/p>\n<ul>\n  <li><strong>Replica<\/strong> Aumenta la disponibilit\u00e0 e le prestazioni di lettura, ma rimane limitato in scrittura.<\/li>\n  <li><strong>Sharding<\/strong> distribuisce i dati orizzontalmente e scala la lettura e la scrittura.<\/li>\n  <li><strong>Ibrido<\/strong> combina frammenti con repliche per ogni frammento per garantire la resilienza.<\/li>\n  <li><strong>Soglie<\/strong>: forte crescita dei dati, elevato parallelismo, limiti di memoria per server.<\/li>\n  <li><strong>Costi<\/strong> dipendono dal funzionamento, dalla progettazione delle query e dall'osservabilit\u00e0.<\/li>\n<\/ul>\n<p>Questi punti mi aiutano a stabilire le priorit\u00e0 e a ridurre il rischio. Comincio con <strong>Replica<\/strong>, non appena la disponibilit\u00e0 diventa importante. In caso di pressione continua su CPU, RAM o I\/O, pianifico <strong>Sharding<\/strong>. In molti scenari, una configurazione ibrida offre il miglior compromesso tra scalabilit\u00e0 e affidabilit\u00e0. In questo modo mantengo l'architettura chiara, gestibile ed efficiente.<\/p>\n\n<h2>Replica nel web hosting: breve e chiara<\/h2>\n<p>Uso <strong>Replica<\/strong>, per conservare copie dello stesso database su pi\u00f9 nodi. Un nodo primario accetta operazioni di scrittura, mentre i nodi secondari forniscono un accesso di lettura veloce. Ci\u00f2 riduce notevolmente le latenze nei report, nei feed e nei cataloghi dei prodotti. Per le manutenzioni programmate, passo in modo mirato a una replica, garantendo cos\u00ec la <strong>Disponibilit\u00e0<\/strong>. Se un nodo smette di funzionare, un altro prende il suo posto in pochi secondi e gli utenti rimangono online.<\/p>\n<p>Distinguo due modalit\u00e0 con conseguenze chiare. Master-Slave aumenta la <strong>prestazioni di lettura<\/strong>, ma limita la capacit\u00e0 di scrittura al nodo primario. Il multi-master distribuisce la scrittura, ma richiede regole di conflitto rigide e timestamp puliti. Senza un buon monitoraggio, rischio di accumulare ritardi nei log di replica. Con impostazioni di commit configurate correttamente, controllo consapevolmente la coerenza rispetto alla latenza.<\/p>\n\n<h2>Sharding spiegato in modo comprensibile<\/h2>\n<p>Condivido su <strong>Sharding<\/strong> i dati orizzontalmente in frammenti, in modo che ogni nodo contenga solo una parte dell'insieme. In questo modo posso scalare contemporaneamente gli accessi in scrittura e in lettura, perch\u00e9 le richieste vengono indirizzate a pi\u00f9 nodi. Un livello di routing indirizza le query al frammento appropriato e riduce il carico per ogni istanza. In questo modo evito i limiti di memoria e I\/O di un singolo <strong>Server<\/strong>. Se la quantit\u00e0 di dati aumenta, aggiungo dei frammenti invece di acquistare macchine sempre pi\u00f9 grandi.<\/p>\n<p>Scelgo la strategia di sharding pi\u00f9 adatta al modello di dati. Lo sharding con hash distribuisce le chiavi in modo uniforme e protegge dagli hotspot. Lo sharding per intervallo facilita le query per intervallo, ma pu\u00f2 causare <strong>squilibrio<\/strong> . Il directory sharding utilizza una tabella di mappatura e offre la massima flessibilit\u00e0 a scapito di una gestione aggiuntiva. Una chiave chiara e buone metriche evitano costosi re-shard in seguito.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/datenbank-sharding-webhosting-9374.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando \u00e8 opportuno ricorrere alla replica<\/h2>\n<p>Ho impostato <strong>Replica<\/strong> Quando prevalgono gli accessi in lettura e i dati devono rimanere altamente disponibili. Blog, portali di notizie e pagine di prodotti ne traggono vantaggio, perch\u00e9 molti utenti leggono e pochi scrivono. Richiedo che i dati di fatturazione o i dati dei pazienti siano conservati in modo ridondante. Per la manutenzione e gli aggiornamenti, mantengo i tempi di inattivit\u00e0 il pi\u00f9 vicini possibile allo zero. Solo quando la coda di scrittura sul master cresce, cerco delle alternative.<\/p>\n<p>Verifico in anticipo alcuni segnali critici. Le latenze di scrittura superano i miei obiettivi di servizio. I ritardi di replica si accumulano nei picchi di carico. I carichi di lettura sovraccaricano le singole repliche nonostante il caching. In questi casi ottimizzo le query e gli indici, ad esempio con <a href=\"https:\/\/webhosting.de\/it\/guida-allottimizzazione-delle-prestazioni-dei-database-per-carichi-elevati\/\">Ottimizzazione del database<\/a>. Se questi passaggi aiutano solo temporaneamente, ho intenzione di passare a Shards.<\/p>\n\n<h2>Quando \u00e8 necessario lo sharding<\/h2>\n<p>Decido di <strong>Sharding<\/strong>, non appena un singolo server non \u00e8 pi\u00f9 in grado di gestire il volume di dati. Ci\u00f2 vale anche quando CPU, RAM o memoria funzionano costantemente al limite delle loro capacit\u00e0. L'elevato parallelismo nella lettura e nella scrittura richiede una distribuzione orizzontale. I carichi di transazioni con molte sessioni simultanee richiedono pi\u00f9 <strong>Istanze<\/strong>. Solo lo sharding elimina davvero i limiti rigidi nella scrittura.<\/p>\n<p>Osservo i fattori scatenanti tipici per settimane. La crescita quotidiana dei dati impone frequenti aggiornamenti verticali. Le finestre di manutenzione diventano troppo brevi per le necessarie reindicizzazioni. I backup richiedono troppo tempo, i tempi di ripristino non soddisfano pi\u00f9 gli obiettivi. Se si verificano due o tre di questi fattori, pianifico l'architettura shard praticamente immediatamente.<\/p>\n\n<h2>Confronto tra strategie di sharding<\/h2>\n<p>Scelgo consapevolmente la chiave, perch\u00e9 \u00e8 lei a determinare <strong>Scala<\/strong> e hotspot. L'hashed sharding offre la migliore distribuzione uniforme per gli ID utente e i numeri d'ordine. Il range sharding \u00e8 adatto per le linee temporali e i report ordinati, ma richiede un ribilanciamento in caso di cambiamenti di tendenza. Il directory sharding risolve casi speciali, ma comporta un ulteriore <strong>Lookup<\/strong>-Livello. In caso di carichi misti, combino hash per una distribuzione uniforme e range all'interno di uno shard per i report.<\/p>\n<p>Pianifico il re-sharding fin dal primo giorno. Un hash coerente con lo sharding virtuale riduce i trasferimenti. Le metriche per ogni shard mostrano tempestivamente eventuali sovraccarichi. I test con chiavi realistiche rivelano i casi limite. In questo modo mantengo calcolabile la ristrutturazione durante il funzionamento.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/sharding_replikation_meeting_4198.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Combinazione: sharding + replica<\/h2>\n<p>Combino <strong>Sharding<\/strong> per il ridimensionamento con replica in ogni frammento per garantire l'affidabilit\u00e0. Se un nodo si guasta, subentra la replica dello stesso frammento. In questo modo, i malfunzionamenti globali interessano solo una parte degli utenti anzich\u00e9 tutti. Distribuisco inoltre i carichi di lettura sulle repliche, aumentando cos\u00ec la <strong>Produttivit\u00e0<\/strong>-Riserve. Questa architettura \u00e8 adatta per negozi, piattaforme di apprendimento e applicazioni sociali.<\/p>\n<p>Definisco SLO chiari per ogni shard. Gli obiettivi di ripristino per ogni classe di dati evitano controversie in caso di emergenza. Il failover automatizzato evita errori umani nei momenti di maggiore frenesia. I backup vengono eseguiti pi\u00f9 rapidamente per ogni shard e consentono ripristini paralleli. Ci\u00f2 riduce i rischi e garantisce tempi di funzionamento prevedibili.<\/p>\n\n<h2>Costi e funzionamento \u2013 realistici<\/h2>\n<p>Credo che <strong>Costi<\/strong> non solo nell'hardware, ma anche nel funzionamento, nel monitoraggio e nell'assistenza telefonica. La replica \u00e8 facile da implementare, ma comporta costi di archiviazione pi\u00f9 elevati a causa delle copie. Lo sharding riduce la memoria per nodo, ma aumenta il numero di nodi e i costi operativi. Una buona osservabilit\u00e0 evita di procedere alla cieca in caso di ritardi nella replica o hotspot di shard. Una tabella riassume le conseguenze.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Criterio<\/th>\n      <th>Replica<\/th>\n      <th>Sharding<\/th>\n      <th>Impatto sul web hosting<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>scrivere<\/strong><\/td>\n      <td>Difficilmente scalabile, master limitato<\/td>\n      <td>Scalabile orizzontalmente tramite shard<\/td>\n      <td>Lo sharding elimina i colli di bottiglia nella scrittura<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Leggi<\/strong><\/td>\n      <td>Scalabilit\u00e0 ottimale tramite repliche<\/td>\n      <td>Ottima scalabilit\u00e0 per shard e replica<\/td>\n      <td>Feed veloci, report, cache<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Memoria<\/strong><\/td>\n      <td>Pi\u00f9 copie = pi\u00f9 costi<\/td>\n      <td>Dati distribuiti, meno per nodo<\/td>\n      <td>L'importo mensile in \u20ac diminuisce per ogni istanza<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Complessit\u00e0<\/strong><\/td>\n      <td>Facile da usare<\/td>\n      <td>Pi\u00f9 nodi, design chiave importante<\/td>\n      <td>Necessaria una maggiore automazione<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Tolleranza ai guasti<\/strong><\/td>\n      <td>Failover rapido<\/td>\n      <td>Errore isolato, interessato un sottoinsieme di utenti<\/td>\n      <td>L'ibrido offre il miglior equilibrio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Imposta i valori soglia in euro per richiesta, non solo per <strong>Server<\/strong>. Se il prezzo per 1000 query diminuisce sensibilmente, la mossa \u00e8 vantaggiosa. Se i nodi aggiuntivi aumentano il carico di on-call, compenso con l'automazione. In questo modo l'architettura rimane economica, non solo tecnicamente pulita. Costi chiari per ogni livello di traffico evitano sorprese successive.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/datenbank-sharding-replikation-7384.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Migrazione agli shard: un percorso graduale<\/h2>\n<p>Entro <strong>Fasi<\/strong> anzich\u00e9 suddividere il database durante la notte. Per prima cosa ripulisco lo schema, gli indici e le query. Successivamente introduco un routing tramite un livello di servizio neutro. Infine, trasferisco i dati in batch nei nuovi shard. Infine, cambio il percorso di scrittura e osservo le latenze.<\/p>\n<p>Evito le insidie con un piano solido. Un buon modello di dati ripaga pi\u00f9 volte in seguito. Uno sguardo a <a href=\"https:\/\/webhosting.de\/it\/database-sql-vs-nosql-confronto-tra-web-hosting-e-scaling\/\">SQL contro NoSQL<\/a>. Alcuni carichi di lavoro traggono vantaggio dall'archiviazione basata su documenti, altri dai vincoli relazionali. Scelgo ci\u00f2 che supporta realmente i modelli di query e il know-how del team.<\/p>\n\n<h2>Monitoraggio, SLO e test<\/h2>\n<p>Definisco <strong>SLO<\/strong> per latenza, tasso di errore e ritardo di replica. I dashboard mostrano sia la vista cluster che quella shard. Gli allarmi scattano in base al trend, non solo in caso di guasto totale. I test di carico in condizioni simili alla produzione convalidano gli obiettivi. Esercizi di chaos rivelano i punti deboli del failover.<\/p>\n<p>Misuro ogni collo di bottiglia in termini numerici. Le velocit\u00e0 di scrittura, i blocchi e le lunghezze delle code indicano tempestivamente i rischi. I piani di query rivelano le carenze. <strong>Indici<\/strong>. Eseguo regolarmente e con tempistiche precise test di backup e ripristino. Senza questa disciplina, la scalabilit\u00e0 rimane solo un desiderio.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/sharding_replikation_techoffice_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Scenari pratici in base al traffico<\/h2>\n<p>Ordino i progetti in base a <strong>Livello<\/strong> Fino a circa alcune migliaia di visitatori al giorno: in molti casi sono sufficienti la replica e il caching. Tra diecimila e centomila: replica con pi\u00f9 nodi di lettura e ottimizzazione delle query, oltre a una prima partizionatura. Oltre questo limite: pianificare lo sharding, identificare i punti caldi di scrittura, creare un livello di routing. A partire da milioni: configurazione ibrida con shard e due repliche per shard, compreso il failover automatico.<\/p>\n<p>Mantengo piccoli i passi della migrazione. Ogni fase riduce il rischio e la pressione temporale. Il budget e le dimensioni del team determinano il ritmo e <strong>Automazione<\/strong>. Le fasi di feature freeze proteggono la ristrutturazione. Traguardi chiari garantiscono progressi affidabili.<\/p>\n\n<h2>Caso speciale: dati temporali<\/h2>\n<p>Tratto <strong>serie temporali<\/strong> separatamente, perch\u00e9 crescono costantemente e sono pesanti in termini di range. La partizionatura in base alle finestre temporali alleggerisce gli indici e i backup. La compressione consente di risparmiare memoria e I\/O. Per metriche, sensori e log \u00e8 utile un motore in grado di gestire serie temporali in modo nativo. Un buon punto di partenza \u00e8 fornito da <a href=\"https:\/\/webhosting.de\/it\/timescaledb-gestione-dei-dati-delle-serie-temporali-webhosting\/\">Dati temporali TimescaleDB<\/a> con gestione automatica dei chunk.<\/p>\n<p>Combino il range sharding per periodo con chiavi hash all'interno della finestra. In questo modo ottengo un equilibrio tra distribuzione uniforme ed efficienza. <strong>Domande<\/strong>. Le politiche di conservazione consentono di eliminare i dati obsoleti in modo pianificabile. Gli aggregati continui accelerano i dashboard. Ci\u00f2 si traduce in costi operativi chiari e tempi di risposta brevi.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/entwickler_sharding_setup_2847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Soglie concrete per la decisione<\/h2>\n<p>Prendo decisioni basandomi su criteri misurabili anzich\u00e9 sul mio istinto. Le seguenti regole empiriche si sono dimostrate efficaci:<\/p>\n<ul>\n  <li><strong>Volume dei dati<\/strong>: A partire da ~1\u20132 TB di dati caldi o &gt;5 TB di inventario totale, prendo in considerazione lo sharding. Se la crescita \u00e8 &gt;10% al mese, pianifico prima.<\/li>\n  <li><strong>scrivere<\/strong>: &gt;2\u20135k operazioni di scrittura\/s con requisiti transazionali sovraccaricano rapidamente un master. A partire da 70% CPU per ore, nonostante la messa a punto, \u00e8 necessario ricorrere allo sharding.<\/li>\n  <li><strong>Leggi<\/strong>: &gt;50\u2013100k query di lettura\/s giustificano repliche aggiuntive. Se il tasso di cache hit rimane &lt;90% nonostante le ottimizzazioni, scalare orizzontalmente.<\/li>\n  <li><strong>Archiviazione\/I\/O<\/strong>: IOPS &gt;80% o storage lento occupato &gt;75% generano picchi di latenza. Gli shard riducono il carico I\/O per nodo.<\/li>\n  <li><strong>Ritardo di replica<\/strong>: &gt;1\u20132 s p95 in caso di picchi di carico a rischio di read-after-write. Quindi instauro le sessioni sul writer o eseguo il ridimensionamento tramite shard.<\/li>\n  <li><strong>RTO\/RPO<\/strong>: Se i backup\/ripristini non sono in grado di rispettare gli SLO (ad es. ripristino &gt;2 ore), suddivido i dati in frammenti per il ripristino parallelo.<\/li>\n<\/ul>\n<p>Questi numeri sono punti di partenza. Li calibro in base al mio carico di lavoro, ai profili hardware e ai miei SLO.<\/p>\n\n<h2>Controllare consapevolmente la consistenza<\/h2>\n<p>Prendo una decisione consapevole tra <strong>asincrono<\/strong> e <strong>sincrono<\/strong>Replica. L'asincronia riduce al minimo la latenza di scrittura, ma comporta il rischio di un ritardo di alcuni secondi. La sincronia garantisce zero perdite di dati in caso di failover, ma aumenta i tempi di commit. Impostiamo i parametri di commit in modo tale da rispettare i budget di latenza e mantenere il ritardo osservabile.<\/p>\n<p>Per <strong>Leggi dopo aver scritto<\/strong> Inoltro la sessione sticky allo scrittore o utilizzo \u201efenced reads\u201c (lettura solo se la replica conferma lo stato del log corrispondente). Per <strong>letture monotone<\/strong> Mi assicuro che le richieste successive leggano \u2265 l'ultima versione vista. In questo modo mantengo stabili le aspettative degli utenti senza essere sempre rigorosamente sincronizzato.<\/p>\n\n<h2>Chiave frammentata, vincoli globali e progettazione delle query<\/h2>\n<p>Scelgo il <strong>Chiave frammentata<\/strong> in modo che la maggior parte delle query rimanga locale. Ci\u00f2 evita costose query fan-out. Globale <strong>unicit\u00e0<\/strong> (ad es. e-mail univoca) risolvo con una tabella di directory dedicata e leggera o tramite normalizzazione deterministica che mappa sullo stesso shard. Per i report accetto spesso la consistenza eventuale e preferisco le viste materializzate o i lavori di aggregazione.<\/p>\n<p>Evito gli anti-pattern sin dall'inizio: fissare una grande tabella \u201eclienti\u201c su uno shard crea hotspot. Distribuisco i grandi clienti su <em>frammenti virtuali<\/em> oppure segmenta per sottodomini. Gli indici secondari che effettuano ricerche trasversali sui frammenti vengono tradotti in servizi di ricerca o scritti in modo selettivo come duplicati in un archivio di reporting.<\/p>\n\n<h2>ID, ora e hotspot<\/h2>\n<p>Io produco <strong>ID<\/strong>, che evitano collisioni e bilanciano gli shard. Le chiavi monotone e puramente crescenti portano a hot partitioning nel range sharding. Utilizzo quindi ID \u201etemporali\u201c con randomizzazione integrata (ad es. k-sorted) oppure separo l'ordine temporale dalla distribuzione degli shard. In questo modo gli insert rimangono ampiamente distribuiti senza che le serie temporali diventino inutilizzabili.<\/p>\n<p>Per mantenere l'ordine nei feed, combino l'ordinamento lato server con l'impaginazione del cursore, invece di distribuire offset\/limite tramite shard. Ci\u00f2 riduce il carico e mantiene stabili le latenze.<\/p>\n\n<h2>Transazioni cross-shard nella pratica<\/h2>\n<p>Decido presto come <strong>Cross-Shard<\/strong>-Gestisco i percorsi di scrittura. Il commit in due fasi garantisce un'elevata coerenza, ma comporta latenza e complessit\u00e0. In molti carichi di lavoro web mi affido a <strong>Saghe<\/strong>: Suddivido la transazione in passaggi con compensazioni. Per gli eventi e i percorsi di replica, un modello di casella di posta in uscita mi aiuta a evitare che i messaggi vadano persi. Operazioni idempotenti e transizioni di stato ben definite impediscono la doppia elaborazione.<\/p>\n<p>Ritengo che i casi cross-shard siano rari, poich\u00e9 suddivido il modello di dati in modo locale per ogni shard (contesti limitati). Laddove ci\u00f2 non \u00e8 possibile, creo un piccolo livello di coordinamento che gestisce in modo pulito timeout, tentativi di riesecuzione e dead letter.<\/p>\n\n<h2>Backup, ripristino e ribilanciamento nel cluster shard<\/h2>\n<p>I sicuro <strong>per frammento<\/strong> e coordino gli scatti con un indicatore globale per documentare uno stato coerente. Per <strong>Recupero point-in-time<\/strong> Sincronizzo gli orari di avvio in modo da poter riportare l'intero sistema allo stesso momento. Limito l'IO di backup tramite throttling, in modo da non compromettere il funzionamento dell'utente.<\/p>\n<p>All'indirizzo <strong>Ribilanciamento<\/strong> Sposto frammenti virtuali invece di intere partizioni fisiche. Prima eseguo una copia in sola lettura, poi passo a una breve sincronizzazione delta e infine effettuo la conversione. Ogni fase \u00e8 accompagnata da allarmi per il ritardo e l'aumento dei tassi di errore. In questo modo la conversione rimane prevedibile.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/server-sharding-hosting-7184.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Operativit\u00e0: aggiornamenti, schemi e implementazione di funzionalit\u00e0<\/h2>\n<p>Sto progettando <strong>aggiornamenti continui<\/strong> shardweise, affinch\u00e9 la piattaforma rimanga online. Le modifiche allo schema vengono eseguite secondo il modello Expand\/Contract: prima campi additivi e percorsi di scrittura duali, poi backfill e infine smantellamento della vecchia struttura. Monitoro i budget di errore e posso eseguire rapidamente il rollback tramite feature flag se le metriche cambiano.<\/p>\n<p>Per i valori predefiniti e i lavori di migrazione di grandi dimensioni, lavoro in modo asincrono in background. Ogni modifica \u00e8 misurabile: durata, velocit\u00e0, errori, impatto sugli hotpath. In questo modo non ho sorprese in termini di effetti collaterali nei momenti di picco.<\/p>\n\n<h2>Sicurezza, localizzazione dei dati e separazione dei clienti<\/h2>\n<p>I nota <strong>Localit\u00e0 dei dati<\/strong> e conformit\u00e0 sin dall'inizio. Gli shard possono essere separati per regione per soddisfare i requisiti legali. Criptiamo i dati inattivi e in transito e manteniamo rigorosi <em>privilegio minimo<\/em>-Politiche per gli account di servizio. Per <strong>Clienti<\/strong> Imposta gli ID tenant come prima parte della chiave. Gli audit e i log a prova di revisione vengono eseguiti per ogni shard, in modo da poter fornire risposte rapide in caso di emergenza.<\/p>\n\n<h2>Caching con replica e shard<\/h2>\n<p>Utilizzo le cache in modo mirato. Le chiavi contengono il <strong>Contesto dello shard<\/strong>, in modo da evitare collisioni. Con l'hashing coerente, il cluster della cache si adatta di conseguenza. Utilizzo Write-Through o Write-Behind a seconda dei budget di latenza; per i percorsi critici in termini di invalidazione, preferisco <strong>Write-Through<\/strong> pi\u00f9 TTL brevi. Contro <em>Cache stampede<\/em> aiutano a ridurre il jitter con TTL e <em>richiesta di coalescenza<\/em>.<\/p>\n<p>In caso di ritardo nella replica, do la priorit\u00e0 alle letture dalla cache rispetto alle letture da repliche leggermente obsolete, se il prodotto lo consente. Per <strong>Leggi dopo aver scritto<\/strong> contrassegno temporaneamente le chiavi interessate come \u201enuove\u201c o ignoro la cache in modo mirato.<\/p>\n\n<h2>Pianificazione della capacit\u00e0 e controllo dei costi<\/h2>\n<p>Prevedo la crescita dei dati e il QPS su base trimestrale. Pianifico un utilizzo superiore a 60-70% come \u201epieno\u201c e mantengo un buffer di 20-30% per i picchi e il ribilanciamento. Io <strong>rightsizing<\/strong>e Istanze regolari e misuro \u20ac per 1000 query e \u20ac per GB\/mese per ogni shard. Se la replica comporta costi di archiviazione aggiuntivi, ma viene utilizzata solo raramente, riduco il numero di nodi di lettura e investo nell'ottimizzazione delle query. Se lo sharding genera un carico di lavoro eccessivo, automatizzo in modo coerente il failover, i backup e il ribilanciamento.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/datenbank-sharding-webhosting-9374.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riassumendo brevemente<\/h2>\n<p>Uso <strong>Replica<\/strong> In primo luogo, quando contano le prestazioni di lettura e la disponibilit\u00e0. Se i volumi di dati e il carico di scrittura aumentano costantemente, lo sharding \u00e8 inevitabile. Un approccio ibrido offre il miglior mix di scalabilit\u00e0 e affidabilit\u00e0. Metriche chiare, schemi puliti e test rendono la decisione sicura. In questo modo utilizzo lo sharding del database in modo mirato e mantengo la piattaforma affidabile.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leggi quando \u00e8 opportuno ricorrere al database sharding hosting e alla replica db. Guida completa al ridimensionamento dei database per le moderne infrastrutture di hosting.<\/p>","protected":false},"author":1,"featured_media":15712,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-15719","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"2081","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"database sharding hosting","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"15712","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/15719","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=15719"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/15719\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/15712"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=15719"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=15719"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=15719"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}