タグ付けされた質問 「nosql」

nosql DBMSの大きな利点の1つは、より簡単にクラスタリングできることです。NoSQLを使用すると、さまざまなデータを格納する数百台の安価なマシンを作成して、一度にクエリを実行できます。 私の質問はこれです、なぜリレーショナルDBMSはmysqlやsqlサーバーのようにこれを行うことができないのですか？ベンダーが既存の製品でこれを行うための技術的な方法を理解していないだけなのか、それとも実現できないようにするリレーショナルモデルの問題がありますか？データ（キー/値、ドキュメントなど）を保存およびアクセスするNoSQLの方法で、これが本当に正しい場合、クラスタリングを容易にするのは何が素晴らしいですか？

88 clustering  nosql  scalability  relational-theory 

私たちは、膨大な量を収集するnetflowデータをキャプチャして分析するツールの開発を検討しています。毎日約14億のフローレコードをキャプチャします。これは、json形式では次のようになります。 { "tcp_flags": "0", "src_as": "54321", "nexthop": "1.2.3.4", "unix_secs": "1352234521", "src_mask": "23", "tos": "0", "prot": "6", "input": "105", "doctets": "186", "engine_type": "0", "exaddr": "2.3.4.5", "engine_id": "2", "srcaddr": "9.8.7.6", "dst_as": "12345", "unix_nsecs": "752265174", "sysuptime": "2943529544", "dst_mask": "24", "dstport": "80", "last": "2943523241", "srcport": "52672", "dpkts": "4", "output": "111", "dstaddr": "6.5.4.3", "first": "2943517993" …

75 sql-server  mongodb  nosql  rdbms  cassandra 

大量の電気データと温度データを保存および分析する必要があるアプリケーションを作成しています。 基本的には、過去数年間および数万の場所について今後数年間にわたって大量の時間ごとの電力使用量の測定値を保存し、それほど複雑ではない方法でデータを分析する必要があります。 （今のところ）保存する必要がある情報は、ロケーションID、タイムスタンプ（日付と時刻）、温度と電気使用量です。 格納する必要があるデータの量については、これは概算ですが、これらの行に沿ったもの： 20 000以上の場所、1か月あたり720レコード（1時間あたりの測定、1か月あたり約720時間）、120か月（10年前） ）そして何年も先。簡単な計算により、次の結果が得られます。 20の000の位置は、720のレコード（10年前）×120ヶ月= X 1つの728 000 000レコード。 これらは過去のレコードです。新しいレコードは毎月インポートされるため、1か月あたり約20 000 x 720 = 14 400 000の新しいレコードになります。 合計ロケーションも着実に成長します。 そのすべてのデータで、次の操作を実行する必要があります。 特定の日付および期間のデータを取得します。日付01.01.2013から01.01.2017の間、および07:00から13:00の間の特定のロケーションIDのすべてのレコード。 特定の日付と時間範囲に対する簡単な数学演算、たとえば、07：00から13:00までの5年間の特定のロケーションIDのMIN、MAX、およびAVG温度と電力使用量。 データは毎月書き込まれますが、何百ものユーザーによって（少なくとも）常に読み取られるため、読み取り速度は非常に重要です。 NoSQLデータベースの経験はありませんが、私が収集したものから、ここで使用するのに最適なソリューションです。最も人気のあるNoSQLデータベースについて読んだことがありますが、それらは非常に異なっており、非常に異なるテーブルアーキテクチャを可能にするため、使用するのに最適なデータベースを決定することができませんでした。 主な選択肢はCassandraとMongoDBでしたが、私は非常に限られた知識しかなく、大きなデータとNoSQLに関しては実際の経験がないため、あまり確信がありません。また、PostreSQLはそのような量のデータを適切に処理することも読みました。 私の質問は次のとおりです。 このような大量のデータにNoSQLデータベースを使用する必要があります。そうでなければ、MySQLに固執できますか？ どのデータベースを使用すればよいですか？ 特定の期間のデータをすばやく取得および処理するために、日付と時刻を別々のインデックス付き（可能な場合）列に保持する必要がありますか、またはタイムスタンプを単一の列に保持することでこれを実行できますか？ ここで時系列データモデリングアプローチは適切ですか？そうでない場合は、適切なテーブル設計のためのポインターを教えてもらえますか？ ありがとうございました。

74 database-design  database-recommendation  nosql 

NoSQLと従来のRDBMSの違いは何ですか？ 過去数か月間、NoSQLは技術ニュースで頻繁に取り上げられてきました。従来のRDBMSと比較して最も重要な機能は何ですか？差異はどのレベル（物理的、論理的）で発生しますか？ NoSQLを使用するのに最適な場所はどこですか？どうして？

71 nosql  rdbms  database-recommendation 

NoSQLのウィキペディアのページを見て、キー/値ストアデータベースのバリエーションをいくつかリストしていますが、このコンテキストでのキー/値ストアの意味についての詳細は見つかりません。誰かが私に説明をしたり、説明をリンクしたりできますか？また、このようなデータベースはいつ使用しますか？

56 nosql 

SQLとNoSQLの一般的な違い（または従来の違い）は気にしません。 現在、内部時系列のストレージの変更を検討しています。これらにはすべて、さまざまなソースからの財務データが含まれています。現在、独自のデータベースにデータを保存しています。独自のクエリ言語を持つのは、まさにNoSQLです。 コミュニティからのインプットに興味があります。SQLデータベースにデータをどのように保存しますか？NoSQLを介してSQLを使用すること、特に時系列のメリットは何ですか？これをSQLに保存することを検討するのは正気ですか？ データセットは数百万の時系列で構成され、これらの約10％にはそれぞれ数百万のレコードが含まれています。時系列は階層的に整理されます：/ Market / Instrument / Value / Frequency、ここで： 市場は証券取引所などであり、基本的には商品の集まりであり、通常は同様の商品です。 楽器は楽器です。これはインジケーター（ブレント原油）、エクイティ（GOOG）などです。 値は、楽器の複数の種類のデータの1つです。これは、近い、高い、低いなどです 頻度は、特定の時系列値の頻度です。毎週、毎日、毎月、ティック、任意など データはどのようにSQL dbに保存されますか？1つの大きなテーブル（何かで分割されている場合があります）、市場または銘柄ごとに1つのテーブル、時系列ごとに1つのテーブル。 前もって感謝します。

33 nosql 

データベースのコンテキストでは、NOSQLデータベースの利点の1つとして、水平方向の拡張性に出会いました。この用語はどういう意味ですか？ ウィキペディアのCouchDB ウィキペディアのNoSQL 垂直スケーリングと比較してどうですか？

23 nosql  terminology  couchdb  scalability 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 ドキュメント指向ストレージの評価、CouchDBとMongoDBの長所と短所は何ですか？

18 nosql  document-oriented  mongodb  couchdb 

環境 この質問は、SQLデータベースシステムとNoSQLデータベースシステムの両方でのインデックスの低レベルの実装の詳細に関するものです。質問はこれらの実装の単一ノード内に保存されたキーに特に関係するため、インデックスの実際の構造（B +ツリー、ハッシュ、SSTableなど）は無関係です。 バックグラウンド SQL（MySQLなど）およびNoSQL（CouchDB、MongoDBなど）データベースでは、データの列またはJSONドキュメントフィールドにインデックスを作成するときに、実際にデータベースに実行させるのは、本質的にすべてのソート済みリストを作成することですこれらの値と、その値に関連するレコードが存在するメインデータファイルへのファイルオフセット。 （簡単にするために、特定の実装のその他の難解な詳細を手で振り払うかもしれません） シンプルなクラシックSQLの例 インデックスを作成する単純な32ビットint主キーを持つ標準SQLテーブルを考えます。データファイルへの64ビットオフセットに関連付けられ、関連付けられた整数キーのディスク上のインデックスが作成されます。レコードは存続します。例： id | offset -------------- 1 | 1375 2 | 1413 3 | 1786 インデックス内のキーのディスク上の表現は、次のようになります。 [4-bytes][8-bytes] --> 12 bytes for each indexed value ファイルシステムとデータベースシステムでのディスクI / Oの最適化に関する標準的な経験則に固執して、ディスク上の4KBブロックにキーを保存するとします。 4096 bytes / 12 bytes per key = 341 keys per block インデックスの全体構造（B +ツリー、ハッシュ、ソート済みリストなど）を無視して、341キーのブロックを一度に読み書きし、必要に応じてディスクに戻します。 クエリの例 前のセクションの情報を使用して、「id = …

16 mongodb  index  nosql  couchdb 

私はNoSQLテクノロジーにますます興味を持ち始めており、SEのしくみと利用可能なさまざまな製品に関するSEに関するいくつかの投稿を読むことができます。 しかし、たとえば、研究論文に掲載でき、以下の概要を把握するために読むことができる標準的な参考文献、書籍、記事があるのではないかと思います。 メリット/デメリットは何ですか？ 使い方？

15 nosql 

私は、小規模企業の顧客向けのWebベースのClojureアプリケーションとして、VBベースのオンプレミス（ローカルにインストールされた）アプリケーション（請求書+在庫）を書き換えることを検討しています。これは、同様の取引の顧客向けのSaaSアプリケーションとして提供される予定です。 私はデータベースオプションを見ていました：私の選択はRDBMS：Postgresql / MySQLでした。最初の1年間で最大400人のユーザーにスケールする可能性があります。通常、ユーザーあたり1日あたり20〜40ページビューです。ほとんどの場合、静的ビューではないトランザクションに使用します。各ビューには、データの取得とデータの更新が含まれます。ACIDコンプライアンスが必要です（またはそう思う）。そのため、トランザクション量は膨大ではありません。 私の好みに基づいてこれらのいずれかを選択するのは簡単でしたが、この1つの要件のために、SaaSアプリの典型であると信じています：スキーマは、顧客/ユーザーを追加し、各顧客のビジネス要件の変更（最初に限って柔軟性を制限します）。私はDBの専門家ではないので、私が考えることができ、読んだことに基づいて、多くの方法でそれを処理できます。 複数のテナントをホストする単一のDBを使用して、MySQl / Postgresqlで従来のRDBMSスキーマを設計します。さらに、顧客を追加したり、既存の顧客に変更を加えたりするときに、将来の変更に対応できるように、各テーブルに十分な「浮動」列を追加します。これには、スキーマに小さな変更が加えられるたびにDBに変更が伝播されるという欠点があります。Postgresqlのスキーマ更新では、ロックなしでリアルタイムに更新できることを読んだことを覚えています。しかし、このユースケースでどれだけ苦痛であるか、どれほど実用的かはわかりません。また、スキーマの変更により、新しい/小さなSQL変更も導入される可能性があるためです。 RDBMSを使用しますが、データベーススキーマを柔軟な方法で設計します。エンティティ属性値に近い値を使用するか、単にキー値ストアとして使用します。（就業日、たとえばFriendFeed） オブジェクト全体をメモリ内にオブジェクトとして保持し、定期的にログファイルに保存します（edval、lmaxなど）。 MongoDBやRedisなどのNoSQL DBを探してください。しかし、私が収集できるものに基づいて、これらはこのユースケースに適さず、ACIDに完全に準拠していません。 SQLおよびACID準拠の動作を保持し、「新世代」のRDBMSであるVoltDbやJustoneDb（クラウドベース）などのNewSQL Dbsを探します。 neo4j（graphdb）を見ましたが、それがこのユースケースに適合するかどうかはわかりません スケーラビリティや分散コンピューティング以上のユースケースでは、「スキーマ+ ACIDの柔軟性+合理的なパフォーマンス」を実現するためのより良い方法を探しています。ネット上のほとんどの記事では、ACID / Transactions側を除外しつつ、パフォーマンス（NoSQL DBの場合）とスケーラビリティにつながる原因としてのスキーマの柔軟性について述べています。 これは、「スキーマの柔軟性とACID」トランザクションの「どちらか」のケースですか、それともより良い方法がありますか？

15 database-design  schema  nosql 

Neo4jでは、ノードごとに大量のデータを保存する必要があります。データはテキストのUnicodeチャンクです。実際、すべてのノードに大きなチャンクがあるわけではありませんが、それらの多くには大きなチャンクがあります。 ドキュメントを探しましたが、ノードサイズ（単一ノードに含めることができるデータの量）に関する言及は見つかりませんでした。 誰にもアイデアはありますか？

14 nosql  neo4j 

NoSQLデータベースにデータを記録し、それをRDBMSに変換するための優れたソリューションがあるかどうか疑問に思っていましたか？ たとえば、セッションログなどの一部のデータをすばやくキャプチャしたいが、それらのレポートを後で作成できるようにする場合です。 私のお気に入りのデータベースはPostgresなので、もしあなたの答えがPostgresに関連しているなら素晴らしいでしょう。

13 nosql  rdbms 

夏に始めたい新しいプロジェクトのために、さまざまなデータベースタイプとDBMSを検討しています。 MySQLとpostgreSQLでシステムを構築しましたが、今ではデータベースに関する知識と経験を広げたいと思っています。 私のプロジェクトは一種のソーシャルネットワーク/知識の集合体です。（まだそれを説明する用語を開発していない）。 私が見てきた： Cassandra（独自の種類のクエリ言語を使用）; 機能が豊富なコンテンツと高性能なクエリ実行を実現するのに適しているようです。ただし、Java環境を使用する必要があるため、あまり熱心ではありません。Oracleとは何の関係もありません。 MongoDB（noSQLタイプのDBMS）; 優れたスケーラビリティ。ただし、ビジネス情報クエリなどの実績のあるSQL言語で既に利用可能なすべての機能を失います。 システムの要件： データテキスト、日付、時刻、xml、小さな整数、ブロブ、 構造/動作：正規化された3NF、非リアルタイム、リレーショナル、スケーラブル、堅牢 環境： unix / linux、JAVAなし、できればCで実行 私が研究すべき他のデータベースシステムを教えてくれないかと思っていました。 Object Relational Databasesも見てきましたが、PHPオブジェクト（PDO）で動作するというアイデアはとても気に入っていますが、パフォーマンスは少し悪いようです。 ここにDBAがいるので、あなたが操作したこれらのシステムに関するフィードバックをいただければ幸いです。 ありがとう

12 performance  database-recommendation  nosql  scalability 

たとえば、それぞれ300億行（合計サイズ4TB）の3つの巨大なテーブル（構造化データ）があり、多数の同時ユーザー（リモートLANマシンの並列osスレッド）が一部を読み取る必要があることを想像してくださいSELELCT WHERE GROUPBYクエリと非常に同時、たとえば10,000同時読み取りによるデータと、ユーザーがこれらのテーブルにデータを挿入する必要があります（更新なし）2000同時書き込み（データセンターLANネットワーク全体） 。ユーザーは、このストレージから可能な限り高速で読み取りと挿入を行い、各読み取りと書き込みが行われる場所はms〜1秒の範囲です。 そのような要件を満たすために、どのテクノロジーをお勧めしますか？これを実行できるデータストレージまたはキーバリューストアはありますか？クラウドはオプションではありません。 いくつかの明確化： ユーザーはデータをすぐに見る必要はなく、最終的な一貫性は許容されます。データはストレージが提供できるドライバーを介してアクセスされ、ユーザーは再びデータセンターのリモートマシンで実行される単なるスレッドになります。クエリは、主にSELECT WHERE GROUPBYに似ています。 データは表形式で、各行は約60バイトです。 DynamoDBまたは同様のソリューションを使用できないクラウドオプションはありません。データセンターで内部的にホストできる必要があります。 テーブルのすべてのデータを常に読み取ることができ、使用パターンは予測できません。結合または超長いクエリはありません。DRは必要ありませんが、合理的なHAは必要ですが、空想である必要はありません。すべての読者は、where句に基づいて行のバッチを取得しており、行は実際には関連していません。各行の長さを固定することもできますが、ストレージレイヤーが心配することを期待しています。 また、私の最大の懸念は、同時読み取りで発生するすべての同時書き込みです。 これに対するあなたの洞察は非常に高く評価されています。 さらに、これらのテーブルのうち3つにそれぞれ300億行の異なるオブジェクトタイプがあります

12 architecture  concurrency  nosql  storage