需要帮助!无法解决这个问题，我遇到了硬件限制 - 页 20

[Mikhail Filimonov]

komposter，你能在你的EA中使用一个DLL吗？

如果是这样，你可以采取以下措施。

使用ZLIB将数据打包成一个头表文件

(http://www.zlib.net/)

它的工作速度会非常快（你会惊讶于它的速度。

DLL将在3毫秒内准备好工作。一切都将在 "实时 "中运作）。

数据将被减少5-8倍，并在同一文件的末尾（打包）。

将包含有ID、偏移量和数据长度的表格。

如果你在源文件中有非常多的记录，那么你就必须编译

成一个子表（几个子表），表明主表中的偏移量，所以你不需要

这样，你就不必查看整个表格，而只需查看其中的一小部分。

比如说。美元数据从0偏移量到1023储存。

欧盟数据从1024到2047等。

如果数据没有打包成一个文件（将是巨大的），将有

还有一个（很小的）子表，在这个子表中，打包器将显示文件号。

而当DLL加载文件时，它将从以下的子表中创建一个公共子表

的所有文件。更好的是，所有的偏移量都存储在第一个文件 中，如果

我们 "跨出 "一个文件，数据就来自第二个文件，等等。

我忘了...

如果你接受我的建议，我建议你把你的

使用Zlib字符串打包功能的文本数据（不是二进制数据，它工作得更快）。

我认为该函数被称为ZCompressString...

[Renat Fatkhullin]

压缩，以及加密，已经可以成为标准。

• https://www.mql5.com/ru/docs/common/cryptencode
  
• https://www.mql5.com/ru/docs/common/cryptdecode

数据加密方法

为了指定数据转换的方法（加密和哈希计算），枚举ENUM_CRYPT_METHOD被用于函数CryptEncode() 和CryptDecode()。

enum_crypt_method

恒定	描述
CRYPT_BASE64	BASE64加密(转码)
CRYPT_AES128	使用128位密钥的AES加密（16字节）
CRYPT_AES256	256位（32字节）AES加密
CRYPT_DES	DES加密，密钥为56比特（7字节）。
crypt_hash_sha1	计算HASH SHA1
crypt_hash_sha256	计算HASH SHA256
CRYPT_HASH_MD5	HASH计算MD5
CRYPT_ARCH_ZIP	ZIP归档

[Mikhail Filimonov]

Renat:

压缩，以及加密，已经可以成为标准。

• https://www.mql5.com/ru/docs/common/cryptencode
  
• https://www.mql5.com/ru/docs/common/cryptdecode

数据加密方法

为了指定数据转换的方法（加密和哈希计算），枚举ENUM_CRYPT_METHOD被用于函数CryptEncode() 和CryptDecode()。

enum_crypt_method

恒定	描述
CRYPT_BASE64	BASE64加密(转码)
CRYPT_AES128	使用128位密钥的AES加密（16字节）
CRYPT_AES256	256位（32字节）AES加密
CRYPT_DES	DES加密，密钥为56比特（7字节）。
crypt_hash_sha1	计算HASH SHA1
crypt_hash_sha256	计算HASH SHA256
CRYPT_HASH_MD5	HASH计算MD5
CRYPT_ARCH_ZIP	ZIP归档

问题不在于加密，而在于如何快速访问数据。

归档的目的是为了减少数据的大小，并允许快速传输偏移量

不是主文件（20GB），而是一个小5-8倍的文件。

但光是打包还不够，你还需要有一个快速访问数据的机制。

P/S Zlib具有快速压缩和解压字符串的功能。

[Renat Fatkhullin]

我指出，现在已经不需要第三方dlls来打包或加密数据。与你的DLL方法相反。

我没有谈及解决topstarter的问题。

[Mikhail Filimonov]

Renat:

我指出，不再需要第三方的dlls来打包或加密数据。与你的DLL方法相反。

我并没有谈及解决该话题作者的问题的办法。

DLL不是一个数据解包器，而是一个从以下方面快速提取数据的机制

文件按照一定的方案打包。

[Renat Fatkhullin]

所有这些现在都可以用语言轻松完成。压缩是作为标准配置提供的。

[Mikhail Filimonov]

Renat:
好了，现在所有这些都可以通过语言的方式轻松完成。从一开始就可以进行压缩。

很好，现在话题发起人可能会解决他的问题。

我从来没有在MQL5中处理过文件，我看看是否有可能打开

我从来没有在MQL5中处理过文件。

是的，它是 :)

bool  FileSeek(
   int                  file_handle,     // handle файла
   long                 offset,          // в байтах
   ENUM_FILE_POSITION   origin           // позиция для отсчета
   );

Будем надеятся, что терминал работает так же быстро, как и нативная DLL

[Renat Fatkhullin]

一切都在运作，而且速度很快。我已经描述了上述方法来提高我们实现中的文件操作的效率。

[Mikhail Filimonov]

Renat:
一切都在运作，而且速度很快。我已经描述了上述方法，以使文件操作在我们的实现中更加有效。

我不是在低估终端的能力和功能，但

几年前，我需要从一个1.21Gb的文件中提取数据，有21,345,728(!)行。

http://ftp.micex.com/pub/info/historical_data/Securities_market/OrderBook20130206.rar

形式的数据。

号码,证券代码,买入卖出,时间,订单号码,行动,价格,数量,交易号码,交易价格

21345728,USD000UTSTOM,B,235000002,3568,0,29.6095,300000,,

然后通过我指出的方法，搜索时间为35-45微秒。

可以说，该文件准备了2天多的时间 :(

P / S 这不是使用什么（终端或DLL）的问题，而是如何准备数据。

而事实上，终端有新的功能是非常受欢迎的!

[Eugeniy Lugovoy]

Mikalas:

我不是低估了终端的能力，但

几年前，我需要从一个1.21GB的文件中提取数据，有21,345,728(!)行。

http://ftp.micex.com/pub/info/historical_data/Securities_market/OrderBook20130206.rar

形式的数据。

号码,证券代码,买入卖出,时间,订单号码,行动,价格,数量,交易号码,交易价格

21345728,USD000UTSTOM,B,235000002,3568,0,29.6095,300000,,

然后通过我指出的方法，搜索时间为35-45微秒。

可以说，该文件准备了2天多的时间 :(

也许是几毫秒？在基于Windows的操作系统上，以微秒为单位，测量就是做不到......