需要帮助!无法解决这个问题，我遇到了硬件限制 - 页 5 123456789101112...21 新评论 Dmitry Fedoseev 2014.08.18 09:15 #41 你要找的东西可以被压缩并以压缩格式搜索。这将减少数据量，并允许你将所有数据保存在RAM中。(理论上) Yuriy Zaytsev 2014.08.18 09:17 #42 Integer:你要找的东西可以被压缩，并以压缩的格式进行搜索。这将减少数据量，并允许你将所有数据保存在RAM中。(理论上)我认为--如果你想以压缩的形式进行搜索--你必须先解压缩--理论上，你必须为压缩形式的数据搜索写一个算法--发疯吧问题是--MT4（32位）在内存中不能容纳太多东西---在数据库中存储大量的数据，并使用查询来获得计算出的数据，这是合乎逻辑的。我想不出有什么比自己编写数据处理机制更好的方法来应用现成的解决方案。 SQL非常适用于存储大数据，尽管20G对SQL来说并不多... --你可以编写你自己的机制，分块读取一个给定的文件，并为一个读取的片段分配最大 的内存量，以加速而20G的几个片段需要被读取以进行一个计算周期问题是，它是否会比将数据加载到数据库并通过SQL查询进行处理的方案更快--我认为不会。我认为将数据输入SQL会更快。 Dmitry Fedoseev 2014.08.18 09:19 #43 YuraZ:ichmo - 如果你想用压缩格式搜索，你首先要解压 不一定。你可以压缩你要找的东西。这就对了!:) Nikolay Likhovid 2014.08.18 09:29 #44 最健康的解决方案当然是改变算法。但由于它是未知的，这里没有什么具体的建议。当然，一般的想法可能根本不存在。 例如，由于需要多次读取文件，这些读取可能发生在一个内部 "循环 "中。人们可以尝试将阅读 "转移 "到外部 "循环 "本身--使用引号是因为在一般情况下，这样的 "转移 "可能意味着从头开始创建一个全新的算法 :) 。另一条线索来自于提到的顺序读与移位--一些要求只读 "移位 "的迭代算法可以解决这个问题。但话说回来，这可能意味着从头开始创建一个完全不同的算法。或者说，这根本就不是为了这个问题 :) Yuriy Zaytsev 2014.08.18 09:30 #45 Integer: 这是没有必要的。你可以压缩你正在寻找的东西。这就对了!:)---有大量的信息（大约20GB的文本文件）。这些信息由同一类型的序列组成，大约有一百万个。有必要反复 浏览所有的序列，并进行一些计算。---从20G开始，你必须把数据送入算法。 它不是在看--它有文件形式的数据--在算法中使用--输入到计算算法中。 Yuriy Zaytsev 2014.08.18 09:32 #46 Candid:最健康的解决方案当然是改变算法。但由于它是未知的，这里没有什么具体的建议。当然，一般的想法可能根本不存在。 例如，由于需要多次读取文件，这些读取可能发生在一个内部 "循环 "中。人们可以尝试将阅读 "转移 "到外部 "循环 "本身--使用引号是因为在一般情况下，这样的 "转移 "可能意味着从头开始创建一个全新的算法 :) 。另一条线索来自于提到的顺序读与移位--一些要求只读 "移位 "的迭代算法可以解决这个问题。但话说回来，这可能意味着从头开始创建一个完全不同的算法。或者说，这根本就不是为了这个问题 :) 将有大量数据的算法放入SQL服务器是合乎逻辑的。 Dmitry Fedoseev 2014.08.18 09:33 #47 YuraZ:---有大量的信息（大约20GB的文本文件）。这些信息由同一类型的序列组成，大约有一百万个。有必要反复 浏览所有的序列，并进行一些计算。---从20千兆字节开始，你必须将数据送入算法。 它不是在寻找--它有一个数据库--这在算法中被使用 只是一个阴谋。当然它可能是任何东西，但我猜测它是在寻找。我甚至在猜测什么。 Eugeniy Lugovoy 2014.08.18 09:41 #48 Integer: 没有必要。你可以压缩你要找的东西。这就对了!:)你让我感到惊讶，我亲爱的))))我们应使用什么算法进行压缩？赫夫曼、伦佩尔-齐夫?那么，对于一个文本作家来说，它将给你4-8倍的压缩。考虑到压缩算法为每个文件创建不同的重新编码树的事实。换句话说，源文件将有一棵树，而要找到的那部分数据将有自己的树。 这只是有趣的，你建议如何搜索，即使理论上))))。数据压缩只不过是编码而已。如果我们用加密做类比，我们会得到两个不同的信息（压缩数据），用不同的密钥（重新编码树）进行加密。甚至不可能以任何方式来匹配它们，更不用说搜索功能了 )) Dmitry Fedoseev 2014.08.18 09:45 #49 elugovoy: 你让我感到惊讶，我亲爱的))))我们应使用什么算法进行压缩？赫夫曼、伦佩尔-齐夫?那么，对于一个文本作家来说，它将给你4-8倍的压缩。考虑到压缩算法为每个文件创建不同的重新编码树的事实。换句话说，源文件将有一棵树，而要找到的那部分数据将有另一棵树。 这只是有趣的，你建议如何搜索，即使理论上))))。数据压缩只不过是编码而已。如果我们用加密做类比，我们会得到两个不同的信息（压缩数据），用不同的密钥（重新编码树）进行加密。它们甚至在任何方面都没有可比性，更不用说搜索功能了 ))哎呀，我被这里的很多事情打动了。我想即使是一个孩子也应该能够理解它。如果你用某种算法压缩一些文本，它今天和明天的压缩形式也会完全一样。你是说，使用相同的压缩算法，压缩两个不同的文本，你可以得到两个完全相同的数据序列？ Yuriy Zaytsev 2014.08.18 09:45 #50 Integer: 只是一个阴谋。当然，可以是任何东西，但我认为是搜索。我甚至在猜测什么。>> 我不知道我在寻找什么...... >> 你必须反复 浏览所有的序列，做一些计算。 嗯--是的--寻找--但要通过20个Gig来寻找......。 基本上，搜索的基础是有某种搜索和比较的事实。 我是根据作者所写的也许数据不能被缩减--压缩--索引。把数据放到SQL中是合乎逻辑的。将业务逻辑传递给服务器+数据专家顾问将只向服务器发送简短的数据，用于枚举和计算。并得到一个现成的答案。 123456789101112...21 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
你要找的东西可以被压缩并以压缩格式搜索。这将减少数据量，并允许你将所有数据保存在RAM中。(理论上)
你要找的东西可以被压缩，并以压缩的格式进行搜索。这将减少数据量，并允许你将所有数据保存在RAM中。(理论上)
我认为--如果你想以压缩的形式进行搜索--你必须先解压缩--理论上，你必须为压缩形式的数据搜索写一个算法--发疯吧
问题是--MT4（32位）在内存中不能容纳太多东西
---
在数据库中存储大量的数据，并使用查询来获得计算出的数据，这是合乎逻辑的。
我想不出有什么比自己编写数据处理机制更好的方法来应用现成的解决方案。
SQL非常适用于存储大数据，尽管20G对SQL来说并不多...
--
你可以编写你自己的机制，分块读取一个给定的文件，并为一个读取的片段分配最大 的内存量，以加速
而20G的几个片段需要被读取以进行一个计算周期
问题是，它是否会比将数据加载到数据库并通过SQL查询进行处理的方案更快--我认为不会。
我认为将数据输入SQL会更快。
ichmo - 如果你想用压缩格式搜索，你首先要解压
最健康的解决方案当然是改变算法。但由于它是未知的，这里没有什么具体的建议。当然，一般的想法可能根本不存在。
例如，由于需要多次读取文件，这些读取可能发生在一个内部 "循环 "中。人们可以尝试将阅读 "转移 "到外部 "循环 "本身--使用引号是因为在一般情况下，这样的 "转移 "可能意味着从头开始创建一个全新的算法 :) 。
另一条线索来自于提到的顺序读与移位--一些要求只读 "移位 "的迭代算法可以解决这个问题。但话说回来，这可能意味着从头开始创建一个完全不同的算法。
或者说，这根本就不是为了这个问题 :)
这是没有必要的。你可以压缩你正在寻找的东西。这就对了!:)
---
有大量的信息（大约20GB的文本文件）。
这些信息由同一类型的序列组成，大约有一百万个。
有必要反复 浏览所有的序列，并进行一些计算。
---
从20G开始，你必须把数据送入算法。
它不是在看--它有文件形式的数据--在算法中使用--输入到计算算法中。
最健康的解决方案当然是改变算法。但由于它是未知的，这里没有什么具体的建议。当然，一般的想法可能根本不存在。
例如，由于需要多次读取文件，这些读取可能发生在一个内部 "循环 "中。人们可以尝试将阅读 "转移 "到外部 "循环 "本身--使用引号是因为在一般情况下，这样的 "转移 "可能意味着从头开始创建一个全新的算法 :) 。
另一条线索来自于提到的顺序读与移位--一些要求只读 "移位 "的迭代算法可以解决这个问题。但话说回来，这可能意味着从头开始创建一个完全不同的算法。
或者说，这根本就不是为了这个问题 :)
---
有大量的信息（大约20GB的文本文件）。
这些信息由同一类型的序列组成，大约有一百万个。
有必要反复 浏览所有的序列，并进行一些计算。
---
从20千兆字节开始，你必须将数据送入算法。
它不是在寻找--它有一个数据库--这在算法中被使用
没有必要。你可以压缩你要找的东西。这就对了!:)
你让我感到惊讶，我亲爱的))))
我们应使用什么算法进行压缩？赫夫曼、伦佩尔-齐夫?
那么，对于一个文本作家来说，它将给你4-8倍的压缩。考虑到压缩算法为每个文件创建不同的重新编码树的事实。
换句话说，源文件将有一棵树，而要找到的那部分数据将有自己的树。
这只是有趣的，你建议如何搜索，即使理论上))))。
数据压缩只不过是编码而已。如果我们用加密做类比，我们会得到两个不同的信息（压缩数据），用不同的密钥（重新编码树）进行加密。
甚至不可能以任何方式来匹配它们，更不用说搜索功能了 ))
你让我感到惊讶，我亲爱的))))
我们应使用什么算法进行压缩？赫夫曼、伦佩尔-齐夫?
那么，对于一个文本作家来说，它将给你4-8倍的压缩。考虑到压缩算法为每个文件创建不同的重新编码树的事实。
换句话说，源文件将有一棵树，而要找到的那部分数据将有另一棵树。
这只是有趣的，你建议如何搜索，即使理论上))))。
数据压缩只不过是编码而已。如果我们用加密做类比，我们会得到两个不同的信息（压缩数据），用不同的密钥（重新编码树）进行加密。
它们甚至在任何方面都没有可比性，更不用说搜索功能了 ))
哎呀，我被这里的很多事情打动了。
我想即使是一个孩子也应该能够理解它。如果你用某种算法压缩一些文本，它今天和明天的压缩形式也会完全一样。
你是说，使用相同的压缩算法，压缩两个不同的文本，你可以得到两个完全相同的数据序列？
只是一个阴谋。当然，可以是任何东西，但我认为是搜索。我甚至在猜测什么。
>> 我不知道我在寻找什么......
>> 你必须反复 浏览所有的序列，做一些计算。
嗯--是的--寻找--但要通过20个Gig来寻找......。
基本上，搜索的基础是有某种搜索和比较的事实。
我是根据作者所写的也许数据不能被缩减--压缩--索引。
把数据放到SQL中是合乎逻辑的。
将业务逻辑传递给服务器+数据
专家顾问将只向服务器发送简短的数据，用于枚举和计算。
并得到一个现成的答案。