如何实体框架适用于大量的记录？ [英] How entity framework works for large number of records?

问题描述

我看到这里已经是未回答的问题上< 。/ A>

我的问题是 -

时的EF真正投入生产？对于大型应用程序

问题源于这些基本问题 -

1. EF拉的所有记录到内存中，然后执行查询
   操作。如何当桌子周围有EF会表现得〜1000条记录？


2. 对于简单的编辑我要拉记录编辑它，
   然后按使用到数据库调用SaveChanges（）

解决方案

我遇到了类似的情况，我们曾与许多表7-10万条记录每一个大的数据库。我们使用实体框架来显示数据。为了获得好的绩效这里是我的经验教训;对于实体框架 我的10黄金规则：

1. 记者了解到，调用数据库的，只有当实际记录是必需的。所有的操作都​​只是用来做查询（SQL），所以尝试获取只有一块数据而不是请求大量的记录。修剪的获取大小尽可能




2. 是的，（在某些情况下，存储过程是一个更好的选择，他们不是邪恶的一些让你相信） ，你应该在必要时使用存储过程。将其导入到你的模型，并有功能的进口他们。您也可以直接拨打他们ExecuteStoreCommand（），ExecuteStoreQuery<>（）。也是一样的功能和意见，但EF具有通话功能SELECT dbo.blah（@id）的一个非常奇怪的方式。




3. EF执行慢，当它有填充一个实体深层次结构。与深层次的实体非常小心




4. 有时，当你正在请求的记录，你是不是需要修改它们，你应该告诉EF不看属性更改（AutoDetectChanges）。这种方式记录检索速度更快




5. 数据库的索引是好的，但在EF的情况下，它变得非常重要。列使用检索和排序应该正确索引。




6. 在模型很大，VS2010 / VS2012模型设计得到真正的疯狂。所以打破你的模型到中型车型。有一个限制，即从不同的模型实体不能即使它们可被指向数据库中的相同的表共享。




7. 当你必须做出在不同的地方是同一个实体的变化，使用相同的实体，进行修改并保存它只有一次。问题的关键是避免检索相同的记录，进行修改和放大器;保存多次。 （真实的性能增益尖）。




8. 当你需要在一个或两个列中的信息尽量不取完整的实体。您可以直接执行SQL或有一个小型实体的东西。您可能需要缓存在应用程序中也有一些经常使用的数据。




9. 交易是缓慢的。小心他们。




10. SQL事件探查器或查询分析器是你的朋友。开发应用程序时，看什么呢EF发送到数据库中运行它。当您执行联接使用LINQ和Lambda表达式在乌拉圭回合的应用程序，通常EF生成一个选择 - 在哪里 - 在 - 选择样式的查询可能并不总是表现良好。如果妳发现任何这种情况下，挽起袖子乌尔，执行对数据库的连接，并有EF检索结果。 （我忘了这其中，最重要的！）

如果你把这些东西记EF应该给几乎表现为纯ADO.NET如不相同相似。

I see already a un-answered question here on.

My question is -

Is EF really production ready for large application?

The question originated from these underlying questions -

1. EF pulls all the records into memory then performs the query operation. How EF would behave when table has around ~1000 records?
2. For simple edit I have to pull the record edit it and then push to db using SaveChanges()

解决方案

I faced a similar situation where we had a large database with many tables 7- 10 million records each. we used Entity framework to display the data. To get nice performance here's what I learned; My 10 Golden rules for Entity Framework:

1. Understand that call to database made only when the actual records are required. all the operations are just used to make the query (SQL) so try to fetch only a piece of data rather then requesting a large number of records. Trim the fetch size as much as possible

2. Yes, (In some cases stored procedures are a better choice, they are not that evil as some make you believe), you should use stored procedures where necessary. Import them into your model and have function imports for them. You can also call them directly ExecuteStoreCommand(), ExecuteStoreQuery<>(). Same goes for functions and views but EF has a really odd way of calling functions "SELECT dbo.blah(@id)".

3. EF performs slower when it has to populate an Entity with deep hierarchy. be extremely careful with entities with deep hierarchy

4. Sometimes when you are requesting records and you are not required to modify them you should tell EF not to watch the property changes (AutoDetectChanges). that way record retrieval is much faster

5. Indexing of database is good but in case of EF it becomes very important. The columns you use for retrieval and sorting should be properly indexed.

6. When you model is large, VS2010/VS2012 Model designer gets real crazy. so break your model into medium sized models. There is a limitation that the Entities from different models cannot be shared even though they may be pointing to the same table in the database.

7. When you have to make changes in the same entity at different places, use the same entity, make changes and save it only once. The point is to AVOID retrieving the same record, make changes & save it multiple times. (Real performance gain tip).

8. When you need the info in only one or two columns try not to fetch the full entity. you can either execute your sql directly or have a mini entity something. You may need to cache some frequently used data in your application also.

9. Transactions are slow. be careful with them.

10. SQL Profiler or any query profiler is your friend. Run it when developing your application to see what does EF sends to database. When you perform a join using LINQ or Lambda expression in ur application, EF usually generates a Select-Where-In-Select style query which may not always perform well. If u find any such case, roll up ur sleeves, perform the join on DB and have EF retrieve results. (I forgot this one, the most important one!)

if you keep these things in mind EF should give almost similar performance as plain ADO.NET if not the same.

这篇关于如何实体框架适用于大量的记录？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！