Come scalabile è LINQ?[chiuso]

https://stackoverflow.com/questions/214233

03-07-2019
|

Domanda

Recenti conversazioni con i colleghi che hanno prodotto diversi punti di vista su questo argomento.Cosa ne dite, in MODO che i membri?

Lo so, anche il concetto di scalabilità può essere preso in tanti modi diversi e contesti, ma che era parte della discussione, quando questo è venuto.Tutti sembravano avere un punto di vista differente che cosa scalabilità significa veramente.Sono curioso di vedere la variabile assume qui.Infatti, ho postato un domanda proprio per questo concetto.

Soluzione

Immagino che il modo migliore per verificare sia scrivere benchmark, ma a mio avviso LINQ ha la possibilità di ottimizzazioni che la scrittura manuale di codice simile non ha. Non so ancora come trarne vantaggio.

LINQ ti consente di esprimere ciò che desideri, non come generarlo. Un evidente vantaggio è che LINQ è automaticamente parallelizzabile (vedi PLINQ ).

Un altro vantaggio di LINQ è che è pigro, quindi puoi eseguire calcoli, attingendo dalla raccolta secondo necessità. È possibile codificare a mano un equivalente, ma potrebbe essere molto più facile ottenere direttamente in LINQ.

Altri suggerimenti

Nei test che abbiamo fatto, LINQ to objects (ForEach) è stato circa 2 volte più lento del ciclo foreach.

LINQ to SQL (database MS SQL) è quasi 10x più lento della query diretta utilizzando il lettore di dati, utilizzando la maggior parte delle volte la creazione di SQL dall'albero delle espressioni (quindi, si sarà associati alla CPU e al database sarà al minimo) Per evitare ciò, è necessario utilizzare query compilate.

Vedi questo per di più. La maggior parte delle informazioni nel post è ancora valida con .NET 3.5 SP1.

Questa domanda è un po 'come chiedere " Quanto sono scalabili le raccolte? "

Parliamo di LINQ agli oggetti. In generale, nella misura in cui la maggior parte delle implementazioni di IEnumerable<T> scorre su ogni elemento della raccolta sottostante, LINQ ha un grande potenziale di ridimensionamento mediocre. Crea un List<Foo> che contenga dieci milioni di elementi e qualcosa del genere:

var list = from Foo f in fooList
           where f.Value = "Bar"
           select f;

sarà lento. Ma non è davvero colpa di LINQ. Sei tu quello che gli ha dato un elenco di dieci milioni di articoli.

Lo gestisci nello stesso modo in cui lo gestiresti se LINQ non esistesse: creando dizionari, liste ordinate e simili che ti aiutano a ridurre lo spazio di ricerca.

LINQ può migliorare la scalabilità (beh, rendere più facile raggiungere la scalabilità) tramite l'esecuzione differita della query. Puoi sostituire un metodo ingenuo che crea un elenco, lo filtra in un nuovo elenco, lo filtra in un nuovo elenco, ecc. Con una serie di query LINQ:

var list1 = from Foo f in fooList where f.Value1 = "Bar" select f;
var list2 = from Foo f in list1 where f.Value2 = "Baz" select f;
var list3 = from Foo f in list2 where f.Value3 = "Bat" select f;

tutti i quali vengono eseguiti su un singolo passaggio della raccolta sottostante quando (e se) diventa necessario scorrere l'elenco finale. Ancora una volta, tuttavia, questa non è una novità: se non avessi LINQ, probabilmente finiresti per sostituire il tuo metodo ingenuo con uno che ha fatto la stessa cosa. Ma LINQ lo rende molto più semplice.

A mio avviso LINQ intende semplificare le cose dal punto di vista dello sviluppo, non affrontare la scalabilità.

In realtà, l'uso di LINQ rende le cose così facili nascondendo molte complicazioni sotto le copertine e potrebbe portare, se usato irresponsabilmente , a problemi di scalabilità.

Gli esempi abbondano in altre risposte, ma per citare il più significativo:

Se si esegue una query su una raccolta di oggetti non è possibile ignorarne le dimensioni. Forse farlo nel modello, con LINQ, suonava bene quando c'erano pochi oggetti da interrogare ... ma con l'aumentare delle dimensioni diventa evidente che la query dovrebbe avvenire nel database, non nel modello.
Se si sta generando automaticamente SQL con LINQ, per quanto ne so, non è possibile fornire suggerimenti al database su come compilare le query, ad esempio WITH (NOLOCK). Man mano che le dimensioni della tabella aumentano, è indispensabile affrontare questi problemi.
Simile al precedente, ma forse più generale: quando si affrontano problemi di scalabilità su un DB, è necessario controllare ciò che il DB sta facendo. Avere un linguaggio che si compila in SQL, che viene quindi nuovamente compilato in un piano di esecuzione, rimuove il controllo dalle tue mani.
Cosa succede se devi modificare lo schema del database per renderlo più scalabile e il tuo codice è fortemente legato ad esso perché non hai procedure memorizzate?
Sebbene sembri semplice, non è possibile modificare il provider LINQ senza troppi problemi: interrogare SQL Server non è lo stesso di interrogare oggetto o interrogare XML. Il LINQ è comunque molto simile. Mi aspetto che alcuni dei miei sviluppatori junior vadano su un & Quot; LINQ spree & Quot; perché è più facile che imparare a fare le cose pensando alla scalabilità.

In conclusione, penso che sia possibile scrivere codice scalabile con LINQ, ma solo usandolo con buona cura. Non ci sono strumenti killer, solo codice .

Molto dipende dal provider LINQ si utilizza e come si utilizza.LINQ probabilmente non è sapere con incredibile velocità di esecuzione, ma piuttosto fornisce agli sviluppatori sostanzialmente migliore produttività.

Secondo questo collegamento anche con alcuni dei Ctp Linq to SQL è già meglio di utilizzo di SQL diretto in alcuni casi.

Se siete preoccupati per la Velocità e utilizzo di LINQ to objects un sacco qui è un progetto codeplex (credo) per un provider che si può dare a 1000x miglioramenti delle prestazioni.

La tua domanda sulla scalabilità dipende in qualche modo da cosa stai usando LINQ. Nelle applicazioni aziendali, non troverai molti comandi SQL in esecuzione: sono lenti e devono essere compilati nel DBMS. Quello che vedrai invece sono molte chiamate di procedure memorizzate. Questi saranno leggermente più veloci in LINQ.

Tieni presente che LINQ to SQL e simili sono basati su TOP di ADO.NET - non sono una metodologia completamente diversa o altro. Certo, LINQ to XML utilizzerà diverse API sotto le copertine. Sarà molto simile a un compilatore: ci sono sempre alcune ottimizzazioni che gli umani possono fare che potrebbero essere più veloci, ma per la maggior parte, queste API saranno in grado di generare un codice più veloce e meno buggy rispetto al codice che scrivi tu stesso.

In termini di ridimensionamento, puoi sempre mettere LINQ dietro un servizio web se vuoi distribuire un po 'i tuoi dati o puoi usare la replica del server SQL. Non dovrebbe essere meno scalabile di quanto sarebbe ADO.NET.

Scalabilità e prestazioni sono due cose diverse ma correlate. Se si desidera misurare le prestazioni, è necessario vedere quanti utenti (ad esempio) è possibile supportare con una casella. Quando misuri la scalabilità aggiungi un'altra casella e vedi se riesci a supportare il doppio dell'importo originale? Probabilmente, e potresti aggiungere solo il 75% alla tua potenza di elaborazione, il prossimo aggiunge solo il 50% dell'unità originale, e quindi scende a zero abbastanza velocemente. Indipendentemente dal numero di caselle che aggiungi a tale velocità, sei fortunato a raddoppiare il conteggio degli utenti supportati. Questa è scalabilità.

Il ridimensionamento del modulo Linq dipende probabilmente dal database, dalla potenza della macchina, dalla progettazione del database, dalla progettazione dell'applicazione.

Spesso vedi micro-benchmark che dovrebbero rivelare qualcosa di conclusivo, ma non lo fanno mai perché sono solo una chiave di volta per l'intero problema.

Puoi estrarre il buon vecchio esempio 20/80 qui. Probabilmente è il 20% sullo strumento e l'80% su tutti i tipi di tangibili che compongono la tua applicazione.

Se stai cercando un esempio di vita reale, StackOverflow utilizza Linq pesantemente, controlla questo

Esiste un prezzo per la memorizzazione nella cache e il caricamento di oggetti su richiesta utilizzando il framework Linq to SQL. Se un oggetto può caricare pigro parti di se stesso su richiesta, è molto probabile che ci sia un riferimento al contesto dei dati all'interno di ciascun oggetto. Per inciso, quel contesto di dati memorizza anche nella cache ogni oggetto mai richiesto da esso. Ciò significa che se tieni uno dei tuoi oggetti in giro (o in una cache o solo perché lo usi in un secondo momento), non stai solo trattenendo quell'oggetto, ma ogni oggetto mai richiesto dal contesto dei dati. Non verranno mai raccolti rifiuti perché vengono ancora citati.

Questo non è un problema se tutti i tuoi obiettivi hanno una durata breve e l'applicazione crea nuovi DataContexts ogni volta che fa un nuovo lavoro. Ma posso vedere come potrebbe creare problemi di scalabilità, se qualcuno non fosse a conoscenza dell'ingombro aggiuntivo che accompagna ogni oggetto.

Linq è scalabile in molti modi.

Un aspetto è l'implementazione delle specifiche dietro linq, che consente a Expression di essere interpretato per esaurirsi nel processo, in una lingua diversa (Linq2Sql, Linq2Hibernate) o in un ambiente di calcolo distribuito come un cluster di riduzione della mappa per quella materia ( DryadLINQ )

Un altro aspetto è la semantica che linq fornisce alla lingua. Puoi scorrere miliardi di oggetti senza riempire la raccolta in memoria se il tuo provider supporta il caricamento differito o puoi paralizzare o ottimizzare la query (PLINQ o i4o).

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow