实体，处理大量记录（> 35毫升）

Question

我们有一组相当大的相关表，每个表有超过3500万条相关记录。我需要创建一些WCF方法，这些方法将使用一些参数（数据范围，类型代码等）查询数据库并返回相关的结果集（从10到10,000条记录）。

该公司在EF 4.0上标准化，但对4.X开放。我或许可以将参数迁移到5.0但不太可能。

使用Entity处理如此大量记录的最佳方法是什么？我应该创建一组存储过程并从实体中调用它们，还是我可以在实体中做些什么？

我对数据库没有任何控制权，因此我无法拆分表或创建一些物化视图或分区表。

非常感谢任何输入/想法/建议。

Answer 1

在我的工作中，我遇到了类似的情况。我们有一个包含许多表格的数据库，其中大多数都包含大约700万到1000万条记录。我们使用Entity框架来显示数据，但页面似乎显示非常慢（例如90到100秒）。即使在网格上排序也需要时间。我被赋予了任务，看它是否可以优化。在对其进行分析（ANTS分析器）之后，我能够对其进行优化（不到7秒）。

所以答案是是的，实体框架可以处理大量记录（以百万计），但必须小心谨慎

1. 了解只有在需要实际记录时才会调用数据库。所有操作都只是用于进行查询（SQL），因此尝试仅获取一段数据而不是请求大量记录。尽可能地修剪提取大小
2. 是的，不是你应该的，你必须使用存储过程并将它们导入模型并为它们进行功能导入。您也可以直接调用它们ExecuteStoreCommand（），ExecuteStoreQuery＆lt;＆gt;（）。 Sames用于函数和视图，但EF有一种非常奇怪的方式来调用函数“SELECT dbo.blah（@id）”。
3. 当必须使用深层次结构填充实体时，EF执行速度较慢。对于具有深层次结构的实体要非常小心。
4. 有时，当您要求记录并且不需要修改它们时，您应该告诉EF不要观察属性更改（AutoDetectChanges）。这样记录检索要快得多
5. 数据库的索引很好但是在EF的情况下它变得非常重要。用于检索和排序的列应正确编入索引。
6. 当你的模特很大时，VS2010 / VS2012模型设计师变得非常疯狂。所以将您的模型打造成中型模型。存在一个限制，即不能共享来自不同模型的实体，即使它们可能指向数据库中的同一个表。
7. 当你必须在不同的地方对同一个实体进行更改时，尝试通过传递它来使用同一个实体并仅发送一次更改，而不是每个人获取一个新片段，进行更改并存储它（实际性能增益）尖端）。
8. 当您只需要一列或两列中的信息时，请尝试不要获取完整实体。你可以直接执行你的sql或者有一个迷你实体。您可能还需要在应用程序中缓存一些常用数据。
9. 交易很慢。小心他们。

如果你记住这些事情，EF应该提供与普通ADO.NET几乎相同的性能，如果不相同的话。

Answer 2

我听到这样的声明的那一刻：“公司在EF4或EF5上标准化，或者其他什么”这会让我感到寒冷。

相当于汽车租赁说“我们为整个车队标准化了单一车型”。

或者是木匠说“我已经将凿子标准化为我的整个工具包。我不会有锯，钻等......”

有一些东西被称为正确工作的正确工具 该声明仅强调负责制定关键软件架构决策的人员对软件架构没有任何线索。

如果您正在处理超过100K的记录并且数据模型很复杂（即非常重要），那么可能EF6不是最佳选择。 EF6基于动态反射的概念，并具有与Castle Project Active Record类似的设计模式

您是否需要将所有100K记录加载到内存中并对其执行操作？如果是，请问自己是否真的需要这样做，为什么不在100K记录中执行存储过程实现相同的目的。做一些分析，看看实际的数据使用模式是什么。也许用户执行的搜索返回100K记录，但他们只导航前200个。例如谷歌搜索，几乎没有人经过数百万搜索结果的第3页。

如果答案仍然是肯定，则需要将所有100K记录加载到内存中并执行操作。那么也许你需要考虑其他的东西，比如使用轻量级对象的自定义内置写入缓存。也许懒惰加载嵌套对象的动态对象指针。等等...我使用这样的东西的一个实例是电子商务网站的大型产品目录，其中针对目录执行大量搜索。为什么要提供自定义行为，例如提前退出搜索，使用预编译的正则表达式进行正则表达式通配符搜索，或将自定义Hashtable索引提供到产品目录中。

这个问题没有一个尺寸适合所有答案。这完全取决于数据使用场景以及应用程序如何处理数据。想想Gorilla Vs Shark会赢吗？这一切都取决于环境和背景。

也许EF6非常适合从动态反射中受益的单件，而NetTiers对于需要静态反射和可扩展ORM的另一件更好。虽然低级别的ADO可能最适合极高性能的产品。