問題タブ [large-scale]

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 投票する
8 に答える
1794 参照

artificial-intelligence - 脳のモデリング

PC あたり 1 テラフロップスに達したにもかかわらず、昆虫の脳をモデル化することはまだできていません。自己学習型、自己開発型のニューラル ネットワークの適切な実装を見た人はいますか?

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

haskell - Haskell で大きなファイルを扱う

私は大きなファイル (4 ギガ以上) を持っています。たとえば、4 バイトのフロートです。map、filter、foldlなどを使用できるようにしたいという意味で、リストとして扱いたいと思います。しかし、出力で新しいリストを作成する代わりに、出力を書き戻したいと思いますしたがって、ファイルのごく一部をメモリにロードするだけで済みます。MutableFileList と呼ばれるタイプと言えます

誰かが以前にこの状況に遭遇したことがありますか? 車輪を再発明する代わりに、これに対処するためのハック的な方法があるかどうか疑問に思っていましたか?

0 投票する
8 に答える
61060 参照

haskell - Haskellの大規模なデザイン?

特にHaskellで大規模な機能プログラムを設計/構造化するための良い方法は何ですか?

私はたくさんのチュートリアルを経験しました(自分でスキームを書くのが私のお気に入りで、Real World Haskellがすぐ近くにあります)-しかし、ほとんどのプログラムは比較的小さく、単一目的です。さらに、それらのいくつかは特にエレガントであるとは考えていません(たとえば、WYASの膨大なルックアップテーブル)。

さまざまなソースからデータを取得し、クリーニングし、さまざまな方法で処理し、ユーザーインターフェイスに表示し、永続化し、ネットワークを介して通信するなど、より多くの可動部分を備えた、より大きなプログラムを作成したいと考えています。そのようなコードを読みやすく、保守しやすく、変化する要件に適応できるようにするための最良の構造はどれですか?

大規模なオブジェクト指向の命令型プログラムに関するこれらの質問に対処する非常に多くの文献があります。MVC、デザ​​インパターンなどのアイデアは、関心の分離やオブジェクト指向スタイルでの再利用性などの幅広い目標を実現するための適切な処方箋です。さらに、新しい命令型言語は、「成長するにつれて設計する」スタイルのリファクタリングに役立ちます。私の初心者の意見では、Haskellはあまり適していません。

Haskellに相当する文献はありますか?関数型プログラミング(モナド、矢印、アプリケーションなど)で利用できるエキゾチックな制御構造の動物園は、この目的にどのように最適に使用されますか?どのようなベストプラクティスをお勧めしますか?

ありがとう!

編集(これはドン・スチュワートの答えのフォローアップです):

@donsは次のように述べています。「モナドは主要な建築設計をタイプで捉えています。」

私の質問は、純粋な関数型言語での主要な建築設計についてどのように考えるべきかということだと思います。

いくつかのデータストリームといくつかの処理ステップの例を考えてみましょう。データストリームのモジュラーパーサーを一連のデータ構造に記述でき、各処理ステップを純粋関数として実装できます。1つのデータに必要な処理ステップは、その値と他のデータによって異なります。一部の手順の後には、GUIの更新やデータベースクエリなどの副作用が続く必要があります。

データと解析ステップを適切に結び付ける「正しい」方法は何ですか?さまざまなデータ型に対して正しいことを行う大きな関数を書くことができます。または、モナドを使用してこれまでに処理されたものを追跡し、各処理ステップでモナドの状態から次に必要なものを取得することもできます。または、大部分が別々のプログラムを作成してメッセージを送信することもできます(このオプションはあまり好きではありません)。

彼がリンクしたスライドには、「デザインをタイプ/関数/クラス/モナドにマッピングするためのイディオム」という箇条書きがあります。イディオムは何ですか?:)

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

symfony - Symfony-2.0 と大規模プロジェクトに関する必携の本はありますか?

Symfony フレームワーク、特にバージョン 2.0 のガイドブックを探しています。私は、より高度なガイド、特に symfony から最大のパフォーマンスを「引き出す」方法、控えめな (しかし多数の) 要求でさえ重要な中規模から大規模なプロジェクトの最適化に興味があります。

良い参考文献は大歓迎です (私は本の方が好きですが)。

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

database-design - ファイルの読み取り/解析のためのスケーラブルなシステム アーキテクチャ/設計

背景:私は、数百万以上のファイルを読み取り、それらのファイルを変換または解析するソフトウェア アプリケーションを設計しています。要件の一部は、スケーラブルな分散システムを構築して、それに応じて読み取りと解析をスケーリングできるようにすることです。

基本的に、ファイル名の最小限の詳細なリストは 1 つの DB であり、クライアントはリストにアクセスして、次にどのファイルを解析/変換する必要があるかを知る必要があります。ファイルは再び別のサーバー/場所にあります。ほとんどの部分は設計されていますが、再検討が必要な重要な部分の 1 つは、さまざまなクライアントにファイル名を提供する設計です。

現在、次の 2 つのオプションがあります。

  1. DB の隣に位置し、すべての要求をファイル名にチャネル化し、クライアントに供給する単一のサービスを設計します。したがって、この場合、クライアントはサービス (事前定義されたプロトコル/フォーマット) と対話し、リストを取得します。

  2. DB と直接対話し、クライアント内で同期/チャネライゼーションを実装するようにクライアントを設計します。

最初のオプションに関する私の唯一の懸念は、それはスケーラブルなアーキテクチャ/設計ですか? スケーラブルなアーキテクチャで、スケーリングで1つのリソースが重要になるような状況に対処した人はいますか(私の場合、すべてのクライアントに供給/サービスを提供する1つのサービスである可能性があります)

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

r - R と Cytoscape を使用した大規模なソーシャル ネットワークの視覚化におけるメモリの問題

私はRに比較的慣れておらず、次の問題を解決しようとしています:

私は R の 32 ビット バージョンを搭載した Windows 7 Enterprise プラットフォームで作業しており、マシンには約 3GB の RAM があります。現在、SQL データベースに格納されている大規模なソーシャル ネットワーク データ (約 7,000 の頂点と約 30,000 のエッジ) があります。このデータ (頂点とエッジの属性を省略) を R データフレームにプルし、次に igraph オブジェクトにプルすることができました。さらなる分析と視覚化のために、RCytoscape を使用してこの igraph を Cytoscape にプッシュしたいと思います。RCytoscape はこのオブジェクト タイプでうまく機能するように見えるので、現在、私のアプローチは igraph オブジェクトを graphNEL オブジェクトに変換することです。(igraph プロット関数は非常に遅く、それ以上の分析機能がありません。)

残念ながら、このスクリプトを実行すると、常にメモリの問題が発生します。ただし、以前は小規模なネットワークで機能していました。

この問題を解決する方法を知っている人はいますか? または、R とうまく連携し、そのような大規模なデータを処理できる他の視覚化および分析ツールをお勧めできますか?

どんな助けでも大歓迎です。よろしくお願いします!

ベスト、イグナシオ

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

algorithm - N ^ 2要素の中央値を見つける(大規模)

質問は次のようになります。N台のマシンがあり、各マシンがN個の要素を格納して操作できると仮定すると、すべてのN^2要素の中央値を最低のコストで見つけるにはどうすればよいでしょうか。

それは本当に私をとても悩ませます、皆さんからの答えを得ることを望んでいます、ありがとう!

申し訳ありませんが、単純すぎて書き留めておきます。各マシンに格納されている要素はランダムであり、順序はありません。また、コストにはI / Oコストだけでなく、マシン間の通信、RAM、時間もすべて考慮する必要があります。中央値を取得するための最も効率的な方法を見つけたいだけです。

これらは私が思いついたいくつかの解決策です:

  1. マージソートなどの外部ソートを使用して、中央値を見つけます。
  2. バケットソートを使用し、すべての要素をその値に従ってX個の連続するバケットに分割します。これにより、中央値がどのバケットにあるかを判断できます。バケットをスキャンすると、中央値が取得されます。
  3. 「アルゴリズム入門」のO(N)アルゴリズムでk番目の数を見つけることはここでうまくいくはずだと思いますか?

しかし、それでも、これらのソリューションはすべて、その仕事をするために追加のマシンを必要とします。これらのN台のマシンだけを使用して中央値を取得できる方法があるかどうか疑問に思っていますか?

ありがとう!

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

mysql - 別のテーブルのオプション フィールドに対するクエリの最適化

1 つの e コマース サイトを強化する itemsという名前の innodb テーブルがあります。検索システムを使用すると、オプション/追加フィールドを検索できるため、たとえば、修理されたコンピューターのみを検索したり、2000 年より古い車のみを検索したりできます。

これは、items_fieldsという追加のテーブルを介して行われます。非常にシンプルなデザインです。

フィールド名とタイプのみを含むフィールドと呼ばれるテーブルもあります。

検索結果を返す主なクエリは次のとおりです。

大規模 (1 日あたり 400 万以上の検索クエリのみ) では、これらの高度な検索をさらに最適化する必要があります。現在、平均的な高度な検索クエリには約 100 ミリ秒かかります。

このクエリを高速化するにはどうすればよいですか? 他に最適化のための提案やアドバイスはありますか? 両方のテーブルはinnodbで、サーバースタックは絶対に素晴らしいですが、それでもこのクエリを解決する必要があります:)

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

python - 大規模なPython竜巻プロジェクトに最適な構造は何ですか?

トルネードをコアとしてmongodbデータベースバックエンドを使用しています。私は現在、たくさんのハンドラーを含むメインファイルを持っています。これは、ユーザー間のリンクを備えたマルチユーザーWebアプリであり、別名「フレンド」システムです。

ほとんどのハンドラーはアクションファイルに対応しています。たとえば、フレンドリクエストハンドラーは、データベースとユーザーIDをパラメーターとして受け入れるuser_actions.pyの関数に対応します。これは、このような大規模なプロジェクトに最適なレイアウトではないように感じます。現在のユーザーのモデルを含むある種のモデルファイルがあるべきですか、それともこれは単に過剰ですか。現在、現在のユーザーを辞書としてCookieに保存しています。

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

javascript - 大規模な共有コードベース、機能の拡張

私たちのアプリケーションは、JavascriptMVCフレームワークを使用した大規模なJavascriptアプリケーションです。SVN:externalを介してすべてのサイトでMVCアプリフォルダーを使用しており、各サイトにも独自のファイルがあります。設定ファイルはサイトに固有です。

システムには、サイトごとに異なる機能を持つ機能が必要です。コア機能は同じままである必要があります。現在および新規の開発者向けの保守可能なソリューションを維持しながら、コアコードを拡張する必要があります。

現在、私たちが考えているオプションは次のとおりです。

a:コア内に機能条件を埋め込み、設定ファイルを介して機能のオン/オフを切り替えます

b:既存のコントローラーをオーバーライド/継承します

c:コア内に無制限のフックを備えたモジュラーシステム(プラグイン)を実装し、settings.jsonを介してロード/有効化されるプラグインを構成します

オプションaは、長期間維持するのが難しいという問題があり、かなりハッキーです。

オプションbはすでに実装されていますが、維持するのは困難です(新しい機能があるかのように、上書きされた場合は各サイトのファイルを編集する必要があります

オプションcは、(共有(プラグイン)コントローラーを使用し、サイト固有の設定ファイルを編集することにより、修正を分離することを最近考えたソリューションです。

知っておくとよいのは、私たちがすでに考えているオプションのいずれかを経験したことがあるかどうか、そして誰かがより適切な別のオプションを知っているかどうかです。