Si può sempre progettare per scalare?

TLDR: il ridimensionamento non è possibile per gli algoritmi sequenziali o i dati atomici e può essere un cattivo modo per spendere un budget di sviluppo.

Come altri hanno sottolineato, gli algoritmi sequenziali non possono essere ridimensionati. Un esempio potrebbe essere l'elaborazione di transazioni finanziarie, in cui le transazioni devono essere applicate nell'ordine corretto. Tuttavia, nel tipico scenario CRUD è improbabile che tu possa imbatterti in algoritmi sequenziali di lunga durata, quindi la mia risposta sarà indirizzata a casi in cui non hai a che fare con un tale algoritmo sequenziale.

La chiave per ridimensionare è evitare il lavoro di sincronizzazione tra i server, perché è il lavoro di sincronizzazione che introduce i colli di bottiglia man mano che si ridimensionano. Ad esempio, i server delle applicazioni possono evitare di archiviare i dati localmente, recuperando tutto ciò che è fresco dal livello del database per ogni richiesta. In questo modo, nessun dato deve essere sincronizzato tra i server delle applicazioni (ad esempio i dati della sessione). Un altro esempio è la condivisione dei database, in cui diversi server di database contengono parti diverse dei dati, il che significa che non è necessario alcun lavoro di sincronizzazione tra questi server.

Quindi, la risposta è che anche nei casi in cui non vi sono colli di bottiglia algoritmici per ridimensionare ci sono situazioni in cui la riduzione non è possibile, e questi hanno a che fare con l'atomicità dei dati. Se hai a che fare con un insieme di dati che non possono essere condivisi e devono essere condivisi tra i nodi per implementare la tua logica (es. Un grafico sociale non divisibile), allora l'unica opzione è scalare: un grande server che contiene invece l'intero set di dati di un gruppo di piccoli che hanno ciascuno un sottosegmento. Queste situazioni sono comunque piuttosto rare, quindi nella maggior parte dei casi il software può essere progettato per essere ridimensionato, a condizione che il progetto tenga conto di ciò sin dall'inizio.

Un'altra cosa da tenere in considerazione è il costo del design. La progettazione per il ridimensionamento aumenta il costo di sviluppo. Ad esempio, lo sharding del database richiede una logica a livello di applicazione aggiuntiva per gestire i frammenti. Per questo motivo, ha senso scegliere consapevolmente di scalare, in particolare a livello di DB. Per un esempio, guarda il sito che stai guardando in questo momento.

No, la cronologia del calcolo sta facendo cose che erano [erano] "impossibili".

A parte le guance, ad un livello più pratico - sembra che tu stia essenzialmente chiedendo al tuo pubblico di dimostrare un aspetto negativo. Quindi, di nuovo, la risposta è abbastanza facilmente "no".

No, non è sempre possibile "scalare". Poiché la la legge di Amdahl ci mostra, le tue capacità di parallelizzare le attività sono limitate da sezioni dell'algoritmo che deve essere fatto in sequenza.

Penso che ci siano poche applicazioni CRUD in cui non è possibile ottenere benefici significativi dal ridimensionamento. Tuttavia, ci sono situazioni in cui si hanno requisiti di elaborazione sequenziale significativi, come molte applicazioni scientifiche, in cui si è fondamentalmente richiesto di calcolare una cosa prima di un'altra. Questa domanda di scambio di CS CS mostra alcuni esempi.

Ecco un esempio di un design che non scala. La ragione è spiegata dalle altre risposte, deve essere fatta in sequenza:

Un orderbook di scambio per un particolare prodotto come un contratto futures. Gli utenti contano per essere riempiti su una regola del prezzo, quindi il server deve elaborare ogni voce in sequenza.

No, qualsiasi progetto sopravviverà solo a scalare il più lontano possibile nella fase di progettazione. Alla fine il sistema colpirà un muro o un'inefficienza in cui non può essere ridimensionato, o ridimensionando ulteriormente diminuisce l'efficienza senza una nuova architettura.