株式市場アプリケーション用のデータベース(MySqlまたはNoSQL)

I'm re-creating an app for Stockmarket Screening & Realtime charting Display.

私が設計することを提案しているデータベースのワイヤフレームは以下の通りです:

1. Company master - Where all the information of the company is given: Vendor Code|Company Full Name|Company Short name|Industry Code|Industry Full Name|Promoter Group Code|Promoter Group|EXCHANGE1 CODE|STOCK CATEGORY|EXCHANGE2 CODE|TYPE|ISIN CODE|STOCK TYPE

2. ) Intraday Data - Where every minutes the price of a stock is Stored: (This would be overwritten the next trading day) EXCHANGE1 CODE | OPEN PRICE | LAST PRICE | DAYHIGH | DAYLOW | Offer Price | Offer Qty | VOLUME |VALUE |Date & Time Stamp

3. Historical Data (Day wise): EXCHANGE1 CODE | OPEN PRICE | CLOSE PRICE | DAYHIGH | DAYLOW | VOLUME | Date

4. Fundamental Data (Not Yet given full thought): This would store all fundamental data like last 4 qtrly reports, Competitors, Balance sheets, Financial Ratios, P&L Statement, Promoter Details etc..

典型的なクエリは次のようになります。

Stock Quote Page: Time Series Price Charts with user selection, Intraday, 1 week, 1 month, 6months, 1 year, 5 years

Fundamental Data presented in chart form (i.e growth in profits, growth in sales) plus Other fundamental Data & News

Stock Screening : (Example Queries)

  • 売上高を20%伸ばした企業の在庫を表示します 過去3年間の年数

  • PEが10未満の企業を表示します

  • 過去5年間にqtrly利益が年間15%増加した会社を表示します。

  • 過去100日間の平均価格が現在の価格よりも低い自動車部門の企業を表示します。
  • 50日、100日、200日の単純な移動平均を表示する

Right now i'm at a stage wherein i've to decide which database to use MySQL or MongoDB (NoSQL Document) or Cassandra (NoSQL Column). So in the above case which database should i use? and why? (Advantages/Disadvantages) I want fast execution, data integrity, high concurrency, data aggregation & calculations (Analysis).

Plus we have to account that the data tables are being updates every minute and also serving visitor requests from the same DB simultaneously. So consistent & error free read/write is also of importance.

私のDBワイヤフレーム上のコメント/評論も歓迎します。

よろしく サニー

5
あなたの質問は次のようなものです:「私はハンマーかスクリュードライバーを使うべきですか?スクリューと釘で作業する必要がありますか?さまざまなニーズ、さまざまなツール...
追加された 著者 Malcolm Dezign,
couchdbを見てください
追加された 著者 Mirco A. Mannucci,
ちょっと晴れて、これを間違った方法でやってはいけませんが、DBAの経験はありますか?あなたの質問にあるコメントから、私はあなたがそうでないことをほぼ確実に推測することができます。そのため、最初の設計作業を行うには、専門家、または少なくとも実践的な経験を持つ人を雇うことをお勧めします。最初のデザインを正しいものにすることは金の重さに値するものです。
追加された 著者 Hoolio,
こんにちはエリック、あなたは絶対に正しいです、私はDBAについての悩みはありません。実際には開発者を雇っています。上記の質問を投稿する理由は、調査された決定に到達することでした。私たちの開発者は、当初、高速なクエリ/応答の理由から、NoSQLへの移行を提案していました。しかし、このスレッドに関するコメントのおかげで、相互に合意したMySQLの決定に至りました。それは論理的な決定だったと思います。
追加された 著者 numerical-solution,

2 答え

さまざまなデータに対して異なるデータベースが必要になります。たとえば、会社のマスタ、履歴データ、基本データはすべて標準のSQLデータベースに格納されている可能性があります(MySQLまたはPostgresの両方が合理的な選択肢です)。

日中のデータが比較的低い頻度(例えば、1分のバー以下)である場合、それはおそらくSQL DBにも入れられる可能性がある。それが非常に大きい場合(例えば、複数の取引所からのティックごとのデータ)、SQLは大きな選択肢ではないかもしれない。その場合、HDF5ファイルやカスタムファイル形式など、どのような種類のクエリーを実行するかによって異なります。

データが非常に大きくなる場合は、実行するクエリの種類を正確に考え、データ構造(バックエンド、ファイル形式、列レイアウトなど)をクエリに合わせて最適化することが重要です。

3
追加された
こんにちはThomasさんは入力を感謝します。私たちは過去5日間のみ記憶している昼間(1分の頻度)、残りのデータは15年間のEODです(OHLCV + AdjVal)。標準的な繰り返しクエリでは、私たちはデータを提供するためにRAMを使用することです(一定間隔でメモリをあらかじめ準備しておいてください)。これは論理的ですが、技術的な落とし穴はまだ分かりません。
追加された 著者 numerical-solution,

一般に、SQLデータベースは、構造化データ、非定型問合せ、および複数のエンティティを結合して結果を検索する問合せに最適です。この構造化された設計を強制することによって、データの一貫性と整合性を維持するのにも役立ちます。最近のデータベースエンジンのメモリ内機能は、NoSQLの残りのパフォーマンス上の利点の大部分を提供します。

データベースの基本部分が非構造化データ(添付ファイルなど)で構成されている場合は、NoSQLを選択することをお勧めします。しかし、ファイル名の参照を持つSQLテーブルはほぼ同じように機能します。

あなたのプロジェクトのための私の推薦はPostgreSQLですが、もしそれが上記のMySQLの一つでなければならないならば。

2
追加された
あなたのお勧めにFinnに感謝します。私たちは、開発者が過去のMySQL経験を持っていたので、MySQLに行ってきました。
追加された 著者 numerical-solution,