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

NoSQL(「SQLだけではない」に拡張されることもある)は、リレーショナルデータベース管理システム(RDBMS)の従来のモデルとはいくつかの重要な点で異なる幅広いクラスのデータベース管理システムです。

21
リレーショナルデータベースを使用しない正当な理由は?
代替のデータストレージツールを指摘して、古き良きリレーショナルデータベースの代わりにそれらを使用する十分な理由を教えていただけませんか?私の意見では、ほとんどのアプリケーションがSQLの全機能を使用することはめったにありません。SQLフリーのアプリケーションを構築する方法を見るのは興味深いでしょう。
139 sql  database  nosql 

5
MongoDB / NoSQL:ドキュメントの変更履歴の保持
データベースアプリケーションでかなり一般的な要件は、データベース内の1つ以上の特定のエンティティへの変更を追跡することです。これは行のバージョン管理、ログテーブル、または履歴テーブルと呼ばれます(他にも名前があるはずです)。RDBMSでこれにアプローチする方法はいくつかあります。すべてのソーステーブルからのすべての変更を単一のテーブル(ログの詳細)に書き込むか、ソーステーブルごとに個別の履歴テーブルを作成できます。また、ロギングをアプリケーションコードで管理するか、データベーストリガーを介して管理するかを選択できます。 同じ問題の解決策がNoSQL /ドキュメントデータベース(具体的にはMongoDB)でどのように見えるか、そしてそれがどのように統一された方法で解決されるかを考えています。ドキュメントのバージョン番号を作成するのと同じくらい簡単で、それらを上書きすることはありませんか?「実際の」ドキュメントと「ログに記録された」ドキュメントのコレクションを個別に作成しますか?これはクエリとパフォーマンスにどのように影響しますか? とにかく、これはNoSQLデータベースの一般的なシナリオですか?その場合、一般的な解決策はありますか?
134 mongodb  nosql 

6
HBaseとHadoop / HDFSの違い
これは素朴な質問ですが、私はNoSQLパラダイムに不慣れで、あまり詳しくありません。それで、誰かがHBaseとHadoopの違いを明確に理解するのを助けることができるか、または違いを理解するのに役立つかもしれないいくつかの指針を与えるなら。 今まで、私はいくつかの研究とaccを行いました。私の理解では、HadoopはHDFSでデータ(ファイル)の生のチャンクを処理するフレームワークを提供し、HBaseはHadoop上のデータベースエンジンであり、基本的に生のデータチャンクではなく構造化データを処理します。Hbaseは、SQLと同じように、HDFS上の論理レイヤーを提供します。それが正しいか? Plsは私を自由に修正してください。 ありがとう。
130 hadoop  nosql  hbase  hdfs  difference 

7
平易な英語での結果の一貫性
NoSQLやデータグリッドなどに関するさまざまなスピーチで結果の一貫性についてよく耳にします。結果の一貫性の定義は多くのソースで異なるようです(具体的なデータストレージに依存している可能性もあります)。 具体的なデータストレージとは関係なく、結果整合性の一般的な用語について簡単に説明できますか?

3
SQL(MySQL)とNoSQL(CouchDB)[終了]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 この質問を改善する 大量のデータを保存する必要のあるスケーラビリティの高いアプリケーションを設計している最中です。たとえば、ユーザーに関する多くの情報や、メッセージ、コメントなどの多くのものを格納します。以前はMySQLを使用したことがありましたが、今はSQL以外のcouchdbなどの新しいものを試してみることにしました。 誰かこれについて何か考えやガイダンスはありますか?
126 mysql  sql  nosql  couchdb 

8
mongodbはCAP定理のどこに立っていますか?
どこを見ても、MongoDBがCPであることがわかります。しかし、掘り下げてみると、最終的には一貫していることがわかります。safe = trueを使用するとCPになりますか?もしそうなら、それは私がsafe = trueで書いた場合、結果を得る前にすべてのレプリカが更新されることを意味しますか?


4
NoSQLでレコード関係をどのように追跡しますか?
NoSQL KVPまたはドキュメントデータベースの外部キーとインデックスに相当するものを理解しようとしています。(2つのオブジェクト間の関係を示すキーを追加するための)ピボットテーブルはないので、通常のWebページに役立つ方法でデータを取得する方法に本当に困惑しています。 ユーザーがいて、このユーザーがサイト全体に多くのコメントを残したとします。ユーザーのコメントを追跡する唯一の方法は、 それらをユーザーオブジェクトに埋め込む(かなり役に立たないようです) user_id:comments各コメントのキーのリスト[コメント:34、コメント:197など...]を含む値を作成して維持し、必要に応じてそれらをフェッチできるようにします。 しかし、第二の例を取って、あなたはすぐに作るの3000万IDが含まれている場合があります「active_comments」と呼ばれるキーのような他のものを追跡するためにそれを使用するときにレンガの壁にヒットするTONの費用だけでいくつかの最近のを知って、各ページを照会しますアクティブなコメント。また、多くのページが同時に更新を試みる可能性があるため、競合状態が発生しやすくなります。 NoSQLデータベースで次のような関係を追跡するにはどうすればよいですか? ユーザーのすべてのコメント すべてのアクティブなコメント タグが付けられたすべての投稿[キーワード] クラブのすべての学生-または学生が所属するすべてのクラブ または私はこれについて間違って考えていますか?

9
mongodbは実行されていますか?
私のUnixサーバーにmongodbとphpドライバーをインストールしました。 私の質問は、mongodbが実行されているかどうかをどのように確認できるかです。ステータスを確認する簡単なコマンドラインクエリはありますか?シェルから一度起動すると、シェルを終了しても実行を続けます(そうではないようです)。mongodb接続を永続化し、サーバーの再起動時に自動起動するにはどうすればよいですか? 走れる: -bash-3.2 $ su パスワード: [root @ xxx] #cd / var / lib [root @ xxx]# . / mongodb-linux-i686-1.6.5 /bin/ mongod ./mongodb-linux-i686-1.6。 5 / bin / mongod --help for help and startup options Wed Feb 23 08:06:54 MongoDB starting:pid = 7271 port = 27017 dbpath = / data …
117 mongodb  unix  database  nosql 

5
非リレーショナルデータベースの設計[終了]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 この質問を改善する 非リレーショナル「nosql」データベースで使用した設計戦略について聞いてみたいと思います。つまり、従来のリレーショナル設計またはSQL(Hypertable、CouchDBなど)を使用しない(ほとんどの場合)データストアのクラスです。 SimpleDB、Google App Engineデータストア、Voldemort、Cassandra、SQLデータサービスなど)。それらは「キー/値ストア」とも呼ばれ、基本的に巨大な分散型永続ハッシュテーブルのように機能します。 具体的には、これらの新しいデータベースとの概念的なデータ設計の違いについて学びたいと思います。何がより簡単で、何が難しく、何ができないのでしょうか? 非リレーショナルの世界でよりうまく機能する代替設計を思いついたか。 不可能と思われるものに頭をぶつけましたか? たとえば、あるパターンから別のパターンに変換するなど、設計パターンでギャップを埋めましたか? 明示的なデータモデルを(UMLでなど)実行したり、半構造化/ドキュメント指向のデータブロブを全面的に採用したりしていますか? リレーショナル整合性、任意の複雑なトランザクションサポート、トリガーなど、RDBMSが提供する主要な追加サービスのどれかを見逃していますか? 私はSQLリレーショナルDBの出身なので、正規化は私の血の中にあります。とは言っても、単純化とスケーリングのための非リレーショナルデータベースの利点が得られ、設計機能にはより豊富なオーバーラップが必要であることが私の内臓からわかります。あなたは何をした? 参考までに、ここで同様のトピックに関するStackOverflowディスカッションが行われました。 次世代のデータベース Google App Engineで動作するようにスキーマを変更する ドキュメント指向のデータベースを選択する
114 database  nosql 

4
MYSQL 5.7のネイティブJSONサポート:MYSQLのJSONデータ型の長所と短所は何ですか?
MySQL 5.7では、MySQLテーブルにJSONデータを格納するための新しいデータ型が追加されました。それは明らかにMySQLの大きな変化になるでしょう。彼らはいくつかの利点を挙げました ドキュメントの検証 -有効なJSONドキュメントのみをJSON列に格納できるため、データの自動検証を取得できます。 効率的なアクセス -さらに重要なことに、JSONドキュメントをJSON列に格納すると、プレーンテキスト値として格納されません。代わりに、オブジェクトメンバーと配列要素にすばやくアクセスできるようにする最適化されたバイナリ形式で保存されます。 パフォーマンス -JSON列内の値にインデックスを作成することにより、クエリのパフォーマンスを向上させます。これは、仮想列の「機能インデックス」で実現できます。 利便性 -JSON列の追加のインライン構文により、SQL内にドキュメントクエリを統合することが非常に自然になります。例(features.featureはJSON列です):SELECT feature->"$.properties.STREET" AS property_street FROM features WHERE id = 121254; うわー !彼らはいくつかの素晴らしい機能が含まれています。データの操作が簡単になりました。より複雑なデータを列に格納できるようになりました。したがって、MySQLはNoSQLでフレーバーされています。 JSONデータのクエリは次のようになります。 SELECT * FROM t1 WHERE JSON_EXTRACT(data,"$.series") IN ( SELECT JSON_EXTRACT(data,"$.inverted") FROM t1 | {"series": 3, "inverted": 8} WHERE JSON_EXTRACT(data,"$.inverted")<4 ); それで、いくつかのjsonカラムに巨大な小さな関係を保存できますか?いいですか?それは正規化を壊しますか?これが可能であれば、MySQLカラムではNoSQLのように動作すると思います。この機能についてもっと知りたいです。MySQL JSONデータ型の長所と短所。

3
Firebaseでデータを構造化する最良の方法は何ですか?
私はFirebaseを使い始めたばかりですが、Firebaseでデータを構造化するための最良の方法を知りたいです。 私は簡単な例を持っています: 私のプロジェクトには応募者と応募者がいます。1人の申請者が複数の申請を行うことができます。この2つのオブジェクトをFirebaseで関連付けるにはどうすればよいですか?リレーショナルデータベースのように機能しますか?または、アプローチはデータ設計の点で完全に異なる必要がありますか?


7
メモリが不足すると、Redisは何をしますか?
これは簡単な質問かもしれませんが、答えを見つけるのに苦労しています。Redis 2.0は割り当てられた最大メモリ不足をどのように処理しますか?どのデータを削除するか、どのデータをメモリに保持するかをどのように決定しますか?
111 nosql  redis 

6
DynamoDBから多数のアイテムを削除するための推奨される方法は何ですか?
DynamoDBで簡単なロギングサービスを書いています。 user_idハッシュとタイムスタンプ(Unixエポックint)範囲をキーとするログテーブルがあります。 サービスのユーザーがアカウントを終了すると、範囲の値に関係なく、テーブル内のすべてのアイテムを削除する必要があります。 この種の操作を実行するための推奨される方法は何ですか(何百万ものアイテムが削除される可能性があることに注意してください)? 私が見る限り、私の選択肢は: A:スキャン操作を実行し、アイテムがなくなるまで、返された各アイテムに対してdeleteを呼び出します。 B:BatchGet操作を実行し、アイテムがなくなるまで各アイテムで削除を再度呼び出します どちらも時間がかかるので、どちらもひどく見えます。 私が理想的には、LogTable.DeleteItem(user_id)を呼び出します-範囲を指定せずに、すべてを削除してもらいます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.