助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 6 12345678910111213...21 新しいコメント Dmitry Fedoseev 2014.08.18 09:52 #51 YuraZ:>>> 何を探しているのかわからない・・・。 >>> すべての配列を繰り返し見て、計算をする必要があります。 そうですね～、検索ですね～、でも20ギガの中から検索するんですよね・・・。 原則的には、何らかの検索や比較が行われていることを前提に 筆者が書いたものを参考にさせてもらっています。データの縮小 - 圧縮 - インデックス化ができないかもしれないSQLにデータを入れるのは論理的ですビジネスロジックをサーバーに渡す + データExpert Advisorは、列挙と計算のために短いデータのみをサーバーに送信します。と聞けば、すぐに答えが返ってくる。 力技で探すのは中世。 Yuriy Zaytsev 2014.08.18 09:55 #52 Integer:それと、このあたりはいろいろと心打たれるものがありますね。子供でも理解できるはずだと思うのですが。テキストをアルゴリズムで圧縮すれば、今日も明日もまったく同じテキストになる。ちなみに、3テラバイトを数時間かけてサーバーからサーバーにコピーしていたのは、1gbのネットワークです。ZIPに圧縮すると、3テラバイトが1日以上圧縮されました。 最初にサーバーのメモリ内で圧縮し、その後バックアップを行う素晴らしいユーティリティLiteSpeedを購入したとき 3テラバイトの圧縮時間を数時間に短縮 アンパッキング（何かを変更したり削除したりすること）にも数時間かかります。圧縮データ探索アルゴリズムの解法はカッコイイ!将来的には、すでに圧縮されたデータベースから挿入や削除を検索するアルゴリズムが開発されるかもしれない。...しかし、このようなアルゴリズムが産業界に存在するわけではありません。ORACL MS SQLデータベースがある - 世界中でデータを圧縮して保存している人はいない - 集中的に作業する場合 Dmitry Fedoseev 2014.08.18 10:04 #53 YuraZ:1.ちなみに、3テラバイトを数時間かけてサーバーからサーバーにコピーしていたのは、1gbネットワークZIPに圧縮すると、3テラバイトが1日以上圧縮されました。 私はLiteSpeedというクールなユーティリティを購入し、まずサーバーのメモリを圧縮し、次にバックアップを行います。 3テラバイトの圧縮時間を数時間に短縮 unpacking（何かを変更したり削除したりすること）にも数時間かかります。2.圧縮データの探索アルゴリズムの解法がかっこいい3.将来、誰かが既に圧縮されたデータベースの挿入と削除を検索するアルゴリズムを考え出すかもしれない。4. ...しかし、このようなアルゴリズムが産業界に存在するわけではありません。産業ORACL MS SQLデータベースは、世界で誰も圧縮形式でデータを格納されていない - あなたがそれらを集中的に作業する場合 1.今回のタスクでは、データ圧縮は1回しか行わず、圧縮に1週間かかることもあります。2）何がそんなにカッコイイのか？3）なぜ、何かを発明しなければならないのか？問題は、それが必要なのか、不要なのか。4.では、そうでない場合はどうでしょうか。 Yuriy Zaytsev 2014.08.18 10:30 #54 Integer:1.目の前のタスクのために、データ圧縮は1回やれば1週間は大丈夫です。2.どこがカッコいいの？3.何を発明するのか？問題は、それが必要なのか、そうでないのか、ということです。4.では、そうでない場合はどうでしょうか。1) p4 を解いてから p12）まあ - 私は知らない多分質問（FAST）大規模なデータセットでの検索は、すでに十分な資格の専門家と複数回を介して考えられている - とこれまでのところ、ないアルゴリズム 3) 神は知っている - 圧縮されたデータでの検索が発明されるかもしれないが、それは解決されないし、ほとんどの場合、それは必要ないからだ...。4）もしかしたら-世界中の優秀な頭脳が、圧縮されたデータで（高速）検索するアルゴリズムを発明するかもしれない。 圧縮されたデータを（ゆっくり）検索することは可能です。方法論（解凍してから検索する）があれば、問題ないのですが...。 Dmitry Fedoseev 2014.08.18 10:35 #55 圧縮されたデータでの検索は、誰も言っていないんです。圧縮された2つの配列を比較する話です。aaa"、"bbb"、"vvv "という配列があるとする。3つの配列 要素は、それぞれ独立して圧縮されます。圧縮して、配列「a」「b」「c」を得たとします。求められた文字列 "bbb "は、配列の中から探す必要があります。検索する前に、圧縮して "b "を得る。さあ、検索して見つけてください。 Yuriy Zaytsev 2014.08.18 10:38 #56 Integer:圧縮データでの検索は誰も言っていない。圧縮された2つの配列を比較する話です。aaa"、"bbb"、"vvv "という配列があるとする。3つの配列 要素は、それぞれ独立して圧縮されます。圧縮して、配列「a」「b」「c」を得たとします。配列の中から目的の文字列 "bbb "を見つける必要があります。検索する前に、圧縮して "b "を得る。今、私たちはそれを探し、見つけることができます。考え方は明快だ... にもかかわらず、この方法論は（ちょっと検索しただけで、）産業界のデータベースには存在しない訳あり Eugeniy Lugovoy 2014.08.18 10:41 #57 Integer:それと、このあたりはいろいろと心打たれるものがありますね。子供でも理解できるはずだと思うのですが。あるテキストをあるアルゴリズムで圧縮すれば、今日も明日も全く同じ圧縮形式になる。同じ圧縮アルゴリズムを使って、2つの異なるテキストを圧縮すると、完全に同一のデータ列が2つ得られると言うことですか？なぜ私がそう言っていると思うのですか？ Sergey Gridnev 2014.08.18 10:41 #58 YuraZ:考え方は明快だ... にもかかわらず、この方法論は（ちょっと検索しただけでは）業界ベースでは利用できない理由があるはずだ。もちろん、理由はありますよ :)データ圧縮とは、冗長性を排除することです。そして、圧縮を効率的に行うことで、冗長性を減らすことができます。また、圧縮されたテキストでは、任意の部分がテキスト全体に依存するため、上記の方法で提案した検索はうまくいきません。 Yuriy Zaytsev 2014.08.18 10:42 #59 Contender:当然、理由もある :)データ圧縮とは、冗長性を排除することです。そして、圧縮が効率的に行われるほど、冗長性は少なくなります。また、圧縮されたテキストでは、どの部分もテキスト全体に依存するため、上記の方法で検索することはできません。:-) そういうことなんです． Dmitry Fedoseev 2014.08.18 10:46 #60 elugovoy: なぜ私がそう言っていると思うのですか？ヒントみたいなものですね。まあ、テキストの4〜8倍の圧縮率は得られるでしょう。圧縮アルゴリズムが、 ファイルごとに独自の トランスコード・ツリーを作成するという事実を考えてみてください。 つまりは の場合、ソースファイルには1つのツリーがありますが、探したいデータの部分には別のツリーがあります。. ただ、理論的にでもいいので、どのように検索するのかが気になります ))))検索の仕方、先に 書きました。 12345678910111213...21 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
>>> 何を探しているのかわからない・・・。
>>> すべての配列を繰り返し見て、計算をする必要があります。
そうですね～、検索ですね～、でも20ギガの中から検索するんですよね・・・。
原則的には、何らかの検索や比較が行われていることを前提に
筆者が書いたものを参考にさせてもらっています。データの縮小 - 圧縮 - インデックス化ができないかもしれない
SQLにデータを入れるのは論理的です
ビジネスロジックをサーバーに渡す + データ
Expert Advisorは、列挙と計算のために短いデータのみをサーバーに送信します。
と聞けば、すぐに答えが返ってくる。
それと、このあたりはいろいろと心打たれるものがありますね。
子供でも理解できるはずだと思うのですが。テキストをアルゴリズムで圧縮すれば、今日も明日もまったく同じテキストになる。
ちなみに、3テラバイトを数時間かけてサーバーからサーバーにコピーしていたのは、1gbのネットワークです。
ZIPに圧縮すると、3テラバイトが1日以上圧縮されました。
最初にサーバーのメモリ内で圧縮し、その後バックアップを行う素晴らしいユーティリティLiteSpeedを購入したとき
3テラバイトの圧縮時間を数時間に短縮
アンパッキング（何かを変更したり削除したりすること）にも数時間かかります。
圧縮データ探索アルゴリズムの解法はカッコイイ!
将来的には、すでに圧縮されたデータベースから挿入や削除を検索するアルゴリズムが開発されるかもしれない。
...しかし、このようなアルゴリズムが産業界に存在するわけではありません。
ORACL MS SQLデータベースがある - 世界中でデータを圧縮して保存している人はいない - 集中的に作業する場合
1.ちなみに、3テラバイトを数時間かけてサーバーからサーバーにコピーしていたのは、1gbネットワーク
ZIPに圧縮すると、3テラバイトが1日以上圧縮されました。
私はLiteSpeedというクールなユーティリティを購入し、まずサーバーのメモリを圧縮し、次にバックアップを行います。
3テラバイトの圧縮時間を数時間に短縮
unpacking（何かを変更したり削除したりすること）にも数時間かかります。
2.圧縮データの探索アルゴリズムの解法がかっこいい
3.将来、誰かが既に圧縮されたデータベースの挿入と削除を検索するアルゴリズムを考え出すかもしれない。
4. ...しかし、このようなアルゴリズムが産業界に存在するわけではありません。
産業ORACL MS SQLデータベースは、世界で誰も圧縮形式でデータを格納されていない - あなたがそれらを集中的に作業する場合
1.今回のタスクでは、データ圧縮は1回しか行わず、圧縮に1週間かかることもあります。
2）何がそんなにカッコイイのか？
3）なぜ、何かを発明しなければならないのか？問題は、それが必要なのか、不要なのか。
4.では、そうでない場合はどうでしょうか。
1.目の前のタスクのために、データ圧縮は1回やれば1週間は大丈夫です。
2.どこがカッコいいの？
3.何を発明するのか？問題は、それが必要なのか、そうでないのか、ということです。
4.では、そうでない場合はどうでしょうか。
1) p4 を解いてから p1
2）まあ - 私は知らない多分質問（FAST）大規模なデータセットでの検索は、すでに十分な資格の専門家と複数回を介して考えられている - とこれまでのところ、ないアルゴリズム
3) 神は知っている - 圧縮されたデータでの検索が発明されるかもしれないが、それは解決されないし、ほとんどの場合、それは必要ないからだ...。
4）もしかしたら-世界中の優秀な頭脳が、圧縮されたデータで（高速）検索するアルゴリズムを発明するかもしれない。
圧縮されたデータを（ゆっくり）検索することは可能です。方法論（解凍してから検索する）があれば、問題ないのですが...。
圧縮されたデータでの検索は、誰も言っていないんです。圧縮された2つの配列を比較する話です。
aaa"、"bbb"、"vvv "という配列があるとする。3つの配列 要素は、それぞれ独立して圧縮されます。圧縮して、配列「a」「b」「c」を得たとします。
求められた文字列 "bbb "は、配列の中から探す必要があります。検索する前に、圧縮して "b "を得る。さあ、検索して見つけてください。
圧縮データでの検索は誰も言っていない。圧縮された2つの配列を比較する話です。
aaa"、"bbb"、"vvv "という配列があるとする。3つの配列 要素は、それぞれ独立して圧縮されます。圧縮して、配列「a」「b」「c」を得たとします。
配列の中から目的の文字列 "bbb "を見つける必要があります。検索する前に、圧縮して "b "を得る。今、私たちはそれを探し、見つけることができます。
考え方は明快だ...
にもかかわらず、この方法論は（ちょっと検索しただけで、）産業界のデータベースには存在しない
訳あり
それと、このあたりはいろいろと心打たれるものがありますね。
子供でも理解できるはずだと思うのですが。あるテキストをあるアルゴリズムで圧縮すれば、今日も明日も全く同じ圧縮形式になる。
同じ圧縮アルゴリズムを使って、2つの異なるテキストを圧縮すると、完全に同一のデータ列が2つ得られると言うことですか？
なぜ私がそう言っていると思うのですか？
考え方は明快だ...
にもかかわらず、この方法論は（ちょっと検索しただけでは）業界ベースでは利用できない
理由があるはずだ。
もちろん、理由はありますよ :)
データ圧縮とは、冗長性を排除することです。そして、圧縮を効率的に行うことで、冗長性を減らすことができます。また、圧縮されたテキストでは、任意の部分がテキスト全体に依存するため、上記の方法で提案した検索はうまくいきません。
当然、理由もある :)
データ圧縮とは、冗長性を排除することです。そして、圧縮が効率的に行われるほど、冗長性は少なくなります。また、圧縮されたテキストでは、どの部分もテキスト全体に依存するため、上記の方法で検索することはできません。
なぜ私がそう言っていると思うのですか？
ヒントみたいなものですね。
まあ、テキストの4〜8倍の圧縮率は得られるでしょう。圧縮アルゴリズムが、 ファイルごとに独自の トランスコード・ツリーを作成するという事実を考えてみてください。
つまりは の場合、ソースファイルには1つのツリーがありますが、探したいデータの部分には別のツリーがあります。.
ただ、理論的にでもいいので、どのように検索するのかが気になります ))))
検索の仕方、先に 書きました。