Anonymous avatar Anonymous committed 40d7d77

relax. drunk.

Comments (0)

Files changed (1)

src/01_why_couchdb.rst

 これらの三方向に直行する観点として、信頼性やシンプルさなどこれまで示したような多くの観点があります。
 このように、異なった方向性や特徴をグラフに描くことによって、システムの特徴を明らかにすることができます。
 
-CouchDB is very flexible and gives you enough building blocks to make system shaped to suit your exact problem. That’s not saying that CouchDB can be bent to solve any problem: CouchDB is no silver bullet, but in the space of data storage it can get you a long way.
+.. CouchDB is very flexible and gives you enough building blocks to make system shaped to suit your exact problem. That’s not saying that CouchDB can be bent to solve any problem: CouchDB is no silver bullet, but in the space of data storage it can get you a long way.
 
-CouchDB Replication
-^^^^^^^^^^^^^^^^^^^^
+CouchDBはとても柔軟であなたの問題を解決するようにシステムの構成要素を提供します。
+これは、CouchDBはどんな問題でも解けるという意味ではありません - 銀の弾丸ではありませんが、
+一般的には、データストレージの道のりは長いものです。
 
-CouchDB replication is one of these building blocks. Its fundamental function is to synchronize two or more CouchDB databases. This may sound simple, but the simplicity is key to allowing replication to solve a number of problems: reliably synchronize databases between multiple machines for redundant data storage; distributing data to a cluster of CouchDB instances that share a subset of the total number of requests that hit the cluster (load balancing); distributing data between physically-apart locations, like one office in New York and another one in Tokyo.
+.. CouchDB Replication
 
-CouchDB replication uses the same REST API all clients use. HTTP is ubiquitous and well understood. Replication works incrementally, that is, if during replication anything goes wrong, like a dropping network connection, it will pick up where it left off the next time it runs. It also only transfers data that is needed to synchronize databases.
+CouchDBのレプリケーション
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-A core assumption CouchDB makes is that things can go wrong, it is designed for graceful error recovery instead of assuming all will be well. The replication system’s incremental design shows that best. The ideas behind “things that can go wrong” are embodied in `Fallacies of Distributed Computing <http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing>`_:
+.. CouchDB replication is one of these building blocks. Its fundamental function is to synchronize two or more CouchDB databases. This may sound simple, but the simplicity is key to allowing replication to solve a number of problems: reliably synchronize databases between multiple machines for redundant data storage; distributing data to a cluster of CouchDB instances that share a subset of the total number of requests that hit the cluster (load balancing); distributing data between physically-apart locations, like one office in New York and another one in Tokyo.
 
-#. The network is reliable.
-#. Latency is zero.
-#. Bandwidth is infinite.
-#. The network is secure.
-#. Topology doesn’t change.
-#. There is one administrator.
-#. Transport cost is zero.
-#. The network is homogeneous.
+CouchDBのレプリケーションはこのような構成要素のひとつです。レプリケーションの根本的な機能は、二つ以上のCouchDBデータベースを同期させることです。
+簡単に聞こえるかもしれませんが、シンプルだからこそレプリケーションが数多くの問題の解決となっているのです。
+(1)冗長構成のデータストレージのための複数マシン間でデータベースを信頼できる方法で同期するのです。
+(2)データをCouchDBクラスタに分散することで、リクエストの総数を分散することができます(ロードバランシング)。
+(3)データを物理的に異なるロケーションに配置することができます。たとえば、ひとつはニューヨークのオフィスに、もうひとつは東京に、といった具合に。
 
-Existing tools often try to hide that there is a network and that any or all of the above conditions don’t exist for a particular system. This usually results in fatal error scenarios when finally something goes wrong. Instead CouchDB doesn’t try to hide the network, it just handles errors gracefully and lets you know when actions on your end are required.
+.. CouchDB replication uses the same REST API all clients use. HTTP is ubiquitous and well understood. Replication works incrementally, that is, if during replication anything goes wrong, like a dropping network connection, it will pick up where it left off the next time it runs. It also only transfers data that is needed to synchronize databases.
 
-Local Data is King
-~~~~~~~~~~~~~~~~~~
+CouchDBのレプリケーションはクライアントが使うものと同じREST APIを使います。
+HTTPは普遍なのです。レプリケーションはインクリメンタルに実行されます。
+もしレプリケーション中に何かがおかしくなった場合には、 - 例えばネットワーク切断など - 次回は失敗したところから再開します。
+データベースの同期に必要なデータだけを転送します。
 
-CouchDB takes quite a few *lessons learned* from The Web, but there is one thing that sucks about the web: latency. Whenever you have to wait for an application to respond or a website to render you almost always wait for a network connection that isn’t as fast as you want it at that point. Waiting a few seconds instead of milliseconds greatly influences user experience and thus user-satisfaction.
+.. A core assumption CouchDB makes is that things can go wrong, it is designed for graceful error recovery instead of assuming all will be well. The replication system’s incremental design shows that best. The ideas behind “things that can go wrong” are embodied in `Fallacies of Distributed Computing <http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing>`_:
 
-Worse: what do you do when you are offline. This happens all the time, your DSL or cable provider has issues, your iPhone, G1 or Blackberry has *no bars*. No connectivity, no way to get to your data.
+CouchDBの根底にある前提は、物事は失敗するという点です。何もかもが正常であることを期待するのではなく、エラーに対して寛大になり回復を試みます。
+レプリケーションシステムのインクリメンタルな設計が最適なのです。
+「物事は故障する」という考え方は `Fallacies of Distributed Computing <http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing>`_ にあります:
+
+#. ネットワークは信頼できる
+#. レイテンシは0である
+#. 帯域は無限大である
+#. ネットワークは安全である
+#. トポロジーは不変である
+#. 管理者は一人である
+#. 転送コストは0である
+#. ネットワークは対称である
+
+.. Existing tools often try to hide that there is a network and that any or all of the above conditions don’t exist for a particular system. This usually results in fatal error scenarios when finally something goes wrong. Instead CouchDB doesn’t try to hide the network, it just handles errors gracefully and lets you know when actions on your end are required.
+
+既存のツールはネットワークが存在して、上記の条件を隠蔽してしまう場合がしばしばあります。
+これはふつう、結局何かがおかしくなってしまう致命的なエラーシナリオに至ってしまいます。
+CouchDBではネットワークを隠蔽せず、エラーを寛大に処理して、あなたがどのような対処をとるべきかを知らせてくれます。
+
+.. Local Data is King
+
+ローカルデータこそ重要
+~~~~~~~~~~~~~~~~~~~~~~~
+
+.. CouchDB takes quite a few *lessons learned* from The Web, but there is one thing that sucks about the web: latency. Whenever you have to wait for an application to respond or a website to render you almost always wait for a network connection that isn’t as fast as you want it at that point. Waiting a few seconds instead of milliseconds greatly influences user experience and thus user-satisfaction.
+
+CouchDBはWebからいくつかの *教訓* を得ていますが、Webの残念なところがひとつだけあります。
+それはレイテンシです。あなたは、アプリケーションが反応してウェブサイトを再描画して、
+そこで待ちたくないけどネットワーク接続を待ってしまいます。ミリ秒のかわりに数秒待つのはユーザエクスペリエンスや顧客満足度に強く影響することでしょう。
+
+.. Worse: what do you do when you are offline. This happens all the time, your DSL or cable provider has issues, your iPhone, G1 or Blackberry has *no bars*. No connectivity, no way to get to your data.
+
+さらに、オフライン時に何をしているか、です。これは常に起こりえます。あなたのDSLまたはケーブルテレビ回線のプロバイダが問題を持っていれば、
+あなたのiPhoneなどのケータイは *アンテナが立ってない* 状態の場合、自分のデータに一切アクセスできなくなってしまいます。
 
 CouchDB can solve this scenario as well and this is where scaling is important again. This time it is scaling down. Imagine CouchDB installed on phones and other mobile devices that can synchronize data with centrally hosted CouchDB’s when they are on a network. The synchronization is not bound by user interface contraints like sub-second response times. It is easier to tune for high bandwidth and higher latency than for low bandwidth and very low latency. Mobile applications can then use the local CouchDB to fetch data and since no remote networking is required for that, latency is low by default.
 
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.