Qual è il miglior paradigma di accesso ai dati per la scalabilità?

Question

Esistono così tante opzioni diverse provenienti da Microsoft per l'accesso ai dati.Qual è la migliore per le app scalabili?

Linq

Dovremmo usare Linq?Sembra certamente facile, ma se conosci il tuo SQL è davvero d'aiuto.Inoltre ho sentito che non è possibile eseguire query asincrone in ASP.NET utilizzando Linq.Quindi mi chiedo se è davvero scalabile?Esistono siti veramente grandi che utilizzano Linq (con la possibile eccezione di StackOverflow).

Struttura delle entità

Non sento così tanto clamore sull'Entity Framework.Sembra più vicino al modello a oggetti con cui ho familiarità.

Astoria/Dati dinamici

Dovremmo esporre i nostri dati come servizio?

Sono piuttosto confuso e questo prima di dedicarmi agli altri prodotti ORM come NHibernate.Qualche idea o saggezza su quale sia meglio?

Answer 1

Consiglierei NHibernate o Entity Framework.Per i siti di grandi dimensioni, utilizzerei ADO.NET Data Services.Non farei nulla di grande con LINQ to SQL.Penso che Stack Overflow potrebbe finire con alcuni problemi di scala interessanti essendo a 2 livelli anziché a 3 livelli, e avranno anche qualche problema con il refactoring poiché gli aspetti fisici del database cambiano e tali modifiche si propagano in tutto il codice.Solo un pensiero.

Answer 2

Penso che ADO.Net Data Services (precedentemente chiamato Astoria) abbia un ruolo enorme da svolgere.Si adatta perfettamente all'architettura in stile REST del web.

Dato che il web è scalabile, immagino che anche tutto ciò che segue la sua architettura sia scalabile.Inoltre, potresti voler tenere d'occhio SQL Server Data Services.

Answer 3

Se parli di database relazionali, il mio voto è a favore dell'incapsulamento di tutte le operazioni sui dati in procedure memorizzate, indipendentemente da come accedi ad esse dagli altri livelli.

Se disabiliti tutti gli accessi in lettura/scrittura al database, tranne tramite procedure memorizzate, puoi nascondere il tuo modello di dati dietro contratti ben definiti.Il modello di dati è libero di cambiare, proprio così le procedure memorizzate continuano a rispettare i loro input e output.

Ciò offre ai DBA la totale libertà di ottimizzare la propria applicazione e renderla scalabile.Questo è un compito molto, molto difficile quando SQL viene generato da uno strumento esterno al database.

Answer 4

Bloccarsi nelle procedure memorizzate sembra essere un modo di pensare in declino al giorno d'oggi, almeno queste sono state le mie osservazioni attuali.Questo modo di pensare si presta al mondo ORM poiché in genere sono più affettivi andando direttamente contro i tavoli, ma qualsiasi ORM degno di questo nome consentirà anche l'uso di proc - a volte non hai scelta.

Ci sono molte opinioni su EF e indipendentemente da ciò che qualcuno dice, buono o cattivo, è un prodotto V1 e con la regola pratica che MS impiega circa 3 giri per farlo bene, potrebbe essere prudente aspettare il prossimo giro a meno.

Sembra che il più grande attore in questo campo sia NHibernate e c'è molto supporto per questo nella comunità.Linq, la funzionalità del linguaggio, non dovrebbe essere troppo lontana nel raggiungere lo stack NHibernate.

Answer 5

Usa quello che funziona per te.Questi sono tutti più facili da configurare se si dispone già di un database abbastanza normalizzato (ad esempio, una buona definizione di chiavi primarie e chiavi esterne).Tuttavia, se disponi di dati che non si normalizzano facilmente, Entity Framework è più flessibile di LINQ to SQL, ma richiede più lavoro per la configurazione.

Answer 6

Abbiamo sperimentato LINQ in un ambiente cluster e sembra che si adatti bene alle singole macchine e all'interno del cluster.Delle 3 opzioni che hai fornito, direi che LINQ è la scelta migliore, sebbene ciascuna opzione abbia un pubblico di destinazione leggermente diverso, quindi dovresti definire cosa farai con i dati prima di decidere il paradigma di accesso.

Answer 7

Suggerirei linq.Si adatta bene al nostro sito ed è abbastanza semplice da usare.

Answer 8

usa le procedure memorizzate con LINQ... ma non lasciare che gli sproc si trasformino in un livello di accesso ai dati!

Answer 9

Questo post è del 2008, prima che il cloud decollasse davvero.Sembra che sia necessario un aggiornamento della risposta.Mi limiterò a fornire alcuni link e una panoramica.Sono sicuro che ci sono post più aggiornati su questo argomento in questo sito e, se li trovo, aggiungerò i collegamenti qui.

Quando si parla di scalabilità dei dati e di scalabilità dell’elaborazione delle transazioni, nel 2017 dobbiamo parlare di Cloud e di Cloud Service Provider.

Penso che i tre principali fornitori di servizi cloud al giorno d'oggi siano:

• Servizi Web di Amazon (AWS)
• La piattaforma cloud di Google (GCP)
• Microsoft Azure

Costo

Uno degli aspetti positivi dell'utilizzo dei servizi cloud è che non sono previsti costi iniziali, né spese di terminazione e si paga solo per ciò che si utilizza.(Citando l'articolo del signor Alba del 2016 "Un confronto affiancato tra AWS, Google Cloud e Azure")

Usiamo AWS noi stessi.Paghiamo solo finché le nostre VM sono installate e funzionanti, quindi può essere un modo economico per avviare.In genere, i fornitori di servizi addebitano tariffe al minuto o all'ora, ma hai la garanzia di averlo per l'intero periodo.

Un modo più economico per procedere è il prezzo spot best-effort.Il prezzo Spot rappresenta il prezzo al di sopra del quale devi fare un'offerta per garantire che una singola richiesta Spot venga soddisfatta.Quando il prezzo della tua offerta è superiore al prezzo Spot, Amazon EC2 avvia la tua istanza Spot e quando il prezzo Spot supera il prezzo della tua offerta, Amazon EC2 termina la tua istanza Spot.(Citando spudoratamente la Guida per l'utente di Amazon Qui)

Un confronto affiancato tra AWS, Google Cloud e Azure è un buon articolo che fa un confronto fianco a fianco di questi tre fornitori di servizi disponibili Qui.

Per uno sguardo più accademico ai servizi cloud, leggi l'articolo del 2010 di Yu, Wang, Ren e Lou "Ottenere un controllo dell'accesso ai dati sicuro, scalabile e granulare nel cloud computing" negli Atti INFOCOM 2010 disponibili Qui, ma potrebbe essere necessario essere un membro IEEE per accedervi.Anche se è un po' datato, è eccellente e puoi usarlo come punto di partenza.

La scalabilità nel cloud è esplosa e fino a poco tempo fa tale scalabilità veniva effettuata avviando nuove macchine virtuali che richiedevano pochi secondi, ma con i contenitori è possibile avviare nuove istanze in millisecondi.Per ulteriori informazioni al riguardo, consulta Docker e Docker Containers Qui.

Mi scuso per il fatto che questa risposta sia solo un mucchio di collegamenti per ulteriori informazioni, ma ho pensato che la risposta a questa domanda dovesse avere un aggiornamento.Spero che questo ispiri qualcuno a fornire maggiori dettagli di prima mano.Se hai già pubblicato alcune informazioni correlate, valuta la possibilità di fornire collegamenti ai tuoi post.Grazie!