gpt4 book ai didi

entity-framework-4 - 实体,处理大量记录(> 3,500万)

转载 作者:行者123 更新时间:2023-12-05 00:31:51 29 4
gpt4 key购买 nike

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

该公司在EF 4.0上进行了标准化,但对4.X开放。我也许可以说服自己移植到5.0,但可能性很小。

使用Entity处理如此大量的记录的最佳方法是什么?我应该创建一组存储的proc并从Entity中调用它们,还是可以在Entity中执行某些操作?

我对数据库没有任何控制权,因此无法拆分表或创建某些物化 View 或分区表。

任何输入/想法/建议,我们将不胜感激。

最佳答案

在我的工作中,我遇到了类似的情况。我们有一个包含许多表的数据库,其中大多数表包含大约7到1千万条记录。我们使用 Entity Framework 来显示数据,但是页面似乎显示得非常慢(例如90到100秒)。甚至在网格上进行排序也需要时间。我得到了一项任务,看是否可以对其进行优化。并且在对它进行分析之后(ANTS profiler),我能够对其进行优化(不到7秒)。

所以答案是是的,Entity Framework可以处理记录负载(以百万计),但是必须格外小心

  • 了解仅在需要实际记录时才对数据库进行的调用。所有操作仅用于进行查询(SQL),因此请尝试仅获取一条数据,而不是请求大量记录。尽可能缩小获取大小
  • 是的,不是应该的,您必须使用存储过程并将其导入模型中,并为它们导入函数。您也可以直接调用它们ExecuteStoreCommand(),ExecuteStoreQuery <>()。函数和 View 也一样,但是EF调用函数“SELECT dbo.blah(@id)”的方法确实很奇怪。
  • EF必须填充具有较深层次结构的实体时,其执行速度较慢。对具有较高层次的实体极为小心。
  • 有时,当您请求记录且不需要修改它们时,应告诉EF不要监视属性更改(AutoDetectChanges)。这样,记录检索就更快了
  • 数据库索引很好,但是在EF的情况下,它变得非常重要。用于检索和排序的列应正确索引。
  • 当您的模型很大时,VS2010/VS2012模型设计器会变得非常疯狂。因此将您的模型分成中等大小的模型。存在一个局限性,即使它们可能指向数据库中的同一表,也无法共享来自不同模型的实体。
  • 当您必须在不同位置的同一实体中进行更改时,请尝试通过传递相同的实体并仅发送一次更改,而不是每一次都获取一个新的更改,进行更改并存储(实际性能提高技巧) 。
  • 当您只需要一两列信息时,请尽量不要获取完整的实体。您可以直接执行sql,也可以拥有迷你实体。您可能还需要在应用程序中缓存一些经常使用的数据。
  • 事务很慢。小心他们。

  • 如果您牢记这些内容,那么EF应该会提供与普通ADO.NET几乎相同的性能(如果不同的话)。

    关于entity-framework-4 - 实体,处理大量记录(> 3,500万),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14205033/

    29 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com