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

CAP定理（整合性、可用性、パーティション：2つを選択）を持たない限り、いわゆる "NoSQL"データベースについて話すことはできません。MongoDB（Partition、Consistency）とCouchDB（Availability、Partition）の間で言う必要がある場合、最初に考える必要があるのは「正しいデータが必要ですか、それとも常時アクセスする必要がありますか？」です。 これらの新しいデータベースは、パーティション分割されるように作成されました。しかし、私がそうしないとどうなりますか？リレーショナルデータベースではなく、キー/値、列、ドキュメントなどのデータベースを持ち、サーバーインスタンスを1つだけ作成し、決してシャードしないのが非常にクールだと思ったらどうでしょうか。その場合、可用性と一貫性の両方はありませんか？MongoDBは何も複製する必要がないため、利用可能になります。また、CouchDBにはデータのソースが1つしかないため、かなり一貫性があります。 それで、その場合、MongoDBとCouchDBはユースケースの用語にほとんど違いがないことを意味しますか？もちろん、パフォーマンス、API、およびその他は除きますが、基本的に異なる2つの要件セットを持つよりも、PostgreSQLとMySQLを選択することに似ています。 私はここにいますか？複数のインスタンスを作成しないことで、APまたはCPデータベースをACデータベースに変更できますか？それとも私が行方不明になっているものがありますか？ 逆に質問してみましょう。リレーショナルデータベースを使用し、MySQLを使用して、それをマスター/スレーブ構成にするとどうなりますか。ACIDトランザクションを使用しません書き込みをすぐにスレーブに同期する必要がある場合、それをCPデータベースにしませんか？そして、事前に定義された間隔で同期するとどうなりますか。クライアントがスレーブから古いデータを読み取っても問題はありません。それがAPデータベースになりませんか？これは、ACIDコンプライアンスを放棄しても、パーティション分割されたデータベースにリレーショナルモデルを使用できるという意味ではないでしょうか。 本質的には、基になるデータモデルよりも、CAP定理で放棄する準備ができているものについてのスケーラビリティですか？列、ドキュメント、キーバリューなど、リレーショナルモデルよりもスケーラビリティを高めるものはありますか？パーティショントレランスのためにゼロから設計されたリレーショナルデータベースを設計できますか？（たぶんそれはすでに存在します）。NoSQLデータベースをACIDに準拠させることはできますか？ 申し訳ありませんが、多くの質問がありますが、最近NoSQLデータベースについて多くのことを読みました。それらを使用することの最大の利点は、パーティションCAPだけでなく、データの「形状」により良くフィットすることですACIDコンプライアンスを放棄します。結局のところ、誰もがデータを分割するのに必要なほど多くのデータを持っているわけではありません。データのパーティション分割について考える前に、リレーショナルモデルを使用しないことでパフォーマンス/スケーラビリティの利点がありますか？

13 database-design  nosql  scalability 

NoSQL対SQLデータベースに関する議論で、スキーマを新しいバージョンに移行するのは問題があるため、企業はスキーマレスのNoSQLデータベースを使用することを好むと聞きます。しかし、アップグレードを行うとき、それは本当に大きな問題ですか？リレーショナルデータベースは、このような操作に悪いですか？ MongoDBブログの次のブログ投稿を読んでください。なぜSchemalessなのですか？

13 database  nosql  relational-database  schema 

スキーマ設計を適切に文書化したいMongoDBデータベースがあります。MongoDBはNoSQLデータベースであり、本質的にスキーマレスであることを知っていますが、アプリケーションを通じてスキーマを強制し、findOne()結果の印刷よりも優れた方法でスキーマを表現したいと考えています。 私は多くの人がERまたはUMLを使用しているのを見ていますが、私のNoSQLデータベースをリレーショナルDBとして表すのは概念的に正しいとは思えません。少なくとも、奇妙に見えます。 UMLを使用した例：MongoDB：論文でスキーマ図を表す方法は？ 人々は異なるモデルを使用していると思いました。私が検索したところ、スキーマを理解するための素晴らしいTreeビューを提供するMongoVUEがありましたが、プリンターには適していません。 NoSQLの世界で他に見逃しているものはありますか？または、私は休んで伝統的なUMLに固執するべきですか？

13 documentation  uml  nosql  mongodb  diagrams 

私は比較的大学を卒業していないので、リレーショナルデータベースに関する私の知識のほとんどは、BCNFまたは3NFにないものはすべてわいせつである私のデータベースコースからのものです。確かにそれは極端なことの一端ですが、仕事中の私のチームは本当にそれを完全に反対側に持っているようです。 マイクロサービスdbスキーマでは、エンティティが複数のテーブルを持つことはめったにありません。通常、別のテーブルに正規化するものはすべてjson列に格納されます。このjsonのプロパティの1つをクエリする必要があることが後で発見された場合、新しい列が追加され、データは両方の場所（はい、同じテーブルの2つの異なる列）に保存されます。 多くの場合、これらのjson列には間違いなく利点があります。そのデータを照会する必要がなく、そのデータに一方的な変更を加える必要がない場合（これは明らかに予測できないことです）、それは悪い考えではありません。さらに、当社のサービスの多くは、サーバーを認識しないか、必要なディスク容量のわいせつなマシンでホストされているため、データの重複は大きな問題ではありません。（私が一般的に哲学から避けたいことですが） 現在、所有する一連の条件に基づいてルールに一致するサービスを構築し、ルールが真（たとえば、すべての条件が真）の場合にそれらのルールに関連付けられた一連のアクションを実行します。このサービスを最も迅速に構築している私のサブチームは、スキーマ内のルールから離れてアクションと条件を正規化することには大きなメリットがあると考えています。明らかに、これらのテーブルは、ルールIDとの外部キー関係を維持します。私たちの観点からは、条件でのデータの重複を避けることができ、一度だけ評価されることを保証できます。また、必要なときに必要な条件やルールを見つけやすく、すべてのルールを引き出してメモリ内で検索する必要がありません。 今日、私たちの主任技術者の一人と話して、彼は私をこのスキーマから遠ざけようとしました。私たちが実際にそれを必要としないとあらゆる方法で議論しようとすると、将来的にパフォーマンスの問題が発生し、所有する古いモノリスを参照します。彼は、私たちがやっていることを「古い方法」と呼び、jsonを含むフラットテーブルを「新しい方法」と呼びました。彼は、私が原子性を望む場所ではそれを必要とせず、クエリの代わりにメモリ内でより多くのことをすべきだと主張した。これは、現在当社のサービスの多くが従っている設計原則です。データの量が大幅に増加することは予想していませんが、これによりクエリを高速に保つことができます。予想されるのは、ルールの評価とアクションの実行に多くの時間を費やすことです。 非リレーショナルデータベースが近年人気を博していることは理解していますが、外部キー関係のパフォーマンスへの影響に関する情報を積極的に検索しても、彼の主張を裏付ける情報は多くありません。問題を引き起こす可能性のある大規模なトランザクションを導入する傾向があると思いますが、それは外部キー自体とは無関係の問題のようです。 これは私の素朴ですか？または、これは本当に私と私のサブチームに欠けているものがありますか？解決策を必ずしも探しているわけではないので、問題に関する詳細な情報を明示的に提供していません。それが私たちの大規模なチームで一般的な傾向であることを考えると、彼らがこれで何かに取り組んでいるかどうかは本当に興味があります。

12 database  relational-database  nosql 

nグラムのデータを保存することについて少しブレインストーミングしたいと思っていました。私のプロジェクトでは、すべての（n -1）データ項目を知っており、適用可能なすべてのnグラムに対する線形補間を使用して統計的にnを推測したい言語の問題を解決しようとしています。（はい、用語集に従ってタグを既知の単語に割り当てるタガーと、未知の単語の単語の種類を推測するサフィックスツリーがあります。ここで説明するnグラムコンポーネントは、曖昧さの解決を担当します。） 私の最初のアプローチは、観測されたすべてのnグラム（n = 1..3、つまりモノグラム、バイグラム、トライグラム）のデータをそれぞれのSQLデータベースに単純に格納し、それを1日と呼ぶことです。しかし、私のプロジェクトの要件は、他のベクトルの長さ（n）を含むように変更される可能性があり、多くの作業（スキーマの更新、アプリケーションコードの更新など）なしにアプリケーションを4グラムに適応させたいです。理想的には、コードを大幅に（またはまったく）変更せずに、4グラムで動作するようにアプリケーションに指示し、特定のデータソースからのデータをトレーニングするだけです。 すべての要件をまとめるには： nグラムのデータを保存する機能（最初はn = {1、2、3}の場合 使用するnグラムの種類を変更する機能（アプリケーションの実行間） nグラムデータを（再）トレーニングする機能（アプリケーションの実行間） データストアを照会する機能（たとえば、A、B、Cを観察した場合、トレーニング済みの4、3、2、1グラムのデータセットを使用して、最も頻繁に観察されるアイテムを知りたい） ほとんどの場合、アプリケーションは読み込みが重くなり、データセットはほとんどの場合再トレーニングされません このソリューションは、.NET Framework（最大4.0）を採用しています では、そのようなタスクに適した設計は何でしょうか？ 各nの SQLサーバー（MSSQL、MySQLなど）によって管理される固定テーブル（たとえば、2グラム、3グラムなどの専用テーブル） または、ドキュメントのキーとして最初のn -1 を保存し、ドキュメント自体にn番目の値と観測頻度が含まれるNoSQLドキュメントデータベースソリューションですか？ または何か違う？

12 .net  sql  database-design  nosql 

マルチユーザードキュメントシステムを非常に簡略化した単一ページのWebアプリケーションの開発を開始します。フロントエンドはおそらくAngular2を使用します。 プロジェクトには短い期限があるため、「ショートカット」、つまりすべてを最初から実装するのではなく、既成のさまざまなサービスを使用することを探していました。 アプリケーションデータを格納するために、なんらかのバックエンドが必要になります。私は周りを見回して、Firebaseを見つけました。Firebaseは、フロントエンドと通信するための個別のバックエンドとAPIを作成する作業の一部を取り除いているようです。 しかし、これはビジネスロジックをフロントエンドのAngular2 Webアプリに配置する必要があることを意味しますよね？ では、将来、モバイルアプリのフロントエンドを作成したい場合、ビジネスロジックコードを複製する必要がありますか？ ビジネスロジックを含み、データストレージにFirebaseを使用するバックエンドを作成するのが代替策だと思いますが、少し奇妙に思えます（バックエンドでORMまたは何かを直接使用して、もっと多くの仕事？） たとえばFirebaseを利用したい場合、人々は通常どのようにこれらの種類のアプリを構築しますか？

10 database  web-services  nosql  angular2 

データベースで非常に高い更新/選択クエリの実行を伴うアプリケーションに取り組んでいます。 ベーステーブル（A）があり、1日のエンティティに対して約500のレコードがあります。そして、システム内のすべてのユーザーについて、このエンティティのバリエーションがユーザーの設定の一部に基づいて作成され、それらは別のテーブル（B）に格納されます。これは、毎日午前0時に実行されるcronジョブによって実行されます。 したがって、テーブルAに10,000人のユーザーと500個のレコードがある場合、その日のテーブルBには500万のレコードがあります。私は常にこれらのテーブルに1日分のデータを保存し、真夜中に履歴データをHBaseにアーカイブします。この設定は正常に機能しており、今のところパフォーマンスの問題はありません。 最近、ビジネス要件にいくつかの変更があり、現在、ベーステーブルAの一部の属性（15〜20レコード）が20秒ごとに変更され、それに基づいて、テーブルBのすべてのバリエーションレコードのいくつかの値を再計算する必要があります。すべてのユーザー。変更するのは20のマスターレコードだけですが、20秒以上かかる200,000のユーザーレコードを再計算して更新する必要があるため、次の更新が行われると、最終的にすべてのSelectクエリがキューに入れられます。オンラインユーザーから約3 getリクエスト/ 5秒で6-9 Selectクエリが発生します。APIリクエストに応答するために、常にテーブルBのフィールドを使用します。 より多くの処理能力を購入してこの状況を解決できますが、100万人のユーザーでも処理できる適切にスケーリングされたシステムに興味があります。 ここの誰かがより良い代替案を提案できますか？nosql +リレーショナルデータベースはここで役立ちますか？ロックせずにデータを頻繁に更新でき、同時にエンティティのさまざまなフィールドで選択クエリを実行できる柔軟性を提供するプラットフォーム/データストアはありますか？

10 database-design  nosql 

メニュー/レシピ管理という趣味のプロジェクトに取り組んでいます。 これは私の実体とそれらの関係がどのように見えるかです。 AにNutrientはプロパティがCodeあり、Value のIngredientコレクションを持っていますNutrients A RecipeにはコレクションがIngredientsあり、時々他のコレクションを持つことができますrecipes Aは、Mealのコレクションを持っているRecipesし、Ingredients A MenuのコレクションがありますMeals 関係は次のように表すことができます いずれかのページで、選択したメニューについて、その構成要素（食事、レシピ、成分、および対応する栄養素）に基づいて計算された有効栄養素情報を表示する必要があります。 現在、SQL Serverを使用してデータを格納しています。メニューの各食事から始めて栄養素の値を集計して、C＃コードからチェーンを移動しています。 この計算はページがリクエストされ、構成要素が時々変更されるたびに行われるため、これは効率的な方法ではないと思います。 MenuNutrients（{MenuId, NutrientId, Value}）と呼ばれるテーブルを維持し、コンポーネント（食事、レシピ、成分）のいずれかが変更されたときに、このテーブルに有効な栄養素を追加/更新するバックグラウンドサービスがあることを考えていました。 GraphDBはこの要件に適していると思いますが、NoSQLへの私の露出は限られています。 特定のメニューの栄養素を表示するというこの要件に対する代替の解決策/アプローチは何ですか？ シナリオの説明が明確であることを願っています。

10 c#  sql  database-design  nosql  graph-databases 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 NoSQLデータベースについてもう少し学びたいので、サッカーの結果を処理するために新しいプロジェクトをゼロから作成することにしました。私の従来のリレーショナルデータベースには、トーナメント、チーム、結果、クラステーブルがあります。すべてが明らかに関連しています。 代わりにNoSQLアプローチを使用して、このようなプロジェクトを設計するための良いアプローチは何でしょうか？

10 database-design  nosql 

ここに私の質問があります：異なるタイプのNoSQLデータベースの弱点は何ですか？具体的には、キー値ストア、グラフデータストア、ドキュメントストアの弱点は何ですか？ 私は長所を見つけるのは簡単な時間でしたが、弱点に関するドキュメントは不足しているようです。 編集：相互に比較したり、リレーショナルデータベースと比較したりします。

10 database  database-design  nosql 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 6年前休業。 3つの主要な部分で構成されるWebアプリで構成される、Railsで最初の実際のプロジェクトを構築します。 データベースを使用しない静的部分 各ユーザーの行は同じフィールドを持つため、データベースを必要とし、MySQLを使用できるユーザー登録部分 ユーザーがコレクション内のアイテムを作成、整理、編集し、他のユーザーと共有できる「アプリ」 いくつかのアイテムタイプがあり、それぞれに異なるオプションがあります。たとえば、次のオプションを持つ「ビデオ」アイテムがあるとします。 id ユーザーID collection_id 題名 プラットフォーム（埋め込まれている場合） URL（埋め込まれている場合） ファイル名（アプリでホストされている場合） ファイルサイズ（アプリでホストされているID） 「マップ」アイテム： id ユーザーID collection_id 題名 プラットフォーム（Googleマップ、Bingマップ...） ロケーション url 地図のサイズ ユーザーがMySQLをアイテムに使用している間、各アイテムが別のアイテムとは異なるオプションを必要とする可能性があるため、MongoDBの柔軟性が役立つ場合があります。 これまで私は常にPHPとMySQLを使用してきました（常に小規模なプロジェクトでは共有ホスティングを使用しています）。スケーラビリティは私にとってまったく新しい言葉です。 学ぶ時間はありますが、1か月くらいで具体的なことができるようになりたいです。 私はMongoDBとNoSQLとRDMSとMySQLについてたくさん読んだので、それを試した後、MongoDBがどのように機能するかが好きだと言っておく必要があります。 私の状況では何をしますか？どうして？ スケーラビリティについて、MongoDBに問題がある可能性はありますか？はいの場合（DBサイズに関して）、これらの問題によりアプリが大幅に遅くなる可能性がありますか？ 編集：アプリの仕組み 多くの人がこれを私がアプリをどのように機能させたいかを尋ねたので： ユーザーがサインアップ 彼はログインしています 彼は無限のアイテムを作成できる彼の最初のコレクションisideを作成します アイテムにはさまざまなタイプがあり、タイプごとに異なるデータをデータベースに保存する必要があり、アイテムのタイプを追加または変更できます ユーザーはその中に他のコレクションやアイテムを作成できます。 そのため、コレクションとその内部のアイテムのCRUDがあり、各コレクション/アイテムは特定のユーザーに参照されます MySQLの主な問題は、柔軟なスキーマがないことです。これを解決する方法があります（回避策？）？ NoSQLについて考えるときの唯一の疑問は、結合に関するものです。たとえば、特定のコレクションがあり、コレクション内のID = user_idフィールドを持つユーザーに関連するデータを取得したい場合 編集：MySQLを使い続けるためのアイデア 「items」テーブルに、オプション設定を含むフィールドを作成します。各設定は|で区切られます。または別のシンボル。 次に、各アイテムのオプション設定の構造をどこかに保存します。たとえば、「ノート」アイテムタイプには、MySQLからデータを取得するときに、2つのオプション設定「color」と「strange_setting」が必要です。オプション設定のフィールドを配列の最初の項目が「色」用であることを認識する配列など。 どう思いますか？その解決策に問題がありますか？他にアイデアはありますか？

9 database  mysql  nosql  rdms  mongodb 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 私は、大学の学生シンポジウム向けに、ポリグロットの持続性のアイデアに関するアプリケーションを開発しています。Martin Fowlersの本を読んだり、さまざまな種類のNoSQLデータベースについてオンラインで他の調査を行ったりしました。さまざまなNoSQLデータベースのさまざまな使用例について知りたいのですが。 現在私はFowlerが指摘したものを持っています（他の研究は主にAPIに対して行われました）。 キー/値： セッションデータ ユーザープロファイル ショッピングカート 基本的に、簡単に生成および複製できる単一の一意のキーを持つもの 資料： イベントログ CMS /ブログ eコマース（トランザクションが完了した後） ウェブ分析 列ファミリー： イベントログ CMS /ブログ カウンター 使用期限切れ グラフ： 接続データ 位置情報サービス 推奨エンジン それでは、他にどのようなユースケースがありますか？より具体的には、リレーショナルモデルよりも優れている各タイプのNoSQL dbの使用例は何ですか？

8 nosql 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 NoSqlデータベースの背後にある概念を学習するための優れたリソースを探しています。 私が見つけたもののほとんどは特定のテクノロジー（MongoDb、CouchDBなど）に関連していますが、特定の領域（一部はグラフDB、一部のKey-Valueなど）に焦点を当てるのではなく、NoSqlの背後にあるすべての概念の後にいます。 あなたの経験から共有して、優れたリソースを私に指摘できますか？

8 learning  database  resources  concepts  nosql