問題タブ [large-data-volumes]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
3574 参照

css - 大規模なデータセットに対するjQueryグリッドの推奨事項?

私はjQueryグリッドの推奨事項を探していて、この質問/回答に出くわしました: https ://stackoverflow.com/questions/159025/jquery-grid-recommendations

そこにある多くのjQueryグリッドソリューションを調べてみると、すべてのデータセットをクライアントに配置したいと考えているようです。私が大規模なデータセット(数千/数百万のレコード)を持っている場合、これらのタイプのソリューションは明らかにうまく拡張できません(またはまったく機能しません)

私の質問:Ajaxを使用して一度に1ページだけを選択するjQueryグリッドソリューションはありますか?クライアントからajaxを介して渡された引数を使用して、サーバー側でページングや並べ替えなどを処理することを期待しています。

前もって感謝します、

-エド

更新:私はFlexiGridを使用して大成功を収めています-アプリの残りの部分はASP.NETMVC2です。唯一の落とし穴は、ASP.NET MVCに付属するSite.cssを変更する必要があることです。これは、flexigrid L&Fを台無しにするすべてのテーブル、td、およびthタグ(パディング)のスタイルを指定するためです。

更新2:fishysplashで、異なるデータテーブルを持つ複数のグリッドを計画している場合は、必要なjavascriptコードの動的生成の優れた実装があります。 http://fishysplash.com/adding-grids-using-flexigrid

0 投票する
1 に答える
700 参照

c# - ワードリストの作成方法

だから今、私はエストニア語の単語リストを小文字で約20mのユニークな単語にしたいです。ワードリストの入力を取得するには、エストニア語のコーパスを使用できます。コーパスファイルは、Text Encoding Initiative(TEI)形式です。正規表現を使って単語を見つけてみました。

これは私が作ったものです:それは非効率的です、mcvはすべて台無しです、単語のハッシュセットがメモリに収まらない場合はブレーキをかけます、それは入力エンコーディングを認識しません-おそらくšのような文字は問題を引き起こします、それは推定完了時間を示しません、一部のコントロールにはデフォルトの名前があり、一部にはありません。マルチタスクを使用していません(使用するかどうかはわかりません)。奇妙な修正と多くのロックインターフェイスを使用しているため、「フリーズ」していないように見えます。少なくとも非常に短いので、コメントがないことにほとんど気付かないでしょう。

利点は、.tei、.txt、.csv、smgl、xhtml、または同様の形式の入力から、ほとんど間違いなく単語を読み取ることができることです。

これで、私が何をしたいのか、どのように(どのような問題で)それを試したのかがわかりました。また、(最小限の肉体労働で)それを行う方法を見つけようとしています。

画像の例:

代替テキスト

コード例とGui

0 投票する
7 に答える
5252 参照

sql - SQL Server データベースの 10 億行以上の列を別の列にコピーする

データベース: SQL Server 2005

問題 : 10 億以上の行を持つ同じテーブル内の 1 つの列から別の列に値をコピーします。

試したこと1:更新クエリ

トランザクション ログがいっぱいになり、トランザクション ログ スペースが不足するためにロールバックします。

2を試しました-次の行の手順

上記の手順は、進行するにつれて速度が低下し始めます。

試した 3 - 更新用のカーソルを作成します。

通常、SQL Server のドキュメントでは推奨されておらず、このアプローチは一度に 1 行ずつ更新されるため、時間がかかりすぎます。

ある列から別の列への値のコピーを高速化できるアプローチはありますか。基本的に私は、更新クエリが一度に 50 万行ずつ順番に 10 億行をリッピングできるようにする「魔法の」キーワードまたはロジックを探しています。

ヒント、ポインタは大歓迎です。

0 投票する
1 に答える
1067 参照

sql - 複数のデータベースにわたる SQLite ビュー。これでいいですか?より良い方法はありますか?

SQlite を使用して、年ごとに分割された大規模なデータベースがあります。

要件は次のとおりです。 1. すべてのデータに一度にアクセスできること。2.挿入は現在のバージョンにのみ移動します。3. データは時間の経過とともに分割され続けます。4. アクセスは、排他的アクセスを持つ単一のプログラムを介して行われます。5. プログラムはいくつかのセットアップ SQL を受け入れることができますが、1 つまたは複数のデータベースにアクセスするときに同じ SQL を実行する必要があります。

それらをまとめて表示するために、次のことを行います(実際にはプログラムで、ここにコマンドラインを示します):sqlite3 DB_current.sq3

データベース 'DB_2006_thru_2007.sq3' を hist1 としてアタッチします。データベース 'DB_2008_thru_2009.sq3' を hist2 としてアタッチします。一時ビュー hist_tbl を作成 as select * from hist1.hist_tbl union select * from hist2.hist_tbl union select * from main.hist_tbl;

temp.hist_tbl (ビュー) と main.hist_tbl (テーブル) が追加されました。テーブルを修飾せずに選択すると、ビューからデータが取得されます。セットアップ方法に応じて、結合されたビューまたは個々のデータベースに対して既定の SQL クエリを使用できるため、これは望ましいことです。さらに、いつでも main.hist_tbl に挿入できます。

質問 1: 欠点は何ですか? 質問 2: もっと良い方法はありますか?

前もって感謝します。

0 投票する
4 に答える
397 参照

sql - 1,500 万を超えるレコードを持つ SQL 列に自動番号を追加する

SQL 2005 で約 1,500 万件のレコードがある既存のテーブルに自動付番列を追加する必要があります。

どれくらい時間がかかると思いますか?それを行うより良い方法は何ですか?

0 投票する
1 に答える
1174 参照

sql-server - Parallel.ForEachは、非常に大きなデータセットを処理するときに例外をスローします

私の質問は、以前は確実に機能していたParallel.ForEachコードに焦点を当てていますが、データベースが5倍に拡大したため、ほぼ定期的に壊れています。

ComputeTipDown()メソッドは、シンボルのすべての毎日の株価データを取得し、毎日繰り返し、昨日のデータを取得していくつかの計算を実行し、それらを毎日データベースに挿入します。

数式が変更されたときに静的データ値を再計算するためにこれを使用することはめったにありません。

例外はこれです:

代替テキスト

私たちがヒットしているデータベースには16ギガのRAMがあり、デュアルクアッドコアであり、再計算中に誰もシステムを使用していませんでした。コードを再生成するためにアプリケーションを実行しているマシンは、ハイパースレッディングオクタルコアを備えた12ギガのRAMを搭載したラップトップです。したがって、明らかなリソースの競合はありませんでした。

これは、.NET 4と並列処理を使用するための私の取り組みです。そのため、何か足りないものがあるのではないかと思います。どんな考えでも歓迎します。

0 投票する
1 に答える
2310 参照

java - ApacheCXFで大きなメッセージを転送する

最大1GBの大きなファイルをアップロードするためにCXFWSを作成しています。ほとんどの場合、10〜15 MBを超えることはありませんが、問題は、ファイルをロードして、標準のバインディングを使用して通常のbyte[]として送信することが効果的でないことです。そのため、カスタムインターセプターが必要になる場合がありますが、それが唯一のオプションであり、その記述方法もわかりません。

0 投票する
3 に答える
3001 参照

web-services - Webサービスでのシリアル化のコスト

次のプロジェクトでは、エンタープライズフレームワーク内にデータAPIを作成します。データは、異なるソフトウェアプラットフォームで実行されているいくつかのアプリケーションによって消費されます。私の同僚は一般的にSOAPを好みますが、RESTfulアーキテクチャを使用したいと思います。

ほとんどのアプリケーションは、呼び出しごとにいくつかのオブジェクトのみを必要とします。ただし、他のアプリケーションでは、それぞれが数千のレコードを含む複数の順次呼び出しを行う必要がある場合があります。パフォーマンスが気になります。シリアル化/逆シリアル化とネットワークの使用は、ボトルネックを見つけるのが怖いところです。各リクエストに大きな遅延が伴う場合、企業のすべてのアプリケーションは遅くなります。

私の恐れは現実的ですか?XMLやJSONのような大量のフォーマットへのシリアル化は問題になりますか?代替案はありますか?

これまで、パフォーマンスのために、CSVなどの「フラット」/リーナーファイル形式を使用してこれらの大規模なデータ転送を行う必要がありました。Webサービスを使用して必要なパフォーマンスを達成するにはどうすればよいですか?

RESTに固有の返信を希望しますが、SOAPユーザーがこれにどのように対処するかについても興味があります。

0 投票する
1 に答える
209 参照

hibernate - 潜在的に数十億のレコードでの ORM の使用

先日、Twitter のようなアプリは何百万人ものユーザーと取引していると考えていました。データベース内の最大ユーザー数が、データベース内の最大ユーザー数から 1 を引いた数 (彼自身) をフォローできる「フォロー」機能がどのように機能するかを考えていました。

これが多対多の双方向マッピングである場合、何十億ものレコードを持つ可能性のある関係テーブルが作成されます。また、ORM はどのようにしてそのようなレコードを取得できるのでしょうか? たとえば、ユーザー A が 20,000 人のユーザーをフォローしている場合、ORM はその 1 人のユーザーに対して 20,000 レコードをロードしますか、それともページネーション アプローチを使用しますか? 小さなレコードセット (たとえば、10 レコード未満) で JPA / ORM を扱うことはできますが、それを超えると、大きなレコードセットをサポートするソフトウェアを作成する方法に頭が下がります。申し訳ありませんが、この質問は具体的ではありませんが、これに関するアーキテクチャのアイデアを得ようとしています。余暇には、数十億のレコードに対していくつかのテストを実行しますが、最初にコミュニティから何らかの意見を得たいと考えていました.

0 投票する
6 に答える
343 参照

performance - 巨大なデータセットでのトークン カウンターの計算

膨大な量のテキスト (> 2 Tb、ウィキペディアのフル ダンプ) を調べ、表示されたトークンごとに2 つのカウンターを保持する必要があります (各カウンターは現在のイベントに応じて増加します)。これらのカウンターに必要な唯一の操作は増加です。2 番目のフェーズでは、これらのカウンターに基づいて 2 つの float を計算し、それらを格納する必要があります。

次の手順を実行する必要があります。

  1. 現在のイベントに応じて、大量のテキストを調べ、見つかった単語ごとに2 つのカウンターを増やします。
  2. すべてのトークンを調べ、それらのそれぞれについて、これらのカウンターに基づいて 2 つの追加の float を計算します。
  3. クエリを許可します (任意のトークンの値を取得します)。

要件とその他の詳細:

  • O(10^8) トークンまでスケールアップする必要があります。
  • 最終結果は非常に高速に照会する必要があります。
  • テキストを読んでいる間、2つのカウンターの増加のみが行われます。これは 1 回限りの処理であるため、処理中にクエリは発生しません。値の更新のみ。
  • 動的/更新可能なスキーマは必要ありません。

私は CouchDB と MongoDB を試してきましたが、あまり良い結果は得られませんでした。

この問題に対する最善のアプローチは何だと思いますか?

ありがとうございました!

編集 1:パトリシア トライを試して、すべてのキーがメモリに収まるかどうかをテストするように提案されました(そうではないと思われます)。1 つのステップで各キーの値を増やすための追加の演算子を使用したカスタム パトリシア トライが、可能な解決策になる可能性があります。

EDIT 2:「巨大」の意味を明確にしました: > 2 Tb のテキスト。詳細説明。

編集 3:一意のトークンの見積もり。Mike Dunlavey の提案に従って、一意のトークンを簡単に見積もってみました。データセットの最初の 830Mb では、一意のトークンは 52134 まで直線的に増加します。より多くのデータを処理した後に一意のトークンの数が遅くならない限り (これは可能性が高い)、O(10^8) 個の一意のトークンが存在するはずです。

編集 4: Java および Python ソリューションが推奨されますが、他の言語も問題ありません。

編集 5:通常、トークンには印刷可能な ASCII 文字のみが含まれますが、印刷可能な任意の Unicode 文字を含めることができます。小文字と大文字の両方をそのままにして、同じプロセスを試します。小文字のみ。