助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 4

新しいコメント
 
komposter:

考えてみた。意見を求められた。

ファイルを読み込む場合と比較して何が高速化され、メモリ内で作業する場合と比較して何が低速化されるのでしょうか？

DBMSは可能な限り、そのテーブルをメモリ上に配置する。

ただし、32GBのRAMを搭載している場合は別です。

20GBをいかに4GBに収めるかは、まさに最適化のチャレンジです。


もし、作業を簡略化したいのであれば、メモリに通常のRAMドライブを作っておくとよいでしょう。

できないなら、ハードディスクにしろ。

 
1) SSDという選択肢を検討する。100ギガの高速ドライブを5ルーブルかそれ以下で購入することができます。


3) バリアント1＋バリアント2、つまり、お客様のデータをデータベースに入力し、そのデータベースをソリッドステートドライブに配置することです。

最後の選択肢は、あなたにぴったりだと思います。そうでない場合は、ユーザー用OSからサーバー用OSに変更してください。
 
MKLとC#などの間のデータ転送について、ここに記事がありました。重い操作はすべてそこに置いて、RAMをすべて占有せずにファイルを一枚一枚読むことができるのです。データの転送は、構造体の形でかなり手軽で高速に行えます。
 
komposter:

ファイルを読むのに比べてどれくらい速くなり、メモリで作業するのに比べてどれくらい遅くなるのでしょうか？

まあ、単にファイルを読むだけでなく、検索、計算、テキストから数値への変換、ソートの実行なども必要なのですが。

まず、データの更新頻度が低い場合は、データ検索に関わる属性（集約属性を含む）に対して、いくつでもインデックスを作成することが可能である。したがって、（インデックスを使って）検索が速くなり、それ故に計算も速くなる。

次に、MySQL、MS SQL、Oracleなどのデータベースは、繰り返し行われるクエリに対してデータキャッシュ技術を使用しており、これもある程度の処理速度のアドバンテージになるという。

第三に、テーブルを年単位などで分割（パーティション）することができる。そのため、ある年のデータを選択するクエリは、他のパーティションのデータを読み込んだり検索したりすることはできません。

第四に、ソースデータがテキスト形式であるため、データベースにロードする際、自然な型変換によりサイズが小さくなることです。例えば、数値124.223456221はテキスト形式で13バイト、データベースでは種類に応じて4～8バイト、日時 "2014-08-17 10:23:35 "は19バイト、データベースでは8バイトを消費する。

5つ目は、ある一定期間の集計情報を頻繁に使う場合、そのデータを一度集計して、別のテーブルに格納することである。

もちろん、データをメモリに読み込むだけならWinApiの方が速いのですが、その後のデータをどうするか？想像してみてください、データの正しい部分を検索するためにさえ、ディスクからすべてのデータを読み込まなければならないのです。あるいは、インデックス機能を書き、ファイル内のデータをソートし、すべての検索操作のためのインデックスファイルを作成し、DBMS機能の半分を書き直さなければならないのです。これだけのデータ量を処理し、それなりのパフォーマンスを発揮するためには、必要なことなのです。

私の意見は明確で、専用機で サーバーDBMS（MS AccessやSQLiteのようなファイルDBMSはここでは使えません）を使うことです。十分な性能とデータ処理（SQLクエリ）が容易な合理的なものになります。そうでなければ、ファイルを処理するための低レベルの「内部」を書くのに多くの時間を浪費することになります。

 
komposter:

考えてみた。意見を求められた。

ファイルを読み込む場合と比較して何が高速化され、メモリ内で作業する場合と比較して何が低速化されるのでしょうか？

(3TBを超えるデータベースや、10-100ギガの比較的小さなデータベースを扱った経験があります。）


が、ある種のハードウェアでは．64GB以上のRAMと優れたディスクサブシステムの組み合わせ

このような状況では、巨大なファイルを扱う場合と比較して

SQLはかなり高速化されるが、もちろん速度はSQLの実装に依存する

- 正しいデータベース設計 - 正しいインデックス - 正しいデータベース構成

これは、ファイル分割を意味します（elugovoyが書いて いる方法は本当です）。

本格的な導入には、別途サーバーとサーバーOSが必要 - SQLデータベース

MS SQLは2008年以下でなければならない場合（ソフトウェアの面でも64以下ではないことが望ましい）。

ただ、私見ですが、実装にはかなりの労力とハードウェアが必要になると思います...。(64ビットが理想的です。）

--

16ギガしか搭載していないマシンで、ステーションとして使用する場合

SQLサーバーを載せるだけでは、あまり良い結果は得られませんが、テキストファイルで悩むよりはマシです。

しかし、SQLの経験がない場合、実装に多少の工夫が必要になります。

 
barabashkakvn:

また、このファイルをアーカイバで圧縮した場合、どの程度になるのでしょうか（テキストはかなり圧縮されているはずなので）。

各パスの解凍にかかる時間は、パフォーマンスを低下させます。

 
YuraZ:

各パスのアンアーカイブにかかる時間は、パフォーマンスを低下させます。

アーカイブ解除のことではありません。アーカイブすることでサイズが大幅に縮小されるのであれば、インデックスファイルに情報を圧縮することは理にかなっていると思います。
 
barabashkakvn:
アーカイブ解除のことではありません。アーカイブすることで大幅に容量を削減できるのであれば、インデックスファイルに情報を圧縮することは理にかなっています。

元々は

barabashkakvn:
また、このファイルをアーカイバで圧縮した場合、容量はどの程度になりますか（やはり、テキストは非常によく圧縮されるはずです）？

というわけで、あなたの投稿に反応しました。


インデックスファイル - 作成...それはまた別の話

自分で（SQLライクな）サーバーを書くのはもっとクールだ - でもなぜ？

 
YuraZ:

もとより

というわけで、あなたの投稿に反応しました。


インデックスファイル - 作成する...それはまた別の話

自分で（SQLのような）サーバーを書くのはもっとクールだ - しかし、なぜ？

元々、作者に質問があったのですが、ファイルはどの程度圧縮されるのでしょうか。解凍については、すでに出来上がっているんですね。
 
barabashkakvn:
元々、筆者への質問は、ファイルがどの程度圧縮されているかということでした ....

理由をお聞かせください。

70〜80%圧縮されることになり、作者が描いた問題を解決するためにどうするのか？

1234567891011...21
新しいコメント