diff --git a/README-ja.md b/README-ja.md index e8f4719d..5834fbe1 100644 --- a/README-ja.md +++ b/README-ja.md @@ -768,14 +768,14 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#通 SQLなどのリレーショナルデータベースはテーブルに整理されたデータの集合である。 -**ACID** はリレーショナルデータベースにおける[トランザクション](https://en.wikipedia.org/wiki/Database_transaction)のプロパティの集合である +**ACID** とは、リレーショナルデータベースの[トランザクション](https://en.wikipedia.org/wiki/Database_transaction)が持つ4つの特性のことです。 * **不可分性** - それぞれのトランザクションはあるかないかのいずれかである * **一貫性** - どんなトランザクションもデータベースをある確かな状態から次の状態に遷移させる。 -* **独立性** - 同時にトランザクションを処理することは、連続的にトランザクションを処理するのと同じ結果をもたらす。 -* **永続性** - トランザクションが処理されたら、そのように保存される +* **独立性** - 複数のトランザクションを並行に処理しても、トランザクションを順に処理したのと同じ結果になる。 +* **永続性** - いったんコミットされたトランザクションは、コミットされたまま残る。 -リレーショナルデータベースをスケールさせるためにはたくさんの技術がある: **マスター・スレーブ レプリケーション**、 **マスター・マスター レプリケーション**、 **federation**、 **シャーディング**、 **非正規化**、 そして **SQL チューニング** +リレーショナルデータベースをスケールさせるための技術は、**マスター・スレーブ レプリケーション**、 **マスター・マスター レプリケーション**、**federation**、**シャーディング**、**非正規化**、**SQL チューニング**などたくさんあります。 #### マスタースレーブ レプリケーション @@ -851,9 +851,9 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ Source: Scalability, availability, stability, patterns

-シャーディングでは異なるデータベースにそれぞれがデータのサブセット断片のみを持つようにデータを分割します。ユーザーデータベースを例にとると、ユーザー数が増えるにつれてクラスターにはより多くの断片が加えられることになります。 +シャーディングでは、複数のデータベースにデータを分散させて、各データベースはデータのサブセットだけを管理します。ユーザーデータベースを例にとると、ユーザー数の増加に合わせて、クラスターにシャードが追加されていくことになります。 -[federation](#federation)の利点に似ていて、シャーディングでは読み書きのトラフィックを減らし、レプリケーションを減らし、キャッシュヒットを増やすことができます。インデックスサイズも減らすことができます。一般的にはインデックスサイズを減らすと、パフォーマンスが向上しクエリ速度が速くなります。なにがしかのデータを複製する機能がなければデータロスにつながりますが、もし、一つのシャードが落ちても、他のシャードが動いていることになります。フェデレーションと同じく、単一の中央マスターが書き込みの処理をしなくても、並列で書き込みを処理することができ、スループットの向上が期待できます。 +[federation](#federation)の利点に似ていて、シャーディングでは読み書きのトラフィックを減らし、レプリケーションを減らし、キャッシュヒットを増やすことができます。インデックスサイズも減らすことができます。一般的にはインデックスサイズを減らすと、パフォーマンスが向上しクエリ速度が速くなります。一つのシャードが落ちたとしても、他のシャードは動き続けます。ただし、データの喪失を避けるため、何らかの形でレプリケーション機能を追加する必要があるでしょう。フェデレーションと同じく、単一の中央マスターで書き込みを直列化したりしないため、並列で書き込みを処理することができ、スループットの向上が期待できます。 ユーザーテーブルをシャードする一般的な方法は、ユーザーのラストネームイニシャルでシャードするか、ユーザーの地理的配置でシャードするなどです。 @@ -877,12 +877,12 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ [フェデレーション](#federation) や [シャーディング](#シャーディング)などのテクニックによってそれぞれのデータセンターに分配されたデータを合一させることはとても複雑な作業です。非正規化によってそのような複雑な処理をしなくて済むようになります。 -多くのシステムで、100対1あるいは1000対1くらいになるくらい読み取りの方が、書き込みのトラフィックよりも多いことでしょう。読み込みを行うために、複雑なデータベースのジョイン処理が含まれるものは計算的に高価につきますし、ディスクの処理時間で膨大な時間を費消してしまうことになります。 +多くのシステムで、100対1あるいは1000対1くらいになるくらい読み取りの方が、書き込みのトラフィックよりも多いことでしょう。複雑なデータベースのジョインを伴う読み込み処理は、計算量的に非常に高価になる（ディスクの処理にかなりの時間を費消する）こともあります。 ##### 欠点: 非正規化 * データが複製される。 -* 冗長なデータの複製が同期されるように制約が存在し、そのことでデータベース全体の設計が複雑化する。 +* 制約を使えば、同じ情報が複数あっても同期を取ることができますが、一方でデータベース全体の設計が複雑になります。 * 非正規化されたデータベースは過大な書き込みを処理しなければならない場合、正規化されているそれよりもパフォーマンスにおいて劣る可能性がある。 ###### その他の参考資料、ページ: 非正規化 @@ -943,23 +943,23 @@ SQLチューニングは広範な知識を必要とする分野で多くの [本 NoSQL は **key-value store**、 **document-store**、 **wide column store**、 もしくは **graph database**によって表現されるデータアイテムの集合です。データは一般的に正規化されておらず、アプリケーション側でジョインが行われます。大部分のNoSQLは真のACIDトランザクションを持たず、 [結果整合性](#結果整合性) 的な振る舞いの方を好みます。 -**BASE** はしばしばNoSQLデータベースのプロパティを説明するために用いられます。[CAP Theorem](#cap-理論) と対照的に、BASEは一貫性よりも可用性を優先します。 +**BASE** はNoSQLデータベースの特性を説明する際によく用いられます。[CAP Theorem](#cap-理論) と対照的に、BASEは一貫性よりも可用性を優先します。 * **Basically available** - システムは可用性を保証します。 * **Soft state** - システムの状態は入力がなくても時間経過とともに変化する可能性があります。 -* **結果整合性** - システム全体は時間経過とともにその間に入力がないという前提のもと、一貫性が達成されます。 +* **結果整合性** - システムに対する入力がなければ、システムは一定時間経過後に一貫性のある状態になります。 -[SQLか？NoSQLか？](#sqlかnosqlか) を選択するのに加えて、どのタイプのNoSQLがどの使用例に最も適するかを理解するのはとても有益です。このセクションでは **キーバリューストア**、 **ドキュメントストア**、 **ワイドカラムストア**、 と **グラフデータベース** について触れていきます。 +[SQLか？NoSQLか？](#sqlかnosqlか) を選択するのに加えて、どのタイプのNoSQLがどのユースケースに最も適するかを理解するのはとても有益です。このセクションでは **キーバリューストア**、 **ドキュメントストア**、 **ワイドカラムストア**、 と **グラフデータベース** について触れていきます。 #### キーバリューストア -> 概要: ハッシュテーブル +> 抽象化すると: ハッシュテーブル キーバリューストアでは一般的にO(1)の読み書きができ、それらはメモリないしSSDで裏付けられています。データストアはキーを [辞書的順序](https://en.wikipedia.org/wiki/Lexicographical_order) で保持することでキーの効率的な取得を可能にしています。キーバリューストアではメタデータを値とともに保持することが可能です。 キーバリューストアはハイパフォーマンスな挙動が可能で、単純なデータモデルやインメモリーキャッシュレイヤーなどのデータが急速に変わる場合などに使われます。単純な処理のみに機能が制限されているので、追加の処理機能が必要な場合にはその複雑性はアプリケーション層に載せることになります。 -キーバリューストアはもっと複雑なドキュメントストアや、グラフデータベースなどの基本です。 +キーバリューストアはより複雑なシステム（ドキュメントストアや、一部のグラフデータベースなど）の基盤にもなっています。 ##### その他の参考資料、ページ: キーバリューストア @@ -970,9 +970,9 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 #### ドキュメントストア -> 概要: ドキュメントがバリューとして保存されたキーバリューストア +> 抽象化すると: ドキュメントがバリューとして保存されたキーバリューストア -ドキュメントストアはオブジェクトに関する全ての情報を持つドキュメント(XML、 JSON、 binaryなど)を中心に据えたシステムです。ドキュメントストアでは、ドキュメント自身の内部構造に基づいた、APIもしくはクエリ言語を提供します。 *メモ：多くのキーバリューストアでは、値のメタデータを扱う機能を含んでいますが、そのことによって二つドキュメントストアとの境界線が曖昧になってしまっています。* +ドキュメントストアはオブジェクトに関する全ての情報を持つドキュメント(XML、 JSON、 binaryなど)を中心に据えたシステムです。ドキュメントストアでは、ドキュメント自身の内部構造に基づいた、APIもしくはクエリ言語を提供します。 *メモ：多くのキーバリューストアでは、値のメタデータを扱う機能を含んでいますが、そのことによってドキュメントストアとの境界線が曖昧になってしまっています。* 以上のことを実現するために、ドキュメントはコレクション、タグ、メタデータやディレクトリなどとして整理されています。ドキュメント同士はまとめてグループにできるものの、それぞれで全く異なるフィールドを持つ可能性があります。 @@ -995,13 +995,13 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 Source: SQL & NoSQL, a brief history

-> 概要: ネストされたマップ `カラムファミリー<行キー、 カラム>` +> 抽象化すると: ネストされたマップ `ColumnFamily>` ワイドカラムストアのデータの基本単位はカラム（ネーム・バリューのペア）です。それぞれのカラムはカラムファミリーとして（SQLテーブルのように）グループ化することができます。スーパーカラムファミリーはカラムファミリーの集合です。それぞれのカラムには行キーでアクセスすることができます。同じ行キーを持つカラムは同じ行として認識されます。それぞれの値は、バージョン管理とコンフリクトが起きた時のために、タイムスタンプを含みます。 Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf)を初のワイドカラムストアとして発表しました。それがオープンソースでHadoopなどでよく使われる[HBase](https://www.mapr.com/blog/in-depth-look-hbase-architecture) やFacebookによる[Cassandra](http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/architecture/architectureIntro_c.html) などのプロジェクトに影響を与えました。BigTable、HBaseやCassandraなどのストアはキーを辞書形式で保持することで選択したキーレンジでのデータ取得を効率的にします。 -ワイドカラムストアは高い可用性とスケーラビリティを担保します。これらはとても大規模なデータセットを扱うことによく使われます。 +ワイドカラムストアでは、高い可用性とスケーラビリティを実現できます。ワイドカラムストアは、非常に大規模なデータセットを扱う際によく使われます。 ##### その他の参考資料、ページ: ワイドカラムストア @@ -1018,11 +1018,11 @@ Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/cha Source: Graph database

-> 概要: グラフ +> 抽象化すると: グラフ -グラフデータベースでは、それぞれのノードがレコードで、それぞれのアークは二つのノードを繋ぐ関係性として定義されます。グラフデータベースは多数の外部キーや多対多などの複雑な関係性を表すのに最適です。 +グラフデータベースでは、各ノードはレコードに、各アークは二つのノードを繋ぐリレーションになります。グラフデータベースは、多数の外部キーを持つ複雑なリレーションや、多対多のリレーションを表す用途に最適化されています。 -グラフデータベースはSNSなどのサービスの複雑な関係性モデルなどについて高いパフォーマンスを発揮します。比較的新しく、まだ一般的には用いられていないので、開発ツールやリソースを探すのが他の方法に比べて難しいかもしれません。多くのグラフは[REST APIs](#representational-state-transfer-rest)を通じてのみアクセスできます。 +グラフデータベースは、ソーシャルネットワークなど、複雑なリレーションを持つモデルで高いパフォーマンスを発揮します。比較的新しく、まだ一般的には用いられていないので、開発ツールやリソースを探すのが他の方法に比べて難しいかもしれません。多くのグラフは[REST APIs](#representational-state-transfer-rest)を通じてのみアクセスできます。 ##### その他の参考資料、ページ: グラフ @@ -1063,8 +1063,8 @@ Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/cha * ダイナミックないし、フレキシブルなスキーマ * ノンリレーショナルなデータ * 複雑なジョインをする必要がない -* データの多くのTB (もしくは PB) を保存する -* 集中的、大規模なデータ負荷に耐えられる +* 数TB (もしくは数PB) のデータを保存する +* 非常にデータ集約型のワークロード * IOPSについては極めて高いスループットを示す NoSQLに適するサンプルデータ: