climbTweetデータベースはそもそも、なぜ作られたのでしょうか?システム設計上の概念から言えば、変数に入るさまざまな値をプログラムから切り離して、別の場所に保管したほうが便利だったから、なのでしょう。そんな初期のデータベースは、大勢の人が一斉にアクセスするわけでもなく、パフォーマンスや可用性は二の次で、正確性と整合性が何よりも重要でした。パフォーマンスにこだわり出したのは、インターネットが普及してからで、可用性にこだわり出したのはクラウドが普及してからではないでしょうか。クーラーの利いたサーバー室にデータベース専用ホストがあって、バックアップのスクリプトを夜中に自動実行されるように設定して、「週7日24時間稼働!」なんてプレッシャーもなく、古き良きのんびりした時代でした...(遠い目でつぶやく)。トランザクション処理(OLTP)をサポートすることが最重要課題になりました。いつどこで誰がデータを更新するかわからないし、AさんとBさんが同時にアクセスするかもしれません。トランザクションは一度始めたら、誰にも邪魔されずに完結してもらわなければならないし、もし途中で失敗したらロールバックして、元の状態に戻さなければなりません。何事も中途半端はいけません。できないことはできないとはっきり言うのが、データベースでも人間関係でも「整合性」を保ついちばんの秘訣です。話が逸れましたが、つまりACIDがデータベース設計の基本原理です。Out」の記事でも触れたとおり、A(atomicity=原子性/不可分性)C(consistency=一貫性/整合性)I(isolation=独立性/隔離性)D(durability=耐久性/永続性)のことです。クラウドが普及すると、パフォーマンスと可用性が重視されるのはもちろんのこと、データの量も桁違いに増加して、ビッグデータ時代に入りました。Out)が必要になります。横方向の拡張とは、すなわちシステムの分散のことで、そこではCAP定理が考慮されなければなりません。(分断耐性)の3つの保証を提供することは不可能である』とブリュワーさんが言い出したから、「ブリュワーの定理」とも呼ばれます。仮に、データベースが2つのノードにまたがる場合、ノードAとノードBのデータを常に一致させるのがConsistency、ノードAがダウンしてもノードBがサービスを提供し続けるのがAvailability、ノードAとノードBが分断されてもサービスを提供するのがPartition-toleranceです。データベースのような整合性を重視する必要がなかったためにスケールアウトが実現したのであり、ブリュワーさんが言うところの「Consistency」を犠牲にしています。(CAP定理のCを外した)システムです。ちなみに、ブリュワーさんは、昔、日ハムにいた外人助っ人のブリューワさんとは別人です。カタカナは異なりますが、どちらもBrewerで、ビール醸造職人という意味です。Theorem)は一見したらビールの作り方の法則みたいで、それだったら、もっと便利な気が...また話が逸れましたが、要するに、スケールアウトされた分散型データベースはACID原理に準拠しておらず、OLTPはサポートできない、ということになります。データベースを水平パーティションで分割(sharding)して、レプリケーションと二次インデックスで複数ノードに分散するしくみです。データベースも複数ノードに分散するのは自然な流れと言えます。一体、このNewSQLはどうやってCAP定理の壁を乗り越えたのでしょうか?少し話が長くなってしまったので、次回につづきます。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。コメントデータの処理方法の詳細はこちらをご覧ください。WordPress.。