需要帮助!无法解决这个问题，我遇到了硬件限制 - 页 6 12345678910111213...21 新评论 Dmitry Fedoseev 2014.08.18 11:52 #51 YuraZ:>> 我不知道我在寻找什么...... >> 你必须反复 浏览所有的序列，做一些计算。 嗯--是的--搜索--但它搜索的是20G... 原则上，搜索的基础是，有一些搜索和比较 我是按照作者所写的去做的。也许数据不能被缩减--压缩--索引把数据放到SQL中是合乎逻辑的。将业务逻辑传递给服务器+数据专家顾问将只向服务器发送简短的数据，用于枚举和计算。并得到一个现成的答案。 用蛮力搜索是中世纪的事。 Yuriy Zaytsev 2014.08.18 11:55 #52 Integer:哦，我被这里的很多事情打动了。在我看来，即使是一个孩子也应该能够理解它。如果一个文本使用一种算法进行压缩，那么它今天和明天都会完全一样。顺便说一下 - 3兆字节被从服务器复制到服务器数小时 - 1GB的网络当压缩成ZIP时，3兆字节被压缩了一天多的时间 当你购买了伟大的工具LiteSpeed，它首先在服务器内存中进行压缩，然后进行备份。 3兆字节的压缩时间被减少到几个小时 拆包（改变或删除一些东西）也需要几个小时。解决压缩数据的搜索算法是很酷的!也许将来有人会想出一些算法来搜索已经压缩的数据库中的插入和删除。...但目前还没有工业规模的这种算法。有ORACL MS SQL数据库--世界上没有人以压缩的形式存储数据--如果你密集地使用它们 Dmitry Fedoseev 2014.08.18 12:04 #53 YuraZ:1.顺便说一下，3兆字节从服务器复制到服务器，持续了几个小时 - 1GB网络当压缩成ZIP时，3兆字节被压缩了一天多的时间 我买了一个很酷的工具，叫LiteSpeed，它首先压缩服务器内存，然后备份 3兆字节的压缩时间被减少到几个小时 拆包（改变或恢复、删除）也需要几个小时。2.解决了在压缩数据中搜索的算法是很酷的!3.也许将来有人会想出一些算法来搜索已经压缩的数据库中的插入和删除内容4. ...但目前还没有工业规模的这种算法。有工业ORACL MS SQL数据库，世界上没有人以压缩形式存储数据--如果你密集地使用它们的话 1.对于手头的任务，数据压缩只进行一次，压缩数据可能需要一个星期。2）它有什么了不起的地方？3）我们为什么要发明东西？问题是，你是否需要它？4.那么，如果不是这样呢？ Yuriy Zaytsev 2014.08.18 12:30 #54 Integer:1.对于手头的任务，数据压缩做一次，你就可以做一个星期。2.它有什么了不起的地方？3.有什么可发明的？问题是，这是否有必要？4.那么，如果不是这样呢？1）只有在解决了P4之后才有P12）好吧--我不知道，也许这个问题（快速）在大型数据集中的搜索已经被足够多的合格的专业人士思考过了，而且不止一次--到目前为止还没有算法 3）天知道--压缩数据中的搜索可能被发明了，但它没有被解决，而且很可能是因为它根本不需要......4）也许--世界上最好的大脑会发明一种在压缩数据中进行（快速）搜索的算法 在压缩的数据中搜索（缓慢地）是可能的--用一种方法（解压缩然后搜索），这不是一个问题... Dmitry Fedoseev 2014.08.18 12:35 #55 没有人在谈论在压缩数据中搜索的问题。我们谈论的是比较两个压缩序列的情况。假设一个数组，"aaa"，"bbb"，"vvv"。三个阵列元素 中的每一个都是独立于其他元素而被压缩的。假设我们压缩并得到数组 "a"、"b"、"c"。我们有一个寻求的字符串 "bbb"，我们需要在数组中找到它。在搜索之前，我们对其进行压缩，得到 "b"。现在搜索并找到。 Yuriy Zaytsev 2014.08.18 12:38 #56 Integer:没有人在谈论在压缩数据中搜索的问题。我们谈论的是比较两个压缩序列的情况。假设一个数组，"aaa"，"bbb"，"vvv"。三个数组元素 中的每一个都是独立于其他元素被压缩的。假设我们压缩并得到数组 "a"、"b"、"c"。我们有一个想要的字符串 "bbb"，我们需要在数组中找到它。在搜索之前，我们对其进行压缩，得到 "b"。现在我们搜索并找到它。想法很清楚... 而这种方法（通过快速搜索）在工业数据库中却没有。一定有原因的 Eugeniy Lugovoy 2014.08.18 12:41 #57 Integer:哦，我被这里的很多事情打动了。在我看来，即使是一个孩子也应该能够理解它。如果你用某种算法压缩一些文本，它今天和明天的压缩形式也会完全一样。你是说，使用相同的压缩算法并压缩两个不同的文本，你可以得到两个完全相同的数据序列？你怎么会认为我在说这个？ Sergey Gridnev 2014.08.18 12:41 #58 YuraZ:想法很清楚... 而这种方法（通过快速搜索）在行业基础上却无法得到。一定是有原因的。当然是有原因的 :)数据压缩是为了消除冗余。而且，压缩的效率越高，冗余度就越低。而上面提出的搜索方法将不起作用，因为在压缩的文本中，任何部分都将取决于整个文本。 Yuriy Zaytsev 2014.08.18 12:42 #59 Contender:自然是有原因的 :)数据压缩是为了消除冗余。而压缩的效率越高，冗余度就越低。而且你不能用上述方法进行搜索，因为在一个压缩的文本中，任何部分都将取决于整个文本。:-)这就是我们正在谈论的...... Dmitry Fedoseev 2014.08.18 12:46 #60 elugovoy: 你怎么会认为我在说这个？你有点暗示了。那么，对于一个文本文件，它将给你4-8倍的压缩。考虑到压缩算法为每个文件创建自己的 转码树的事实。 换句话说。 源文件将有一棵树，但你想找到的那部分数据将有一个不同的树。. 只是想知道你建议如何进行搜索？即使是理论上的))))。如何搜索，我之前 写过。 12345678910111213...21 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
>> 我不知道我在寻找什么......
>> 你必须反复 浏览所有的序列，做一些计算。
嗯--是的--搜索--但它搜索的是20G...
原则上，搜索的基础是，有一些搜索和比较
我是按照作者所写的去做的。也许数据不能被缩减--压缩--索引
把数据放到SQL中是合乎逻辑的。
将业务逻辑传递给服务器+数据
专家顾问将只向服务器发送简短的数据，用于枚举和计算。
并得到一个现成的答案。
哦，我被这里的很多事情打动了。
在我看来，即使是一个孩子也应该能够理解它。如果一个文本使用一种算法进行压缩，那么它今天和明天都会完全一样。
顺便说一下 - 3兆字节被从服务器复制到服务器数小时 - 1GB的网络
当压缩成ZIP时，3兆字节被压缩了一天多的时间
当你购买了伟大的工具LiteSpeed，它首先在服务器内存中进行压缩，然后进行备份。
3兆字节的压缩时间被减少到几个小时
拆包（改变或删除一些东西）也需要几个小时。
解决压缩数据的搜索算法是很酷的!
也许将来有人会想出一些算法来搜索已经压缩的数据库中的插入和删除。
...但目前还没有工业规模的这种算法。
有ORACL MS SQL数据库--世界上没有人以压缩的形式存储数据--如果你密集地使用它们
1.顺便说一下，3兆字节从服务器复制到服务器，持续了几个小时 - 1GB网络
当压缩成ZIP时，3兆字节被压缩了一天多的时间
我买了一个很酷的工具，叫LiteSpeed，它首先压缩服务器内存，然后备份
3兆字节的压缩时间被减少到几个小时
拆包（改变或恢复、删除）也需要几个小时。
2.解决了在压缩数据中搜索的算法是很酷的!
3.也许将来有人会想出一些算法来搜索已经压缩的数据库中的插入和删除内容
4. ...但目前还没有工业规模的这种算法。
有工业ORACL MS SQL数据库，世界上没有人以压缩形式存储数据--如果你密集地使用它们的话
1.对于手头的任务，数据压缩只进行一次，压缩数据可能需要一个星期。
2）它有什么了不起的地方？
3）我们为什么要发明东西？问题是，你是否需要它？
4.那么，如果不是这样呢？
1.对于手头的任务，数据压缩做一次，你就可以做一个星期。
2.它有什么了不起的地方？
3.有什么可发明的？问题是，这是否有必要？
4.那么，如果不是这样呢？
1）只有在解决了P4之后才有P1
2）好吧--我不知道，也许这个问题（快速）在大型数据集中的搜索已经被足够多的合格的专业人士思考过了，而且不止一次--到目前为止还没有算法
3）天知道--压缩数据中的搜索可能被发明了，但它没有被解决，而且很可能是因为它根本不需要......
4）也许--世界上最好的大脑会发明一种在压缩数据中进行（快速）搜索的算法
在压缩的数据中搜索（缓慢地）是可能的--用一种方法（解压缩然后搜索），这不是一个问题...
没有人在谈论在压缩数据中搜索的问题。我们谈论的是比较两个压缩序列的情况。
假设一个数组，"aaa"，"bbb"，"vvv"。三个阵列元素 中的每一个都是独立于其他元素而被压缩的。假设我们压缩并得到数组 "a"、"b"、"c"。
我们有一个寻求的字符串 "bbb"，我们需要在数组中找到它。在搜索之前，我们对其进行压缩，得到 "b"。现在搜索并找到。
没有人在谈论在压缩数据中搜索的问题。我们谈论的是比较两个压缩序列的情况。
假设一个数组，"aaa"，"bbb"，"vvv"。三个数组元素 中的每一个都是独立于其他元素被压缩的。假设我们压缩并得到数组 "a"、"b"、"c"。
我们有一个想要的字符串 "bbb"，我们需要在数组中找到它。在搜索之前，我们对其进行压缩，得到 "b"。现在我们搜索并找到它。
想法很清楚...
而这种方法（通过快速搜索）在工业数据库中却没有。
一定有原因的
哦，我被这里的很多事情打动了。
在我看来，即使是一个孩子也应该能够理解它。如果你用某种算法压缩一些文本，它今天和明天的压缩形式也会完全一样。
你是说，使用相同的压缩算法并压缩两个不同的文本，你可以得到两个完全相同的数据序列？
你怎么会认为我在说这个？
想法很清楚...
而这种方法（通过快速搜索）在行业基础上却无法得到。
一定是有原因的。
当然是有原因的 :)
数据压缩是为了消除冗余。而且，压缩的效率越高，冗余度就越低。而上面提出的搜索方法将不起作用，因为在压缩的文本中，任何部分都将取决于整个文本。
自然是有原因的 :)
数据压缩是为了消除冗余。而压缩的效率越高，冗余度就越低。而且你不能用上述方法进行搜索，因为在一个压缩的文本中，任何部分都将取决于整个文本。
你怎么会认为我在说这个？
你有点暗示了。
那么，对于一个文本文件，它将给你4-8倍的压缩。考虑到压缩算法为每个文件创建自己的 转码树的事实。
换句话说。 源文件将有一棵树，但你想找到的那部分数据将有一个不同的树。.
只是想知道你建议如何进行搜索？即使是理论上的))))。
如何搜索，我之前 写过。