web-dev-qa-db-ja.com

各タイプのデータベースの実際の例（実際のケース）

さまざまな目的のデータベースにはいくつかのタイプがありますが、最もよく知られているデータベースであるため、通常はすべてにMySQLが使用されます。私の会社の例を挙げると、ビッグデータのアプリケーションには初期段階でMySQLデータベースがあり、信じられないほど深刻な結果をもたらします。 MySQLを選ぶ理由他のDBMSをどのように（そしていつ）使用すべきかを誰も知らないからです。

だから、私の質問はベンダーではなく、データベースの種類です。使用することが強く推奨されているデータベースの各タイプの特定の状況（またはアプリ）の実用的な例を教えてください。

例：

•ソーシャルネットワークでは、YのためXタイプを使用する必要があります。

•MongoDBまたはCouch DBはトランザクションをサポートできないため、Document DBは銀行またはオークションサイトのアプリには適していません。

等々...

リレーショナル：MySQL 、 PostgreSQL 、 SQLite 、 Firebird 、 MariaDB 、 Oracle DB 、 SQLサーバー 、 IBM DB2 、 IBM Informix 、 Teradata

Object：[〜＃〜] zodb [〜＃〜] 、 DB4O 、- Eloquera 、 Versant 、 Objectivity DB 、 VelocityDB

グラフデータベース：AllegroGraph 、 Neo4j 、 OrientDB 、- InfiniteGraph 、 グラフベース 、 sparkledb 、 flockdb 、 BrightstarDB

キー値ストア：Amazon DynamoDB 、 Redis 、 Riak 、 Voldemort 、 FoundationDB 、 leveldb 、 BangDB 、 [〜＃〜] kai [〜＃ 〜] 、 hamsterdb 、 Tarantool 、 Maxtable 、 HyperDex 、 Genom 、 Memcachedb

カラムファミリー：大きなテーブル 、 Hbase 、 ハイパーテーブル 、 Cassandra 、 Apache Accumulo

RDFストア：Apache Jena 、 Sesame

マルチモデルデータベース：arangodb 、 Datomic 、 Orient DB 、- FatDB 、 AlchemyDB

ドキュメント：Mongo DB 、 Couch DB 、 Rethink DB 、 Raven DB 、 terrastore 、 Jas DB 、 Raptor DB 、 djon DB 、- [〜＃〜] ejdb [〜＃〜] 、 denso DB 、 Couchbase

XMLデータベース：BaseX 、 Sedna 、 eXist

階層：InterSystemsCaché 、 GT.M@ Laurent Parenteauに感謝

databasenosqlrelational-database
56
daniel__

この質問は一般的であるため、答えることはほとんど不可能です。何か簡単な答えの問題=解決策を探していると思います。問題は、ビジネスになるにつれて各「問題」がますます一意になることです。

ソーシャルネットワークとは何ですか？ツイッター？フェイスブック？ LinkedIn？スタックオーバーフロー？それらはすべて異なる部品に異なるソリューションを使用しており、多言語アプローチを使用する多くのソリューションが存在する可能性があります。 Twitterにはコンセプトのようなグラフがありますが、つながり、フォロワー、フォローは1度しかありません。一方、LinkedInは、人々が1度以上のつながりを持っていることを示すことに成功しています。これらは2つの異なる処理とデータのニーズですが、どちらも「ソーシャルネットワーク」です。

「ソーシャルネットワーク」があり、ディスカバリメカニズムを実行していない場合は、ほとんどの場合、基本的なキーと値のストアを簡単に使用できます。高性能、水平スケールが必要で、セカンダリインデックスまたは全文検索が必要な場合は、 Couchbase を使用できます。

収集しているログデータに加えて機械学習を行っている場合、HadoopをHiveまたはPig、またはSpark/Sharkと統合できます。または、ラムダアーキテクチャを実行し、Stormでさまざまなシステムを使用できます。

2次の頂点を超えるクエリのようなグラフを介してディスカバリーを行い、エッジプロパティをフィルター処理する場合は、プライマリストアの上部にあるグラフデータベースを検討する可能性があります。ただし、グラフストアはセッションストアとして、または汎用ストアとしては適切な選択肢ではないため、効率的にポリグロットソリューションが必要になります。

データ速度とは何ですか？規模？どのように管理しますか。会社またはスタートアップで利用できる専門知識は何ですか。これが単純な質問と回答ではない理由はいくつかあります。

5
scalabl3

データベース選択に固有の短い便利な読み取り： NoSQLデータベースの選択方法 。この回答でキーポイントを強調します。

キーバリューとドキュメント指向

Key-Valueストア

すべてのデータにキーが1つだけになるように明確なデータ構造が定義されている場合は、キーと値のストアを探します。大きなHashtableがあるようで、多くの人はそれをCacheストアまたは明らかにキーベースのデータに使用します。ただし、複数のキーに基づいて同じデータを照会する必要がある場合、事態は少し厄介になります！

いくつかの重要な値ストアは、 memcached 、 Redis 、 Aerospike です。

キーと値のストアに関するデータモデルの設計に関する2つの重要な点は次のとおりです。

  • すべてのユースケースを事前に知る必要があり、再設計しないとデータ内のクエリ可能なフィールドを変更できませんでした。
  • キーと値のストア内の同じデータの周りに複数のキーを維持しようとする場合、複数のテーブル/バケット/コレクション/アトミックではないものへの更新を覚えておいてください。あなた自身でこれに対処する必要があります。

ドキュメント指向

RDBMSから離れて、データをオブジェクトのように、テーブルのような構造にできるだけ近づけたい場合は、ドキュメント構造が最適です。アプリを作成していて、RDBMSテーブルの設計を早い段階（プロトタイピング段階）で処理したくない場合、スキーマが時間とともに大幅に変更される可能性がある場合に特に便利です。ただし、次の点に注意してください。

  • 二次索引も同様に機能しない場合があります。
  • トランザクションは利用できません。

一般的なドキュメント指向データベースは、 MongoDB 、 Couchbase です。

Key-Value NoSQLデータベースの比較

memcached

  • メモリ内キャッシュ
  • 永続性なし
  • TTLサポート
  • クライアント側のクラスタリングのみ（クライアントは複数のノードに値を保存します）。クライアントを介して水平方向にスケーラブル。
  • 大きなサイズの値/ドキュメントには適していません

Redis

エアロスパイク

  • インメモリとオンディスクの両方
  • 非常に高速（単一ノードで100万以上のTPSをサポートできます）
  • 水平方向にスケーラブル。サーバー側のクラスタリング。断片化および複製されたデータ
  • 自動フェイルオーバー
  • サポート セカンダリインデックス
  • CAS（安全な読み取り-変更-書き込み）操作、TTLサポート
  • エンタープライズクラス

ドキュメント指向のNoSQLデータベースの比較

MongoDB

  • 速い
  • 成熟した安定した機能–豊富な機能
  • フェイルオーバーをサポート
  • 水平方向にスケーラブルな読み取り-レプリカ/セカンダリから読み取り
  • Mongoシャードを使用しない限り、水平方向にスケーラブルではない書き込み
  • 高度なクエリをサポート
  • 複数のセカンダリインデックスをサポート
  • シャードアーキテクチャはトリッキーになり、セカンダリインデックスが必要なポイントを超えてスケ​​ーラブルではありません。基本のシャード展開には、少なくとも9つのノードが必要です。
  • 書き込み速度が非常に高い場合、ドキュメントレベルのロックが問題になります

Couchbase Server

  • 速い
  • Mongodbのマスタースレーブではなく、シャードクラスター
  • ホットフェールオーバーのサポート
  • 水平方向にスケーラブル
  • ビューを介してセカンダリインデックスをサポート
  • MongoDBよりも大きな学習曲線
  • より高速であるという主張
1
naXa