From 7e84ba48a658ecf9fe182fb526090edefd08fcf7 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Sat, 6 Jul 2019 03:02:01 +0900 Subject: [PATCH 01/20] JA: Fix mistranslation in Weak consistency section MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "best effort" should be literally "ベストエフォート" in Japanese. - "メムキャッシュ" is overtranslation. Remain in English: "memecached". - The modification structure of last sentence in Japanese is ambiguous. --- README-ja.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README-ja.md b/README-ja.md index 9aa683e2..9a784d57 100644 --- a/README-ja.md +++ b/README-ja.md @@ -471,9 +471,9 @@ ### 弱い一貫性 -書き込み後の読み取りでは、その最新の書き込みを読めたり読めなかったりする。一番良いアプローチが選択される。 +書き込み後の読み取りでは、その最新の書き込みを読めたり読めなかったりする。ベストエフォート型のアプローチに基づく。 -メムキャッシュなどのシステムにおいてこのアプローチは取られる。弱い一貫性はリアルタイム性が必要な使用例、例えばVoIP、ビデオチャット、リアルタイムマルチプレイヤーゲームなどと相性がいいでしょう。例えば、電話に出ていて、受信を数秒受け取れなかったとして、その後に接続回復してもその接続が切断されていた間に話されていたことは聞き取れないというような感じです。 +このアプローチはmemcachedなどのシステムに見られます。弱い一貫性はリアルタイム性が必要なユースケース、例えばVoIP、ビデオチャット、リアルタイムマルチプレイヤーゲームなどと相性がいいでしょう。例えば、電話に出ているときに数秒間音声が受け取れなくなったとしたら、その後に接続が回復してもその接続が切断されていた間に話されていたことは聞き取れないというような感じです。 ### 結果整合性 From 7e75774797d3fd5c9fbcd830872ed0922d9cd8d7 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 16:46:34 +0900 Subject: [PATCH 02/20] Correct mistranslation in Relational database management system (RDBMS) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - “特性” is commonly used for the translation of “(ACID) property” rather than “プロパティ”. - “set of properties” couldn’t be literally translated in this situation (“プロパティの集合” doesn’t make sense), so substitute with “4つの特性” (four properties). --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index d124de81..bef8e9fc 100644 --- a/README-ja.md +++ b/README-ja.md @@ -768,7 +768,7 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#通 SQLなどのリレーショナルデータベースはテーブルに整理されたデータの集合である。 -**ACID** はリレーショナルデータベースにおける[トランザクション](https://en.wikipedia.org/wiki/Database_transaction)のプロパティの集合である +**ACID** とは、リレーショナルデータベースの[トランザクション](https://en.wikipedia.org/wiki/Database_transaction)が持つ4つの特性のことです。 * **不可分性** - それぞれのトランザクションはあるかないかのいずれかである * **一貫性** - どんなトランザクションもデータベースをある確かな状態から次の状態に遷移させる。 From f1ed2e2d16ff7b6bc695273dba820a9165156425 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 16:49:54 +0900 Subject: [PATCH 03/20] Correct mistranslation in Relational database management system (RDBMS) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Usually "並行に" is used for the translation of "concurrently" rather than "同時に" (simultaneously). - "serially" means "順に" in Japanese. "連続的" isn’t used in this kind of context. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index bef8e9fc..e9964590 100644 --- a/README-ja.md +++ b/README-ja.md @@ -772,7 +772,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ * **不可分性** - それぞれのトランザクションはあるかないかのいずれかである * **一貫性** - どんなトランザクションもデータベースをある確かな状態から次の状態に遷移させる。 -* **独立性** - 同時にトランザクションを処理することは、連続的にトランザクションを処理するのと同じ結果をもたらす。 +* **独立性** - 複数のトランザクションを並行に処理しても、トランザクションを順に処理したのと同じ結果になる。 * **永続性** - トランザクションが処理されたら、そのように保存される リレーショナルデータベースをスケールさせるためにはたくさんの技術がある: **マスター・スレーブ レプリケーション**、 **マスター・マスター レプリケーション**、 **federation**、 **シャーディング**、 **非正規化**、 そして **SQL チューニング** From 8bcac35ca7b8d138d72ecb39996c40e9e7c10180 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 16:51:29 +0900 Subject: [PATCH 04/20] Correct mistranslation in Relational database management system (RDBMS) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "Once" (いったん) is missing in the translation. - "コミット" is commonly used for the translation of "commit" rather than "処理" (process). - "そのように保存される" doesn’t make sense in this context. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index e9964590..1a13a634 100644 --- a/README-ja.md +++ b/README-ja.md @@ -773,7 +773,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ * **不可分性** - それぞれのトランザクションはあるかないかのいずれかである * **一貫性** - どんなトランザクションもデータベースをある確かな状態から次の状態に遷移させる。 * **独立性** - 複数のトランザクションを並行に処理しても、トランザクションを順に処理したのと同じ結果になる。 -* **永続性** - トランザクションが処理されたら、そのように保存される +* **永続性** - いったんコミットされたトランザクションは、コミットされたまま残る。 リレーショナルデータベースをスケールさせるためにはたくさんの技術がある: **マスター・スレーブ レプリケーション**、 **マスター・マスター レプリケーション**、 **federation**、 **シャーディング**、 **非正規化**、 そして **SQL チューニング** From 878781ebfc4bdd072ad2bcaa216cb485f73ef36c Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 16:54:10 +0900 Subject: [PATCH 05/20] Make Japanese translation more fluent - The translation is ambiguous about "There are many techniques" or "You need many techniques". - ":" is not properly translated. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 1a13a634..78df5650 100644 --- a/README-ja.md +++ b/README-ja.md @@ -775,7 +775,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ * **独立性** - 複数のトランザクションを並行に処理しても、トランザクションを順に処理したのと同じ結果になる。 * **永続性** - いったんコミットされたトランザクションは、コミットされたまま残る。 -リレーショナルデータベースをスケールさせるためにはたくさんの技術がある: **マスター・スレーブ レプリケーション**、 **マスター・マスター レプリケーション**、 **federation**、 **シャーディング**、 **非正規化**、 そして **SQL チューニング** +リレーショナルデータベースをスケールさせるための技術は、**マスター・スレーブ レプリケーション**、 **マスター・マスター レプリケーション**、**federation**、**シャーディング**、**非正規化**、**SQL チューニング**などたくさんあります。 #### マスタースレーブ レプリケーション From 7c0c3cd57c1e582fd3835a26d577d8ea56df696a Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:01:50 +0900 Subject: [PATCH 06/20] Correct mistranslation in Sharding MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "different" means "複数の" rather than "異なる" in this context. - "distribute" means "分散" rather than "分割" (split). - "断片" (fragment) is mistranslation for "shards". - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 78df5650..471d2334 100644 --- a/README-ja.md +++ b/README-ja.md @@ -851,7 +851,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ Source: Scalability, availability, stability, patterns

-シャーディングでは異なるデータベースにそれぞれがデータのサブセット断片のみを持つようにデータを分割します。ユーザーデータベースを例にとると、ユーザー数が増えるにつれてクラスターにはより多くの断片が加えられることになります。 +シャーディングでは、複数のデータベースにデータを分散させて、各データベースはデータのサブセットだけを管理します。ユーザーデータベースを例にとると、ユーザー数の増加に合わせて、クラスターにシャードが追加されていくことになります。 [federation](#federation)の利点に似ていて、シャーディングでは読み書きのトラフィックを減らし、レプリケーションを減らし、キャッシュヒットを増やすことができます。インデックスサイズも減らすことができます。一般的にはインデックスサイズを減らすと、パフォーマンスが向上しクエリ速度が速くなります。なにがしかのデータを複製する機能がなければデータロスにつながりますが、もし、一つのシャードが落ちても、他のシャードが動いていることになります。フェデレーションと同じく、単一の中央マスターが書き込みの処理をしなくても、並列で書き込みを処理することができ、スループットの向上が期待できます。 From e9f6bd970f42947d44099843ecefe4e26b03bf8e Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:06:38 +0900 Subject: [PATCH 07/20] Make Japanese translation more fluent --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 471d2334..e1603cd6 100644 --- a/README-ja.md +++ b/README-ja.md @@ -853,7 +853,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ シャーディングでは、複数のデータベースにデータを分散させて、各データベースはデータのサブセットだけを管理します。ユーザーデータベースを例にとると、ユーザー数の増加に合わせて、クラスターにシャードが追加されていくことになります。 -[federation](#federation)の利点に似ていて、シャーディングでは読み書きのトラフィックを減らし、レプリケーションを減らし、キャッシュヒットを増やすことができます。インデックスサイズも減らすことができます。一般的にはインデックスサイズを減らすと、パフォーマンスが向上しクエリ速度が速くなります。なにがしかのデータを複製する機能がなければデータロスにつながりますが、もし、一つのシャードが落ちても、他のシャードが動いていることになります。フェデレーションと同じく、単一の中央マスターが書き込みの処理をしなくても、並列で書き込みを処理することができ、スループットの向上が期待できます。 +[federation](#federation)の利点に似ていて、シャーディングでは読み書きのトラフィックを減らし、レプリケーションを減らし、キャッシュヒットを増やすことができます。インデックスサイズも減らすことができます。一般的にはインデックスサイズを減らすと、パフォーマンスが向上しクエリ速度が速くなります。一つのシャードが落ちたとしても、他のシャードは動き続けます。ただし、データの喪失を避けるため、何らかの形でレプリケーション機能を追加する必要があるでしょう。フェデレーションと同じく、単一の中央マスターで書き込みを直列化したりしないため、並列で書き込みを処理することができ、スループットの向上が期待できます。 ユーザーテーブルをシャードする一般的な方法は、ユーザーのラストネームイニシャルでシャードするか、ユーザーの地理的配置でシャードするなどです。 From 6575de78154b46576272dd1d95d6d32174e6f75d Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:08:42 +0900 Subject: [PATCH 08/20] Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index e1603cd6..b446f651 100644 --- a/README-ja.md +++ b/README-ja.md @@ -877,7 +877,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ [フェデレーション](#federation) や [シャーディング](#シャーディング)などのテクニックによってそれぞれのデータセンターに分配されたデータを合一させることはとても複雑な作業です。非正規化によってそのような複雑な処理をしなくて済むようになります。 -多くのシステムで、100対1あるいは1000対1くらいになるくらい読み取りの方が、書き込みのトラフィックよりも多いことでしょう。読み込みを行うために、複雑なデータベースのジョイン処理が含まれるものは計算的に高価につきますし、ディスクの処理時間で膨大な時間を費消してしまうことになります。 +多くのシステムで、100対1あるいは1000対1くらいになるくらい読み取りの方が、書き込みのトラフィックよりも多いことでしょう。複雑なデータベースのジョインを伴う読み込み処理は、計算量的に非常に高価になる（ディスクの処理にかなりの時間を費消する）こともあります。 ##### 欠点: 非正規化 From 720df8f7b1db5588747286b302e00c600053354e Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:09:44 +0900 Subject: [PATCH 09/20] Correct mistranslation in Denormalization MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - The original Japanese translation doesn’t make sense. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index b446f651..e7a2c1ec 100644 --- a/README-ja.md +++ b/README-ja.md @@ -882,7 +882,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ ##### 欠点: 非正規化 * データが複製される。 -* 冗長なデータの複製が同期されるように制約が存在し、そのことでデータベース全体の設計が複雑化する。 +* 制約を使えば、同じ情報が複数あっても同期を取ることができますが、一方でデータベース全体の設計が複雑になります。 * 非正規化されたデータベースは過大な書き込みを処理しなければならない場合、正規化されているそれよりもパフォーマンスにおいて劣る可能性がある。 ###### その他の参考資料、ページ: 非正規化 From 7ffeebba9b2d914e7b494a1fd0a3ac19cc9a8c7c Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:12:14 +0900 Subject: [PATCH 10/20] Correct mistranslation in NoSQL MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "特性" is commonly used for the translation of "properties" rather than "プロパティ" in this context. - Make the translation more fluent ("しばしば" is too literal). --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index e7a2c1ec..15b5f03c 100644 --- a/README-ja.md +++ b/README-ja.md @@ -943,7 +943,7 @@ 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** - システムの状態は入力がなくても時間経過とともに変化する可能性があります。 From dfd17ebf2f1ea4e4d9b057599f66a9a1e8d02722 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:12:41 +0900 Subject: [PATCH 11/20] Make the translation more fluent --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 15b5f03c..7f823c8e 100644 --- a/README-ja.md +++ b/README-ja.md @@ -947,7 +947,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 * **Basically available** - システムは可用性を保証します。 * **Soft state** - システムの状態は入力がなくても時間経過とともに変化する可能性があります。 -* **結果整合性** - システム全体は時間経過とともにその間に入力がないという前提のもと、一貫性が達成されます。 +* **結果整合性** - システムに対する入力がなければ、システムは一定時間経過後に一貫性のある状態になります。 [SQLか？NoSQLか？](#sqlかnosqlか) を選択するのに加えて、どのタイプのNoSQLがどの使用例に最も適するかを理解するのはとても有益です。このセクションでは **キーバリューストア**、 **ドキュメントストア**、 **ワイドカラムストア**、 と **グラフデータベース** について触れていきます。 From 508fca91d89c479c9dc7f52825617f4b057ebf31 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:13:28 +0900 Subject: [PATCH 12/20] Correct mistranslation in NoSQL MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Usually "ユースケース" is used for the translation of "use case" rather than "使用例" ("使用例" is overtranslation). --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 7f823c8e..04a31ffe 100644 --- a/README-ja.md +++ b/README-ja.md @@ -949,7 +949,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 * **Soft state** - システムの状態は入力がなくても時間経過とともに変化する可能性があります。 * **結果整合性** - システムに対する入力がなければ、システムは一定時間経過後に一貫性のある状態になります。 -[SQLか？NoSQLか？](#sqlかnosqlか) を選択するのに加えて、どのタイプのNoSQLがどの使用例に最も適するかを理解するのはとても有益です。このセクションでは **キーバリューストア**、 **ドキュメントストア**、 **ワイドカラムストア**、 と **グラフデータベース** について触れていきます。 +[SQLか？NoSQLか？](#sqlかnosqlか) を選択するのに加えて、どのタイプのNoSQLがどのユースケースに最も適するかを理解するのはとても有益です。このセクションでは **キーバリューストア**、 **ドキュメントストア**、 **ワイドカラムストア**、 と **グラフデータベース** について触れていきます。 #### キーバリューストア From f7ea14de132f15dc699809305319be713d88cffe Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:15:21 +0900 Subject: [PATCH 13/20] Correct mistranslation in Key-value store MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "基本" (basics) is mistranslation for "basis" ("基盤"). - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 04a31ffe..e40b01a9 100644 --- a/README-ja.md +++ b/README-ja.md @@ -959,7 +959,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 キーバリューストアはハイパフォーマンスな挙動が可能で、単純なデータモデルやインメモリーキャッシュレイヤーなどのデータが急速に変わる場合などに使われます。単純な処理のみに機能が制限されているので、追加の処理機能が必要な場合にはその複雑性はアプリケーション層に載せることになります。 -キーバリューストアはもっと複雑なドキュメントストアや、グラフデータベースなどの基本です。 +キーバリューストアはより複雑なシステム（ドキュメントストアや、一部のグラフデータベースなど）の基盤にもなっています。 ##### その他の参考資料、ページ: キーバリューストア From ad9a7d3d149febd871f4ca3ed667e5f88e47c9d2 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:16:28 +0900 Subject: [PATCH 14/20] Correct mistranslation in Document store MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Fix a literal error ("二つ" is unnecessary) --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index e40b01a9..363fa390 100644 --- a/README-ja.md +++ b/README-ja.md @@ -972,7 +972,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 > 概要: ドキュメントがバリューとして保存されたキーバリューストア -ドキュメントストアはオブジェクトに関する全ての情報を持つドキュメント(XML、 JSON、 binaryなど)を中心に据えたシステムです。ドキュメントストアでは、ドキュメント自身の内部構造に基づいた、APIもしくはクエリ言語を提供します。 *メモ：多くのキーバリューストアでは、値のメタデータを扱う機能を含んでいますが、そのことによって二つドキュメントストアとの境界線が曖昧になってしまっています。* +ドキュメントストアはオブジェクトに関する全ての情報を持つドキュメント(XML、 JSON、 binaryなど)を中心に据えたシステムです。ドキュメントストアでは、ドキュメント自身の内部構造に基づいた、APIもしくはクエリ言語を提供します。 *メモ：多くのキーバリューストアでは、値のメタデータを扱う機能を含んでいますが、そのことによってドキュメントストアとの境界線が曖昧になってしまっています。* 以上のことを実現するために、ドキュメントはコレクション、タグ、メタデータやディレクトリなどとして整理されています。ドキュメント同士はまとめてグループにできるものの、それぞれで全く異なるフィールドを持つ可能性があります。 From 46616fd6fc67df218c398f47c7864ef71be2675f Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:18:22 +0900 Subject: [PATCH 15/20] Correct mistranslation in Wide column store - "ColumnFamily" is wrongly translated. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 363fa390..34758191 100644 --- a/README-ja.md +++ b/README-ja.md @@ -995,7 +995,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 Source: SQL & NoSQL, a brief history

-> 概要: ネストされたマップ `カラムファミリー<行キー、 カラム>` +> 概要: ネストされたマップ `ColumnFamily>` ワイドカラムストアのデータの基本単位はカラム（ネーム・バリューのペア）です。それぞれのカラムはカラムファミリーとして（SQLテーブルのように）グループ化することができます。スーパーカラムファミリーはカラムファミリーの集合です。それぞれのカラムには行キーでアクセスすることができます。同じ行キーを持つカラムは同じ行として認識されます。それぞれの値は、バージョン管理とコンフリクトが起きた時のために、タイムスタンプを含みます。 From 0e85af537609a5622dcbe8720f64569e46b29984 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:19:06 +0900 Subject: [PATCH 16/20] Correct mistranslation in Wide column store MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "担保します" (guarantee) is mistranslation for "offer". - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 34758191..5e857b8f 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1001,7 +1001,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 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などのストアはキーを辞書形式で保持することで選択したキーレンジでのデータ取得を効率的にします。 -ワイドカラムストアは高い可用性とスケーラビリティを担保します。これらはとても大規模なデータセットを扱うことによく使われます。 +ワイドカラムストアでは、高い可用性とスケーラビリティを実現できます。ワイドカラムストアは、非常に大規模なデータセットを扱う際によく使われます。 ##### その他の参考資料、ページ: ワイドカラムストア From db8eeae4d8abbbf97b2b159c24f3fdbaf1b5b856 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:21:47 +0900 Subject: [PATCH 17/20] Correct mistranslation in Graph database MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Usually "リレーション" is used for the translation of "relationship" rather than "関係性" in this context. - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 5e857b8f..7c1e5230 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1020,7 +1020,7 @@ Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/cha > 概要: グラフ -グラフデータベースでは、それぞれのノードがレコードで、それぞれのアークは二つのノードを繋ぐ関係性として定義されます。グラフデータベースは多数の外部キーや多対多などの複雑な関係性を表すのに最適です。 +グラフデータベースでは、各ノードはレコードに、各アークは二つのノードを繋ぐリレーションになります。グラフデータベースは、多数の外部キーを持つ複雑なリレーションや、多対多のリレーションを表す用途に最適化されています。 グラフデータベースはSNSなどのサービスの複雑な関係性モデルなどについて高いパフォーマンスを発揮します。比較的新しく、まだ一般的には用いられていないので、開発ツールやリソースを探すのが他の方法に比べて難しいかもしれません。多くのグラフは[REST APIs](#representational-state-transfer-rest)を通じてのみアクセスできます。 From 91e01ee503f935789b67989760d14ffab9fa07ad Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:22:44 +0900 Subject: [PATCH 18/20] Correct mistranslation in Graph database MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Usually "リレーション" is used for the translation of "relationship" rather than "関係性" in this context. - "a social network" doesn’t mean "SNS" in this context. - "サービス" ("service") is unnecessary. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 7c1e5230..c3e3fa75 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1022,7 +1022,7 @@ Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/cha グラフデータベースでは、各ノードはレコードに、各アークは二つのノードを繋ぐリレーションになります。グラフデータベースは、多数の外部キーを持つ複雑なリレーションや、多対多のリレーションを表す用途に最適化されています。 -グラフデータベースはSNSなどのサービスの複雑な関係性モデルなどについて高いパフォーマンスを発揮します。比較的新しく、まだ一般的には用いられていないので、開発ツールやリソースを探すのが他の方法に比べて難しいかもしれません。多くのグラフは[REST APIs](#representational-state-transfer-rest)を通じてのみアクセスできます。 +グラフデータベースは、ソーシャルネットワークなど、複雑なリレーションを持つモデルで高いパフォーマンスを発揮します。比較的新しく、まだ一般的には用いられていないので、開発ツールやリソースを探すのが他の方法に比べて難しいかもしれません。多くのグラフは[REST APIs](#representational-state-transfer-rest)を通じてのみアクセスできます。 ##### その他の参考資料、ページ: グラフ From 36e9383a2b462479c9286a7fb9dab40759428cc7 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:25:54 +0900 Subject: [PATCH 19/20] Correct mistranslation in SQL or NoSQL MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "データの多くのTB (もしくは PB)" doesn’t make sense. - "ワークロード" is used for the translation of "workload" rather than "負荷" in this context. - "集中的、大規模なデータ負荷" doesn't make sense. --- README-ja.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README-ja.md b/README-ja.md index c3e3fa75..59722e45 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1063,8 +1063,8 @@ Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/cha * ダイナミックないし、フレキシブルなスキーマ * ノンリレーショナルなデータ * 複雑なジョインをする必要がない -* データの多くのTB (もしくは PB) を保存する -* 集中的、大規模なデータ負荷に耐えられる +* 数TB (もしくは数PB) のデータを保存する +* 非常にデータ集約型のワークロード * IOPSについては極めて高いスループットを示す NoSQLに適するサンプルデータ: From 8bd4ff5c7558f4c7668a108711b32d90b65215f0 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 8 Aug 2019 17:32:00 +0900 Subject: [PATCH 20/20] Correct mistranslation in Database section MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "Abstraction" couldn’t be literally translated in this situation ("概要" ("summary") is not suitable), so substitute with "抽象化すると" ("if you abstract it"). --- README-ja.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README-ja.md b/README-ja.md index 59722e45..04c6b611 100644 --- a/README-ja.md +++ b/README-ja.md @@ -953,7 +953,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 #### キーバリューストア -> 概要: ハッシュテーブル +> 抽象化すると: ハッシュテーブル キーバリューストアでは一般的にO(1)の読み書きができ、それらはメモリないしSSDで裏付けられています。データストアはキーを [辞書的順序](https://en.wikipedia.org/wiki/Lexicographical_order) で保持することでキーの効率的な取得を可能にしています。キーバリューストアではメタデータを値とともに保持することが可能です。 @@ -970,7 +970,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 #### ドキュメントストア -> 概要: ドキュメントがバリューとして保存されたキーバリューストア +> 抽象化すると: ドキュメントがバリューとして保存されたキーバリューストア ドキュメントストアはオブジェクトに関する全ての情報を持つドキュメント(XML、 JSON、 binaryなど)を中心に据えたシステムです。ドキュメントストアでは、ドキュメント自身の内部構造に基づいた、APIもしくはクエリ言語を提供します。 *メモ：多くのキーバリューストアでは、値のメタデータを扱う機能を含んでいますが、そのことによってドキュメントストアとの境界線が曖昧になってしまっています。* @@ -995,7 +995,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、 Source: SQL & NoSQL, a brief history

-> 概要: ネストされたマップ `ColumnFamily>` +> 抽象化すると: ネストされたマップ `ColumnFamily>` ワイドカラムストアのデータの基本単位はカラム（ネーム・バリューのペア）です。それぞれのカラムはカラムファミリーとして（SQLテーブルのように）グループ化することができます。スーパーカラムファミリーはカラムファミリーの集合です。それぞれのカラムには行キーでアクセスすることができます。同じ行キーを持つカラムは同じ行として認識されます。それぞれの値は、バージョン管理とコンフリクトが起きた時のために、タイムスタンプを含みます。 @@ -1018,7 +1018,7 @@ Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/cha Source: Graph database

-> 概要: グラフ +> 抽象化すると: グラフ グラフデータベースでは、各ノードはレコードに、各アークは二つのノードを繋ぐリレーションになります。グラフデータベースは、多数の外部キーを持つ複雑なリレーションや、多対多のリレーションを表す用途に最適化されています。