quali sono le cose da prendere in considerazione quando si progetta un database che probabilmente verrà distribuito dopo qualche tempo? [chiuso]

Devi determinare il motivo per cui il db viene distribuito.

Replica: una società può avere filiali ciascuna con il proprio server di database che replica i propri dati nell'ufficio aziendale che dispone di un proprio server. Marche diverse lo gestiscono in modo diverso e probabilmente raccomandano guids o il server principale usa chiavi composte come: RegionID & UID.

Tolleranza ai guasti Cosa fare quando il server del database si arresta in modo anomalo? Quanto tempo puoi permetterti di stare giù? Ne avrai bisogno di un altro per cambiare se vuoi abbreviare questa volta. Potrebbe trovarsi in un datacenter diverso. Non penso che tu abbia progettato il database in modo così diverso. Ci sono solo altri software e modi per fare il cambio e riavviare la scatola di produzione.

Immagino che tu sia preoccupato di superare una singola macchina per motivi di prestazioni. Ci sono molti passaggi che puoi compiere prima di arrivarci.

1. Progetta la tua app per facilitare la modifica del database.
2. Progetta il database correttamente. Potresti non avere il lusso di normalizzazione. Gli indici di lancio del problema hanno bisogno di alcuni pensieri come bene.
3. Interrogare i dati in modo efficiente. Conosci il tuo database di marca. Utilizzare gli strumenti disponibili (analizzatori di query). Confronta e confronta diversi metodi.
4. Cerca strumenti per memorizzare nella cache i dati. Non riesco a ricordare cosa usano, ma credo che i siti SO facciano questo, così come basecamp.com. Siti abbastanza grandi che, per quanto ne so, sono riusciti a utilizzare RDBMS, forniscono molte informazioni con una grande scatola.
5. Compra un server più grande o aumenta la potenza di uno esistente. Se i soldi ci sono, questa potrebbe essere la tua prima scelta, ma non lasciare che sia una stampella.

Sulla base delle affermazioni di server come NUODB.COM , puoi semplicemente creare la tua app usando il buon vecchio SQL e continuare a lanciare server vari punti di errore (transazioni, scrittura su disco, ecc.) al volo senza apportare modifiche all'app.

Se a un certo punto hai bisogno di più potenza del database, spero che questo sia il risultato di generare più entrate. Con questo, puoi assumere almeno un DBA part time con competenze nella sintonizzazione del database.

UUID o GUID sono utilizzati per essere identificatori univoci globali. come discusso nella documentazione di Postgres . non ci sono metodi che siano del tutto appropriati per generarlo. Tuttavia, i postgres hanno alcuni generatori utili.

L'effetto delle prestazioni sul software dipende dalla dimensione complessiva del database e dalla dimensione media della query. A mio parere, l'uso dell'ID di incremento automatico Guid è trascurabile.

Ti auguro il meglio con la tua start-up e, per avere una solida società di soluzioni software, devi prestare attenzione all'architettura software e al modello di progettazione per rendere il software altamente scalabile e facile da gestire.

Buona fortuna.

Se la tua preoccupazione è archiviazione , il che significa che hai paura che una singola macchina (di database) non sia in grado di conservare tutti i tuoi dati, è meglio progettare in un modo che ti consenta di scalare di sharding tuoi dati.

Sharding significa che ogni macchina di database manterrà solo parte dei tuoi dati, ogni parte atomica è chiamata 'shard', con nodi di database contenenti uno o più shard, ogni frammento ha una o più repliche .

L'idea alla base del sharding è che, dato che sai su quale frammento sono i dati rilevanti, puoi interrogare solo un server che potrebbe avere i dati. La scrittura dei dati viene eseguita anche solo nei nodi rilevanti, il che riduce al minimo i blocchi del database. Alcuni database NoSQL supportano questa funzionalità (come ricerca elastica ).

Non tutti i dati possono essere messi a punto, poiché si interrompono se si desidera interrogare il set di dati intero o se non si riesce a capire in modo affidabile e idempotativo su quale frammento dovrebbero essere i dati, ma se i tuoi dati sono isolati (ad esempio - hai molti utenti, ma ogni utente è interessato solo ai suoi dati) - potrebbe essere fatto abbastanza facilmente.