7
Apparentemente il motivo dell'architettura BigTable ha a che fare con la difficoltà di ridimensionare i database relazionali quando si ha a che fare con l'enorme numero di server con cui Google deve gestire.Quale aspetto dei database relazionali rende difficile per loro scalare a sufficienza su servizi come Google App Engine?
Ma tecnicamente parlando cosa rende difficile la scalabilità dei database relazionali?
Nei data center aziendali di grandi aziende sembrano essere in grado di farlo con successo, quindi mi chiedo perché non è possibile farlo semplicemente a un ordine di grandezza maggiore per farlo scalare sui server di Google.
Concordo sul fatto che la maggior parte delle app web implicano più letture rispetto all'input dell'utente o all'aggiornamento delle app dei dati. Ma non capisco cosa intendi quando dici che le scritture sono "più facili (in termini di lavoro svolto)" in un RDBMS normalizzato? Vorrei che il datastore di App Engine è più facile in termini di lavoro fatto da una chiave univoca identifica ogni entità e un aggiornamento è equivalente a un inserto a causa del carattere simile ai dizionari del datastore. Mettendo e recuperando da un dizionario è tanto facile quanto arriva fino al lavoro svolto, penserei. – pacman
@pacman: Stai dimenticando tutto il lavoro effettivamente svolto. L'Indice è il grande re del Datastore. Quando si aggiunge un'entità al datastore, si fa un enorme mole di lavoro replicare i dati in modo che se si vuole ottenere una proprietà che si può fare così in fretta. Scrive essenzialmente gli indici per ogni proprietà, in ogni entità, due volte (asc e desc), per tutti i dati memorizzati (forse non le nuove grandi Blobs, non è sicuro). Questo è ciò che richiede così tanto tempo per le scritture, ma consente anche letture veloci su una scala da capogiro. Suggerirei di ottenere un buon libro di AppEngine, in quanto è importante quando si progetta per GAE. –