Wie funktioniert das Entity Framework für eine große Anzahl von Datensätzen?
Sehe ich schon eine un-Frage geantwortet hier auf.
Meine Frage ist -
Ist EF wirklich die Produktion bereit für große Anwendungen?
Die Frage entstand aus diesen zugrunde liegenden Fragen -
- EF zieht alle Datensätze in den Speicher und führt dann die Abfrage
Betrieb. Wie EF Verhalten würde, wenn die Tabelle hat rund ~1000 Einträgen? - Für einfache Bearbeiten, habe ich zu ziehen den Datensatz Bearbeiten und
drücken Sie dann auf db mitSaveChanges()
Kommentar zu dem Problem - Öffnen
1) EF nicht ziehen alle Datensätze in den Speicher eine Abfrage. 2) Okay... was hat das zu tun mit large-scale-Anwendungen?
Nicht mischen: Große Daten-update vs. große Anwendung. EF ist sehr praktisch für jeden Tag Daten von Operationen, d.h. das anzeigen, Bearbeiten, hinzufügen einzelner Datensätze. Es ist nicht optimiert zu tun, bulk insert/update-Operationen aber gibt es Diskussionen und versuche und Lösungen. Siehe diese SO Q&A für mehr Informationen.
@roliu Wir wollten sicherstellen, dass nicht zu ziehen ganze Tupel, wenn es notwendig ist, zu aktualisieren, die nur einen Wert.
Sie sollten nicht ändern Sie die post-Titel und tags. EF-Core ist ganz anderes system, also das, was Sie Taten ungültig werden alle aktuellen Antworten. Man sollte Sie rückgängig machen und eine neue Frage stellen statt.
InformationsquelleAutor der Frage Abhijeet | 2013-10-11
Du musst angemeldet sein, um einen Kommentar abzugeben.
Stand ich vor einer ähnlichen situation, wo wir hatten eine große Datenbank mit vielen Tabellen 7 - 10 Millionen Datensätze, die jeweils. wir verwendet Entity framework, um die Daten anzuzeigen. Um schöne Leistung hier ist, was ich gelernt; Meine 10 Goldenen Regeln für die Entity Framework:
Verstehen, dass der Aufruf der Datenbank erfolgt nur, wenn die tatsächlichen Aufzeichnungen erforderlich sind. alle Operationen werden nur verwendet, um die Abfrage (SQL), so versuchen zu Holen, nur ein Stück von Daten nicht anfordern dann eine große Anzahl von Datensätzen. Schneiden Sie die fetch-Größe wie viel wie möglich
Ja, (In einigen Fällen gespeicherte Prozeduren sind eine bessere Wahl, Sie sind nicht so böse, wie manche Sie glauben machen), sollten Sie gespeicherte Prozeduren verwenden, wo es nötig ist. Importieren Sie Sie in Ihr Modell und Funktion importiert für Sie. Sie können auch rufen Sie direkt ExecuteStoreCommand(), ExecuteStoreQuery<>(). Dasselbe gilt für Funktionen und Ansichten, aber EF hat eine wirklich seltsame Art und Weise der Aufruf von Funktionen "SELECT dbo.bla(@id)".
EF führt langsamer, wenn es um das Auffüllen einer Entität mit Tiefe Hierarchie. seien Sie extrem vorsichtig bei Personen mit tiefen Hierarchie
Manchmal, wenn Sie ersuchenden Aufzeichnungen und Sie sind nicht verpflichtet, Sie zu ändern, sollten Sie sagen, das EF nicht zu beobachten, die änderungen der Eigenschaft (AutoDetectChanges). so Abrufbarkeit ist viel schneller
Indizierung der Datenbank ist gut, aber im Falle der EF wird es sehr wichtig. Die Spalten, die Sie verwenden, für den Abruf und die Sortierung sollte korrekt indiziert.
Wenn Sie Modell ist groß, VS2010/VS2012 Modell-designer wird ' s echt verrückt. so brechen Sie Ihr Modell in mittelgroßen Modellen. Es ist eine Einschränkung, dass die Entitäten aus verschiedenen Modellen nicht freigegeben werden, auch wenn Sie vielleicht auf das gleiche Tabelle in der Datenbank.
Wenn Sie änderungen vornehmen müssen in der gleichen Entität an verschiedenen Orten, verwenden Sie die gleiche Entität, änderungen vornehmen und speichern Sie es nur einmal. Der Punkt ist, zu VERMEIDEN, abrufen von den gleichen Datensatz, änderungen vornehmen und speichern Sie es mehrere Male. (Echte performance-Gewinn Tipp).
Wenn Sie Sie brauchen, die info nur in einer oder zwei Spalten versuchen, nicht zu abrufen der vollen Einheit. Sie können entweder die Ausführung Ihrer sql-direkt oder über einen mini-Einheit etwas. Sie müssen möglicherweise den cache einige Häufig verwendete Daten in Ihre Anwendung auch.
Transaktionen langsam sind. seien Sie vorsichtig mit Ihnen.
SQL Profiler oder query-profiler ist dein Freund. Führen Sie es, wenn Sie Ihre Anwendung entwickeln, um zu sehen, was bedeutet EF sendet Datenbank. Beim ausführen einer join mit LINQ oder Lambda-Ausdruck in der ur-Anwendung, EF generiert in der Regel eine Select-Wo-In-den Stil Wählen, der Abfrage, die vielleicht nicht immer gut. Wenn u finden, eine solche Fall -, roll-up ur ärmel, führen Sie die Verknüpfung auf DB-und EF-Ergebnisse abrufen. (Ich vergaß, diese eine, die wichtigste!)
wenn Sie halten diese Dinge im Hinterkopf EF geben sollte fast eine ähnliche Leistung wie plain ADO.NET wenn nicht das gleiche.
InformationsquelleAutor der Antwort Simple Fellow
Das ist nicht wahr! EF holt nur notwendig, Datensätze und Abfragen transformiert werden in die richtige SQL-Anweisungen. EF kann die cache-Objekte lokal innerhalb
DataContext
(und verfolgen Sie alle änderungen an Entitäten), aber so lange du dich an die Regel zu halten, Rahmen nur öffnen, wenn erforderlich, es wird nicht ein problem sein.Es ist wahr, aber ich würde nicht stören, zu tun, es sei denn, Sie wirklich sehen, dass die performance-Probleme. Weil 1. stimmt nicht, du bekommst nur einen Datensatz aus der DB geholt werden, bevor es gespeichert. Umgehen kann man dass, indem Sie die SQL-Abfrage als string und senden es als einfacher string.
InformationsquelleAutor der Antwort MarcinJuraszek
SaveChanges()
bestehen alle diese Veränderungen.InformationsquelleAutor der Antwort Botz3000
EF ist nicht eine schlechte ORM-framework. Ist es ein anderer mit seinen eigenen Eigenschaften. Vergleichen Sie Microsoft Entity Framework 6, gegen sagen NetTiers angetrieben wird es von Microsoft Enterprise Library 6.
Diese sind zwei völlig verschiedene Tiere. Die akzeptierte Antwort ist wirklich gut, denn es geht durch die Nuancen der EF6. Was ist der Schlüssel zu verstehen ist, dass jedes ORM hat seine eigenen stärken und Schwächen. Vergleichen Sie die Anforderungen an ein Projekt und seine Daten zugreifen Muster gegen die ORM am Verhalten.
Beispiel: NetTiers wird Ihnen immer die höhere rohleistung als die EF6. Aber das ist in Erster Linie, weil es ist nicht ein Punkt, und klicken Sie auf ORM und als Bestandteil bei der Generierung des ORM werden Sie von der Optimierung Ihrer Daten-Modell, das hinzufügen von benutzerdefinierten gespeicherten Prozeduren, wo relevant, etc... wenn Sie entwickelt Ihre-Daten-Modell mit dem gleichen Aufwand für EF6 man wohl schließen, um die gleiche Leistung.
Auch berücksichtigen, können Sie ändern Sie den ORM? zum Beispiel mit NetTiers hinzufügen von Erweiterungen zu der codesmith-Vorlagen, um Ihre eigenen design-patterns, die über das, was erzeugt wird, durch den base-ORM-Bibliothek.
Berücksichtigen Sie auch EF6 macht erheblichen Gebrauch der Reflexion in der Erwägung, dass NetTiers oder jede Bibliothek powered by Microsoft Enterprise Library, machen starken Gebrauch von Generika statt. Diese sind zwei völlig verschiedene Ansätze. Warum ist das so? Da EF6 basiert auf dynamische Reflexion in der Erwägung, dass NetTiers basiert auf statischen Reflexion. Welche schneller ist und welche besser ist, hängt ganz von der Verwendung von mustern benötigt wird, von der ORM.
Manchmal ein hybrid-Ansatz besser funktioniert: denken Sie zum Beispiel an EF6 für Web API OData-Endpunkte, Ein paar große Tabellen verpackt mit NetTiers & Microsoft Enterprise Library mit benutzerdefinierten gespeicherten Prozeduren, und ein paar große masterdata Tabellen verpackt mit einer eigens angefertigten schreiben über Objekt-cache, wo beim erstmaligen laden des Datensatzes ist per Stream in den cache-Speicher mit Hilfe einer ADO-Daten-reader.
Diese sind alle Verschieden, und Sie alle haben Ihre best-fit-Szenarien: EF6, NetTiers, NHibernate, Wilson ODER Mapper XPO vom Dev Express, etc...
InformationsquelleAutor der Antwort tcwicks
Gibt es keine einfache Antwort auf deine Frage. Die Hauptsache ist, über das, was Sie wollen, mit Ihren Daten tun? Und brauchen Sie so viel Daten auf einmal?
EF übersetzt, Ihre Anfragen in SQL, so dass in dieser Zeit es gibt kein Objekt im Speicher. Wenn man die Daten, dann die markierten Datensätze sind im Speicher. Wenn Sie auswählen, wird eine große Menge von großen Objekten kann es dann sein, ein performance-killer, wenn Sie zu Bearbeiten müssen Sie alle.
Wenn Sie nicht brauchen, zu manipulieren, Sie alle können Sie die änderungsnachverfolgung deaktivieren und aktivieren Sie es später für einzelne Objekte, die Sie brauchen, um zu manipulieren.
Damit Sie es sehen können, hängt von Ihrer Art der Anwendung.
Wenn Sie brauchen, um zu manipulieren, eine Masse von Daten, die effizienten, dann verwenden Sie nicht ein OR-Mapper!
Sonst EF ist in Ordnung, aber Bedenken Sie, wie viele Objekte Sie wirklich brauchen, zu einer Zeit, und das, was Sie wollen mit Ihnen zu tun.
InformationsquelleAutor der Antwort Dannydust