Mercurial > hg > Papers > 2014 > nobuyasu-master

comparison slides/index.html @ 77:bd73f0e1cdd4

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Added slides
author Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp>
date Mon, 03 Feb 2014 08:40:32 +0900
parents
children 04f63b011fee
comparison
equal deleted inserted replaced
76:5c5d71d36c14 77:bd73f0e1cdd4
1 <!DOCTYPE html>
2 <html>
3 <head>
4 <meta charset='utf-8'>
5 <title>分散 Database Jungle に関する研究</title>
6 <script src='slides.js'></script>
7 <style media='screen,projection'>
8 /****
9 * Add your styles here.
10 */
11
12 body { font-size: 175%; }
13
14 .step { color: silver; } /* or hide next steps e.g. .step { visibility: hidden; } */
15
16 .slide {
17 font-family: 'Open Sans', Arial, sans-serif;
18
19 color: rgb(102, 102, 102);
20 text-shadow: 0 1px 1px rgba(0, 0, 0, .1);
21 }
22
23 .slide h1, .slide h2, .slide h3 {
24 color: rgb(51, 51, 51);
25 }
26
27 .slide pre {
28 font-family: 'Droid Sans Mono', 'Courier New', monospace;
29 font-size: 80%;
30
31 padding: 5px 10px;
32
33 margin-top: 40px;
34 margin-bottom: 40px;
35
36 color: black;
37 background: rgb(240, 240, 240);
38 border: 1px solid rgb(224, 224, 224);
39 box-shadow: inset 0 2px 6px rgba(0, 0, 0, .1);
40 overflow: hidden;
41 }
42
43 .slide code {
44 font-family: 'Droid Sans Mono', 'Courier New', monospace;
45 color: black;
46 }
47
48 .slide h3 {
49 margin-top:-15px;
50 }
51
52 </style>
53 </head>
54 <body>
55
56 <section class='slides'>
57 <!-- Add your slides here. Delete or comment out the slides below. -->
58
59 <article class='cover'>
60 <h1>
61 分散 Database Jungle に関する研究
62 <br>
63
64 </h1>
65 <p>
66 大城 信康
67 <br>
68 Feb 3, 2013
69 </p>
70 </article>
71
72 <article>
73 <h3>
74 概要
75 </h3>
76 <small>
77 <p>ウェブサービスにとってデータベースは必須であり、ウェブサービスの規模に比例してデータベースへの負荷も高まる。</p>
78 <p>データベースの処理能力の高さはそのままウェブサービスの質に繋がるため、データベースのスケーラビリティの確保は重要である。</p>
79 <p>スケーラビリティ確保の方法としてデータ分散があるが、分散する方法により性能も変わってくる。</p>
80 <p>我々は、非破壊的構造を用いてデータを表現するデータベースJungleの開発を行った。</p>
81 <p>非破壊的木構造データベースJungleに分散実装を行い、その評価を行った。分散データベースCassandraよりよい性能を得ることができた。</p>
82 </small>
83 </article>
84
85 <article>
86 <h3>
87 ウェブサービスにおけるデータベースの重要性
88 </h3>
89 <p>ウェブサービスへの負荷が高まることは、データベースへの負荷が高まることでもある。</p>
90 <p>データベースの性能が低ければ負荷に耐え切れずサービスはダウンする</p>
91 <p style="text-align:center;">
92 <img src="./images/service_down.png">
93 </p>
94 <p>そのため、データベースにはスケーラビリティが必要</p>
95 </article>
96
97 <article>
98 <h3>
99 スケーラビリティとは
100 </h3>
101 <p>システムが負荷の増大に対して柔軟に拡張して対応できる性質</p>
102 <p>主に次の2つの方法によりシステムはスケールされる</p>
103 <ul>
104 <li><font color="blue">スケールアップ</font>：<br/>高価な単一マシンによる性能アップ</li>
105 <br/>
106 <li><font color="red">スケールアウト</font>：<br/>汎用的なマシンを複数台用意することで性能アップ</li>
107 </ul>
108 <p>分散システムにおいては<font color="red">スケールアウト</font>によりスケーラビリティを高める</p>
109 </article>
110
111 <article>
112 <h3>
113 データベースのスケーラビリティ
114 </h3>
115 <p>データベースのスケーラビリティを考えるとき、どういう用途で使用するかを考えるのが重要。</p>
116 <li>例えば銀行の口座の情報を扱うデータベースは、データの整合性が最優先である。違う値がみられてはいけない。</li>
117 <br/>
118 <p>ウェブサービスにおいても、どのようなサービスを行うかによってスケーラビリティの確保の仕方も変わってくる。</p>
119 <p>本研究で開発しているデータベースはコンテンツマネジメントシステム（CMS）を対象としている。</p>
120 </article>
121
122 <article>
123 <h3>
124 コンテンツマネジメントシステム(CMS)
125 </h3>
126 <p>Webコンテンツを構成するテキストや画像などのデジタルコンテンツを管理し配信するシステム。</p>
127 <li>例：ブログツール、Wiki</li>
128 <p>『分散』コンテンツマネジメントシステムに求められること。</p>
129 <li>Webコンテンツを分散して管理</li>
130 <li>スケールアウトするシステム</li>
131 <p>データ全体の整合性に遅延がある結果整合性でも問題なく。書き込みや読み込みを優先としたデータベースが必要。</p>
132 <p>そこで、非破壊的木構造データベースJungleの提案を行った。</p>
133 </article>
134
135 <article>
136 <h3>非破壊的木構造データベースJungle</h3>
137 <p>JungleはスケーラビリティのあるCMSの設計を目指して当研究室で開発されているデータベース。</p>
138 <p>データを木構造で、さらに非破壊で保持する。</p>
139 <br/>
140 <p>まず、破壊的木構造と非破壊的木構造について説明する。</p>
141 </article>
142
143 <article>
144 <h3>破壊的木構造</h3>
145 <p>木構造の通常のデータ表現</p>
146 <p>破壊的木構造は、木構造により保持しているデータの編集をデータを直接書き換えることで行う</p>
147 <p style="text-align:center;">
148 <img style="height:300px;" src="./images/destructive_tree_slide.png">
149 </p>
150 </article>
151
152 <article>
153 <h3>破壊的木構造</h3>
154 <p>破壊的木構造ではデータの編集中にそのデータを読むことができない</p>
155 <p>編集が完了するまでまたなければならない</p>
156 <p style="text-align:center;">
157 <img style="width:500px;" src="./images/destructive_tree_demerit.png">
158 </p>
159 </article>
160
161 <article>
162 <h3>
163 非破壊的木構造
164 </h3>
165 <p>非破壊的木構造は一度作成したデータは変更しない</p>
166 <p>新しい木構造を作成することでデータの編集を行う</p>
167 <p style="text-align:center;">
168 <img style="height:300px;" src="./images/non_destructive_tree_slide.png">
169 </p>
170 <p></p>
171 </article>
172
173 <article>
174 <h3>
175 非破壊的木構造におけるデータ編集
176 </h3>
177 <p>目的とするノード5ををコピーして内容を編集する。ノード100となる</p>
178 <p>ルートノードから目的のノード5までに続くルートノードとノード2のコピーとりノード100と繋げる</p>
179
180 <p style="text-align:center;">
181 <img style="width:700px;" src="./images/non_destructive_tree_edit.png">
182 </p>
183 </article>
184
185 <article>
186 <h3>
187 非破壊的木構造におけるデータ編集と読み込み
188 </h3>
189 <p>新しく作成したルートノードに変更を加えていないノードへの参照を持たせる。新しい木構造のデータができる</p>
190 <p>最新のルートノードの登録を新しく作成した側のルートノードへと登録する</p>
191 <p style="text-align:center;">
192 <img style="width:700px;" src="./images/non_destructive_tree_edit2.png">
193 </p>
194 </article>
195
196 <article>
197 <h3>
198 非破壊的木構造の利点
199 </h3>
200 <p>非破壊的木構造は通常の木構造である破壊的木構造に比べ、以下のような利点を持つ</p>
201 <ul>
202 <li>一度作成したデータは変更されない</li>
203 <li>データが変更されないため自由にコピーを作ることができる(いつでも読み込みが可能)</li>
204 <li>ロックがすくない。ロックが必要なのは最新のルートノードを登録するときだけ</li>
205 </ul>
206 <p>ロックが少なく、いつでもコピーが可能なことから、非破壊的木構造はスケーラブルなシステムに有用となる</p>
207 </article>
208
209 <article>
210 <h3>
211 Jungleの分散設計:分散版管理システム
212 </h3>
213 <p>Jungleは分散設計を行うにあたってGitやMercurialといった分散版管理システムを意識している</p>
214 <p style="margin-top:-10px;">分散版管理システムとは多人数によるソフトウェア開発において変更履歴を管理するシステム</p>
215 <p style="margin-top:-10px;">分散版管理システムは次の特徴とAPIを持つ</p>
216 <ul>
217 <li>開発者それぞれがリポジトリのクローンを持ち、開発はローカルのリポジトリを通すことで行われる</li>
218 <li>ローカルのリポジトリは独立に存在し、サーバ上ある他人のリポジトリから変更履歴をとることができる。また自身の変更履歴を伝えることもできる</li>
219 <li>データ更新時に先に別の更新が入っていた(衝突)場合はMergeによりデータの整合性をとる</li>
220 </ul>
221 </article>
222
223 <article>
224 <h3>
225 Jungleの分散設計:分散版管理システム
226 </h3>
227 <p>分散版管理システムAPI</p>
228 <ul style="margin-top:-20px;">
229 <li>commit:データに変更を加えたことをリポジトリに登録</li>
230 <li>push:ローカルのリポジトリで行った変更履歴を他のリポジトリへまとめて送る</li>
231 <li>pull:他のリポジトリからの変更履歴をまとめて受け取る</li>
232 </ul>
233 <p style="text-align:center;">
234 <img style="height:200px;" src="./images/distributed_repository.png">
235 </p>
236 <small>
237 <p>分版版管理システムはリポジトリが壊れても別のリポジトリよりデータを復旧できることと、いつでも
238 読み込みが可能なため、高いスケーラビリティを持っている</p>
239 </small>
240 </article>
241
242 <article>
243 <h3>
244 Jungleの分散設計:分散版管理システム
245 </h3>
246 <p>Jungleと分散版管理システムには似通った点がある</p>
247 <li>どちらもデータのコピーが自由</li>
248 <li>データ更新しても過去のデータに影響を与えない</li>
249 <br/>
250 <p><font color="red">同じAPIを実装することで、分散版管理システムと同じく高いスケーラビリティが期待できる</font></p>
251 <p>具体的には</p>
252 <ul>
253 <li>pushやpullによる定期的なデータの更新</li>
254 <li>Mergeによる更新データ衝突の解決</li>
255 </ul>
256 </article>
257
258
259 <article>
260 <h3>
261 Jungleの分散実装
262 </h3>
263 <p>ここまでJungleの分散設計について説明した。</p>
264 <br/>
265 <p>これらのシステムを実装する為にまずはJungleのノード同士でネットワークトポロジーを
266 組み、その上でデータをやりとりする機構が必要になる。</p>
267 <p>そこで、ネットワートポロジーを組みログによるデータの分散を行う仕組みをJungleに実装した。</p>
268 <p>また、Mergeの例として掲示板プログラムにおけるMergeの実装も行った。</p>
269 </article>
270
271 <article>
272 <h3>
273 Jungleの分散実装：ログによるデータ分散
274 </h3>
275 <small>
276 <p>今回Jungleの分散実装は以下のように行った</p>
277 <table>
278 <tr>
279 <th>ツリートポロジーを形成</th>
280 <th>commit log伝搬によるデータ分散</th>
281 </tr>
282 <tr>
283 <td>
284 <img src="./images/tree_topology.png">
285 </td>
286 <td>
287 <img src="./images/distributed_jungle.png">
288 </td>
289 </tr>
290 </table>
291 <p>サーバノード同士でツリートポロジーを形成する。データ編集をどのように行ったのかを示すログ commit log を伝搬させデータの分散を行う。</p>
292 </small>
293 </article>
294
295
296 <article>
297 <h3>
298 Jungleの分散実装:掲示板システムにおけるMerge
299 </h3>
300 <p>Mergeとはデータ更新の衝突が起きた際の解決方法</p>
301 <p>Jungleではアプリケーション毎にMergeアルゴリズムを設計</p>
302 <p>後述する性能比較に用いた掲示板システムにおけるMergeの実装を考える</p>
303 <p>掲示板システムにおけるデータ構造を以下に示す</p>
304 <p style="text-align:center;">
305 <img src="./images/bulletinboard.png">
306 </p>
307 </article>
308
309 <article>
310 <h3>
311 Jungleの分散実装:掲示板システムにおけるMerge
312 </h3>
313 <small>
314 <table style="font-size: 0.7em; width:100%;" >
315 <tr>
316 <td><p>1</p></td>
317 <td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/merge_impl1.png"></p></td>
318 </tr>
319 <tr>
320 <td>2</td>
321 <td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/merge_impl2.png"></p></td>
322 </tr>
323 <tr>
324 <td>3</td>
325 <td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/merge_impl3.png"></p></td>
326 </tr>
327 </table>
328 </small>
329 </article>
330
331
332 <article>
333 <h3>
334 分散データベースJungleの評価
335 </h3>
336 <p>分散データベースとしてJungleの性能を評価する。</p>
337 <p>分散Key-ValueデーターべースCassandraと比較を行う。</p>
338 <p>比較方法は、Jungle, Cassandra をそれぞれバックエンドとした簡易掲示板を作成する。</p>
339 <p>掲示板に対してHTTP Requestで並列に読み込みと書き込みの負荷をかけ計測する。</p>
340 <p>レスポンスが返る平均時間と標準偏差を求めグラフ化する</p>
341 </article>
342
343
344 <article>
345 <h3>
346 JungleとCassandraの比較方法
347 </h3>
348 <p>実験は以下の2つを行う</p>
349 <small>
350 <table style="font-size: 0.7em; width:100%;">
351 <tr>
352 <th>実験1:サーバ単体への負荷</th><th>実験2:複数台のサーバに対する負荷</th>
353 </tr>
354 <tr>
355 <td><img style="width:400px;" src="./images/cluster_request_server.png"></td>
356 <td><img style="width:400px;" src="./images/clients_request_servers.png"></td>
357 </tr>
358 <tr>
359 <td><p>複数のクライアントから単体のサーバへ負荷をかける</p></td>
360 <td><p>複数のクライアントから複数のサーバへ負荷をかける</p></td>
361 </tr>
362 </table>
363 <p>サーバ単体の性能と, 分散環境下における性能の2つを調べる。</p>
364 <p>分散環境下におけるノードは全て繋がっている</p>
365 </small>
366 </article>
367
368 <article>
369 <h3>
370 実験に使用するサーバの仕様
371 </h3>
372 <!--
373 <p>実験1:単体サーバへの負荷で使用するサーバ側</p>
374 -->
375 <table style="font-size: 0.7em;">
376 <tr>
377 <th></th><th>ブレードサーバ</th>
378 </tr>
379 <tr>
380 <td>CPU</td>
381 <td>Intel(R) Xeon(R) CPU X5650@2.67GHz</td>
382 </tr>
383 <tr>
384 <td>コア数</td>
385 <td>24</td>
386 </tr>
387 <tr>
388 <td>Memory</td>
389 <td>132GB</td>
390 </tr>
391 <tr>
392 <td>OS</td>
393 <td>Fedora 16</td>
394 </tr>
395 <tr>
396 <td>HyperVisor</td>
397 <td>なし（物理マシン）</td>
398 </tr>
399 </table>
400 <small>
401 <p style="">並列環境</p>
402 </small>
403 <table style="font-size: 0.7em; margin-top:-20px; ">
404 <tr>
405 <th></th><th>VMWareクラスタ</th><th>KVMクラスタ</th>
406 </tr>
407 <tr>
408 <td>台数</td><td>48</td><td>12</td>
409 </tr>
410 <tr>
411 <td>CPU</td>
412 <td>Intel(R) Xeon(R) CPU X5650@2.67GHz</td>
413 <td>Intel(R) Xeon(R) CPU X5650@2.67GHz</td>
414 </tr>
415 <tr>
416 <td>コア数</td>
417 <td>4</td>
418 <td>4</td>
419 </tr>
420 <tr>
421 <td>Memory</td>
422 <td>8GB</td>
423 <td>8GB</td>
424 </tr>
425 <tr>
426 <td>OS</td>
427 <td>Fedora 16</td>
428 <td>Fedora 16</td>
429 </tr>
430 <tr>
431 <td>HyperVisor</td>
432 <td>VMWare ESXi</td>
433 <td>KVM (Linux Fedora 16)</td>
434 </tr>
435 </table>
436
437 </article>
438
439
440 <article>
441 <h3>
442 実験1:単体サーバへの負荷
443 </h3>
444 <p style="text-align:center;">
445 <img style="width:80%;" src="./images/cluster_request_server.png">
446 </p>
447 </article>
448
449 <article>
450 <h3>
451 実験1：単体サーバへの負荷（読み込み）
452 </h3>
453 <small>
454 <p>ブレードサーバ一台に対して複数のクライアントからの負荷</p>
455 <table style="text-align:center;font-size:0.7em;">
456 <tr>
457 <td><img style="height:350px;" src="./images/bldsv12_read_bench.png"/></td>
458 </tr>
459 <tr>
460 <th style="text-align:center;">読み込みの実験結果</th>
461 </tr>
462 </table>
463 <p style="margin-top:0px;">JungleがCassandraより良い結果を示している</p>
464 <p style="margin-top:-20px;">クライアントが55台のときのJungleの最速とCassandraの最遅は3倍近く離れている</p>
465 </small>
466 </article>
467
468 <article>
469 <h3>
470 実験1：単体サーバへの負荷（書き込み）
471 </h3>
472 <small>
473 <p>ブレードサーバ一台に対して複数のクライアントからの負荷</p>
474 <table style="text-align:center;font-size:0.7em;">
475 <tr>
476 <td><img style="height:350px;" src="./images/bldsv12_write_bench.png"/></td>
477 </tr>
478 <tr>
479 <th style="text-align:center;">書き込みの実験結果</th>
480 </tr>
481 </table>
482 <p>読み込み同様Jungleのほうが良い結果を示している</p>
483 <p>読み込みよりJungleとCassandraの結果が重なる部分が減っている</p>
484 </small>
485 </article>
486
487 <article>
488 <h3>
489 実験1の考察
490 </h3>
491 <p>読み込み、書き込みともにJungleの性能がよく。平均だけみても2倍以上早い部分もある。</p>
492 <p>特に書き込みに関してはクライアントの数が増えるにつれ差が開いている。</p>
493 <!--
494 <p>要因の1つとしてCassandraはディスクへ書き込みを行うが、Jungleは全てのデータをオンメモリで扱っていることもある</p>
495 <p>これはある意味当然だが、もう1つ要因をあげられる</p>
496 -->
497 <p>これはJungleが全体的にロックが少ないことが要因としてあげられる。</li>
498 <p>Jungleは非破壊でデータの保持をするため、読み込みは自由に行える。書き込み時には木のコピーをとりルートノードを入れ替える
499 ときのみロックが発生する。</p>
500 </article>
501
502 <article>
503 <h3>
504 実験2:分散環境下における負荷
505 </h3>
506 <p style="text-align:center;">
507 <img style="width:80%;" src="./images/clients_request_servers.png">
508 </p>
509 </article>
510
511 <article>
512 <h3>
513 実験2：分散環境下における読み込み
514 </h3>
515 <small>
516 <table style="text-align:center;font-size:0.7em;">
517 <tr>
518 <td><img style="height:350px;" src="./images/distributed_read_bench.png">
519 </tr>
520 <tr>
521 <th style="text-align:center;">読み込みの実験結果</th>
522 </tr>
523 </table>
524 <p>CassandraはConsistency Level ONE(赤)とQUORUM(緑)両方を測定</p>
525 <p>Jungleは1秒から5秒をキープ</p>
526 </small>
527 </article>
528
529 <article>
530 <h3>
531 実験2：分散環境下における書き込み
532 </h3>
533 <small>
534 <table style="text-align:center;font-size:0.7em;">
535 <tr>
536 <td><img style="height:350px;" src="./images/distributed_write_bench.png">
537 </tr>
538 <tr>
539 <th style="text-align:center;">書き込みの実験結果</th>
540 </tr>
541 </table>
542 <p>CassandraはConsistency Level ONE(赤)とQUORUM(緑)両方を測定</p>
543 <p>Jungleは5.5秒から7.3秒をキープ</p>
544 </small>
545 </article>
546
547
548 <article>
549 <h3>
550 実験2の考察
551 </h3>
552 <p>こちらもJungleがCassadraより良い結果を示した。実験1よりも差がでている。</p>
553 <p>Jungleのグラフが横ばいになっていることに注目したい。</p>
554 <!--
555 <p>Cassandraはノードの数が増えるに従いデータを取りにいくノードも増えることでレスポンスが遅くなっている。</p>
556 -->
557 <p>Jungleはリクエストに対し手元にあるデータを返す。そのためノードの数が増えてもレスポンスの早さを維持できる。</p>
558 <p>Cassandraはデータを持っている数台のノードに読み込みに行くという作業が入るためJungleより遅くなってしまう</p>
559 <p>Jungleは同期を取らないためデータ全体の整合性は落ちるが、分散管理システムを参考にした設計の有用性を示すことができた。</p>
560 </article>
561
562
563 <article>
564 <h3>
565 まとめ
566 </h3>
567 <p>本研究では非破壊的木構造Jungleに分散データベースの実装を行った</p>
568 <p>非破壊的木構造における利点を述べ、スケーラビリティの高い分散版管理システムとの類似性を述べた</p>
569 <p>Mergeアルゴリズムの1つとして掲示板プログラムにおけるMergeについて設計・実装を行った</p>
570 <p>性能比較の実験のためJungle、Cassandraで利用できる簡易掲示板の作成を行った</p>
571 <p>実験は単体サーバと分散環境下において行い、どちらともCassandraよりよい結果をえることができた</p>
572 </article>
573
574 <article>
575 <h3>
576 今後の課題
577 </h3>
578 <p>push/pull方式による分断耐性の実装</p>
579 <ul>
580 <li>現実装ではJungleはデータ編集が行われた際に発生するログを非同期で他サーバノードへと送信している</li>
581 <li>だがこの方法では接続が切れた際に再接続を行ったノードが全てのデータをとることができない</li>
582 <li>そこで非同期とは別に同期をとり他ノードとに差分となるデータを送るということを行いたい</li>
583 <li>これは分散管理システムにおけるpush/pull APIにあたる</li>
584 </ul>
585 </article>
586
587 <article>
588 <h3>
589 今後の課題
590 </h3>
591 <p>データ分割の実装</p>
592 <ul>
593 <li>現在の実装は全てのノードで全てのデータを持たせている</li>
594 <li>この方法ではメモリの使用量が高いこととネットワーク帯域への負荷が懸念される</li>
595 <li>ノード単位で保持するデータを分ける実装が必要</li>
596 <li>その場合、木構造単位でノード毎にデータを分ける</li>
597 <li>持っていないデータの要求が来た場合は、データを持っているノードに取りに行くようにする</li>
598 </ul>
599 </article>
600
601 <article>
602 <h3>
603 今後の課題
604 </h3>
605 <p>Mergeアルゴリズムの設計</p>
606 <ul>
607 <li>JungleはMergeを使うことで更新データ衝突の問題を解決する。</li>
608 <li>今回実装した掲示板プログラムにおけるMergeは単純なもの。</li>
609 <li>他のアプリケーションではどのようにMergeを行うのか考察が必要。</li>
610 </ul>
611 </article>
612
613
614 <article>
615 <h3>
616 今後の課題
617 </h3>
618 <p>過去のデータの掃除について</p>
619 <ul>
620 <li>Jungleは非破壊でデータを保持するため過去のメモリの使用量が大きい</li>
621 <li>ある程度の単位で過去のデータの掃除を行いたい</li>
622 <li>そのためにはどのノードがどのデータを持っているかという情報を扱うことが必要</li>
623 <li>どれくらいデータが古くなると掃除を行うか判断が必要</li>
624 </ul>
625 </article>
626
627 <article>
628 <h3>
629 </h3>
630 <p></p>
631 <ul>
632 </ul>
633 </article>
634
635 <article>
636 <h3>
637 分散Key-ValueストアCassandraの特徴
638 </h3>
639 <small style="line-height:30px;">
640 <p>ring型トポロジーを形成。ring上にはHash値があり、書き込むデータのキーのハッシュ値により書き込むノードを決定</p>
641 <p>1つのデータの複製を最大何とるかというReplication factorの設定がある。</p>
642 <p>Consistency Levelというデータの読み書きの際に何台のノードから読み書きするかを決定できる</p>
643 <p>Consistency LevelにはONE,QUORUM,ALLがある。QUORUMはReplication factorの数/2+1 のノードに読み書きする。</p>
644 </small>
645 <p>
646 <img style="margin-top:-30px;" src="./images/consistency_quorum.png">
647 </p>
648 </article>
649
650
651
652 </section>
653
654 </body>
655 </html>