3

今天，我使用 AnyDAC (firedac) 进行了测试，以获取远程 SQL Server 2012 中可用的所有数据。

我从中获取数据的表有这些简单的列：

1. date - (size 3 byte)
2. time - (max 5 byte)
3. int - (4 byte)
4. bit - (1 byte)
5. int - (4 byte)
6. float - (4 byte)
7. float - (4 byte)
8. int - (4 byte)
9. int - (4 byte)

总行大小应最大为 33 个字节。

好吧，在获取表中所有可用的行（超过 214 万行）后，我检查了 FireDAC 接收到的 tcp 流量并观察到它大约是 280MB，这意味着每行需要大约 130 字节，而我的预期值接近 33 字节.

我通过使用在服务器端定义的存储过程进行的另一项测量，该存储过程具有插入到上面同一个表的 sql，我使用 AnyDAC 的 Array DML 功能调用了存储过程。数组大小为 300K，我总共使用它添加了 1880 万条记录。用于它的流量实现为 2.85 GB。（所以每行 150 个字节）

FireDAC 或 SQL Server 端是否有任何配置来减少流量？显然，这里有问题。有什么建议么？

谢谢。

信息输出：

================================
Connection definition parameters
================================
User_Name=*****
Password=*******
SERVER=sql.***.gen
ApplicationName=Bist
Workstation=NB
DATABASE=BIST
MARS=yes
DriverID=MSSQL
================================
FireDAC info
================================
Tool = D18 Architect
FireDAC = 8.0.1 (Build 3279)
Platform = Windows 32 bit
Defines = AnyDAC_Unicode;AnyDAC_DBX;AnyDAC_NOLOCALE_META;
  AnyDAC_MONITOR
================================
Client info
================================
Loading driver MSSQL ...
  Loading odbc32.dll driver manager
  Creating ODBC environment handle
  Searching for ODBC driver ...
    Checking for ODBC driver [SQL SERVER NATIVE CLIENT 11.0] ...
      Found [SQL Server Native Client 11.0]
Driver Manager version = 03.80.7601.0000
================================
Session info
================================
Current catalog = 
Current schema = dbo
Driver name = sqlncli11.dll
Driver version = 11.00.2100
Driver conformance = 3
DBMS name = Microsoft SQL Server
DBMS version = 11.00.2100
4

1 回答 1

6

您到 SQL 数据库服务器的网络流量不仅包括您要传输的数据（正如您所观察到的，收到的流量比行数据多得多）

在我开始之前，让我声明几件事：我绝不是网络流量和协议方面的专家，但我已经花了相当多的时间来研究它们以了解足够的. 我也不太了解特定 DAC 软件、查询组合等将采用什么协议来将您请求的数据带回。话虽如此，我无法举一个确切的例子。但这些概念仍然适用。

与 SQL Server 的通信通过各种协议进行，但为了讨论，我们将只关注 1 个：TDS（表格数据流）协议。（您可以阅读更多关于 SQL Server 协议的信息：您可以阅读更多关于 SQL Server 协议的信息：http: //msdn.microsoft.com/en-us/library/ff420673 (v=sql.105).aspx ）。TDS 使用 TCP 协议，因此 TDS 数据包只不过是包装在 TCP 数据包中的规范）。

使用 TCP，通信基本上是请求/响应类型的交换，涉及许多请求/响应/确认数据包。同样，我绝不是这方面的专家，但您可以在http://en.wikipedia.org/wiki/Transmission_Control_Protocol阅读更多内容

仅通信的“确认”（或确认）方面就占了相当多的开销，而不仅仅是您引用的行大小。您可以在下图中看到一个示例，其中客户端应用程序和 SQL 服务器之间发生了通信：

Sql server TCP 通信

此外，在从 DB 服务器发送到应用程序的实际数据包中，TCP 数据包协议本身以及 TDS 数据包中存在大量开销。

让我们只关注 TDS 数据包的开销，它会增加您的整体数据传输负载。以下是可以在 TDS 数据包中找到的所有文档 ( http://msdn.microsoft.com/en-us/library/dd340794.aspx )：

  • ALT元数据
  • 阿尔特罗
  • COLINFO
  • 科尔元数据
  • 完毕
  • 完成过程
  • 完成程序
  • 改变
  • 错误
  • 功能扩展
  • 信息
  • 登录
  • NBCROW
  • 抵消
  • 命令
  • 返回状态
  • 返回值
  • ROW <- 这是您的数据所在的位置
  • 会话状态
  • SSPI
  • 选项卡名称
  • TVP 行

一直以来，实际上您的 ACTUAL 数据（在您上面描述的情况下）位于数据包的ROW部分。

下面是显示 1 个 TDS 数据包的 ASCII 版本的屏幕截图。数据包帧（右侧）突出显示的部分是实际的行数据。其余的只是开销，使整个通信和辅助功能正常工作。

这甚至不包括 TCP 本身产生的开销（尽管是必要的）。

总之

您正在传输大量数据，并且这些数据总是会产生开销。

  • 如果最后要汇总数据，那么在发送之前在数据库服务器上汇总。
  • 如果要搜索数据，则将该搜索卸载到数据库服务器并返回您需要的内容
  • 如果您需要列出数据（每一行），那么您可能只显示每页结果的子集 - 仅通过类似SELECT TOP 50 .... WHERE ....

根据您对数据的实际使用情况，还有许多其他解决方案，但这些只是一些想法。

希望这可以帮助！

于 2013-05-08T17:36:06.830 回答