「これらの再バランスの処理は、ツリーの一部(sub-trees)を新しいディスク上の位置に移動させることによって、ツリーの構造を完全に変えてしまうことになります」。ここで、もしあなたが「再バランス」が大量のデータ移動を引き起こしてしまうと考えているならば、それは間違いです。repeats.B-treeにおいて重要な操作はノードの分割です。あなたが想像した通り、ノードの分割は、そのノードに保持すべき新しいエントリが入り切らなくなった時に発生します。理解するために、100回INSERTする度に発生すると仮定しましょう。ノード分割は、新しいノードを割り当て、インデックスエントリの半分を新しいノードに移動させ、新しいノードを以前のノード、隣のノード、および親ノードと連結します。これこそが、LehmanとYaoが多くのロックを削減した部分です。場合によっては、親ノードがいっぱいで新しいノードをすぐに親ノードに追加できない場合があります。その場合、親ノードが分割され、同じようにすべてが繰り返されることになります。disk.最悪なケースでは、ノード分割はルートノードまで伝播していき、同じようにルートノードが分割され、新しいルートノードがその上に配置されます。この場合のみ、B-treeはその階層が深くなるのです。ルートノードの分割は実際、ツリーを下方にシフトさせることでそのバランスを保ちます。この処理は多くのデータ移動を伴うものではありません。最悪の場合には、各階層で3ノード、および新しいルートノードにアクセスします。実際の世の中のほとんどのインデックスは、5階層以上にはならないということです。10億回のINSERTに対して5回くらい起こる、ということです。その他の場合には、ツリー全体を上がっていく必要はありません。このように、インデックスのメンテナンスというのは「定期的」なのではなく、非常に頻繁に発生しているものであり、ツリー全体の構造を完全に変えてしまうようなものでもありません。少なくとも、ディスク上の物理配置については。物理ログを使ったレプリケーションです。元の記事がインデックスの「再バランス」の件に触れたのは、UberがPostgreSQLのレプリケーションで、下流のレプリカにおけるデータ破壊を引き起こすバグを踏んだからです。9.2では、コア(本体)では物理ログを使ったレプリケーションだけを提供していますので、レプリケーションのバグは「インデックスツリーの大部分が完全に壊れているという状況を引き起こしうる」ものです。詳細に言うと、ノード分割が間違ってレプリケーションされると、二度と正しい子ノードを指し示さなくなってしまい、ツリーの一部が壊れた状態になります。これは、その他の「もしバグがあったなら、悪いことが起こるでしょう」という話と同じで真実のように聞こえるものです。ツリー構造を壊すには、多くのデータを書き換える必要はあなく、ただひとつの間違ったポインタだけで十分なのです。amplification)によるものを含む―、および新しいPostgreSQLバージョンへのアップデートの際にダウンタイムを必要としていること、などです。前者については納得がいくものですが、後者については私にはコメントできません。query.最後に、元記事は「PostgreSQLはレプリカで真のMVCCをサポートしていない」と苦情を述べています。ラッキーなことに、元記事はその問題を解説した(そして改善した)PostgreSQLのドキュメントにリンクを張っています。この問題は、基本的にはマスターというのはレプリカが何をやっているか知る由もない、つまり、レプリカがクエリを完了するために必要としているデータを、(マスタが)削除するようなことがあり得る、ということです。設定したタイムアウトに達するまで、レプリケーションストリーム(ログ転送)を生成しているアプリケーションを遅延させることで、(※訳注:レプリカで)実行されている読み取りトランザクションが完了できるようにする。(※訳注:レプリカ上の読み取り)クエリが指定した時間内に完了しなければ、そのクエリをキャンセルしてレプリケーションストリームの適用を継続する。レプリカが実行しているクエリについて、マスター側にフィードバックを送るように設定する。それによって、どこかのスレーブで必要としている行のバージョンに対してマスター側でVACUUMしないようにする。Uberの元記事は1つ目の選択肢については規定していますが、2つ目の選択肢についてはまったく言及していません。Uberの開発者のせいにする代わりに。「例えば、開発者が領収書をユーザにメールするコードを書いたとします。どのように書かれたのか、その実装にもよりますが、そのコードでは暗黙的に、メールの送信を完了するまでデータベーストランザクションがオープンされたままになるかもしれません。データベースに関連性のないブロッキングI/Oが実行される間、データベーストランザクションをオープンしたままにするというのは、どんな場合でも悪い状況となるわけけですが、現実的にはほとんどのエンジニアはデータベースのエキスパートではなく、特にオープントランザクションのような低いレベルの問題を引き起こすORMを使うような場合には、これらの問題を常には認識していないでしょう。experts.残念なことに、私は認識しており、この主張に賛同しています。「ほとんどのエンジニアはデータベースのエキスパートではない」と言う代わりに、データベースエキスパートだけではなくSQLに触るすべての開発者がトランザクションについて知っていなければならないにも関わらず、ほとんどの開発者はデータベースについてわずかしか理解していない、と言うことができます。reader.SQLのトレーニングを開発者に提供することは私のメインのビジネスです。あらゆる規模の企業においてこれを行っています。私が言えるひとつ確実なことは、SQLについての知識が尋常でなく低いということです。今言った「オープントランザクション」の文脈においては、開発者たちは、参照のみのトランザクションが実際重要なものである、と多少は知っていると思います。ほとんどの開発者はトランザクションは書いたものを戻すために使うことができる、ということを知っているくらいでしょう。私は、これを説明するスライドを準備している際、度々この誤解に遭遇しますし、その度にこの問題に興味のある読者に向けてスライドをアップロードしているのです。企業がより多くの人を雇うようになると、彼ら彼女らの能力は平均値に近づきます。大げさに言うと、もし地球上のすべての人を雇えば、完全に平均値になります。多くの人を雇うということは、実際にサンプルサイズを大きくする、ということなのです。ベストな人材のみを雇うこと。このアプローチの難しいところは、平均値以上の候補者が見つからない時に待つ必要があることです。平均値の人を雇って仕事をしながらトレーニングすること。この方法は新しいスタッフに対して本当に長いウォームアップ期間を必要としますし、既存のスタッフについてもトレーニングに拘束することになるでしょう。両者に共通する問題は、時間がかかる、ということです。あれば、データベースについてさほど分かっていない平均値の人を雇うしかありません(2014年に実証されています)。急激に成長している企業にとっては、人材よりもテクノロジーの方が取り換えは容易なのです。Uber.また成功要因は、時間の経過に伴って要求が変化するため、テクノロジースタックに影響を与えます。アーリーステージにおいては、スタートアップはすぐに利用可能なテクノロジーであり、彼らのビジネスにおいて十分に柔軟であるものを必要とします。SQLは、本当に柔軟であるからこそ(どんなやり方であれ、データに対して問い合わせすることはできます)、この局面で良い選択肢であり、SQLを多少なりとも知っている人を見つけることはたやすいことです。ほとんどの会社にとって、話はここで終わるのです。仮に緩やかな成功と、ビジネスの成長が実現できたとしても、SQLデータベースの制約の中に健やかに留まっていることになるでしょう。Uberはそうではありませんでしたが。Schemaless.まれにラッキーなスタートアップは最終的にSQLの限界を超えます。それが起こる時、彼らはさらなる(仮想的には無限の?)リソースを利用することができ、そして。彼らは、その一般的な用途のデータベースを彼ら独自のユースケースだけのために開発したシステムでリプレースすることで、多くの問題を解決できることを認識するのです。これこそが、新しいNoSQLデータベースが生まれる瞬間です。Uberでは、それはSchemalessと呼ばれています。moment).現時点では、私はUberは彼らの記事が言っているようにPostgreSQLをMySQLでリプレースしたとは思っていません。彼らは実際には、(現時点では)MySQL/InnoDBで支えられた彼ら独自のソリューションでPostgreSQLを置き換えたように見えます。PostgreSQL.元記事は、MySQL/InnoDBがなぜ彼らのSchemalessのバックエンドとして、PostgreSQLよりも良かったのか、ということを説明しているように見えます。残念ながら、元記事はそのことについて明確にしていません。いうのは、Schemalessを紹介するに当たって、彼らの要件が2013年、彼らがMySQLからPostgreSQLに移行した時と比べてどのように変化してきたのかについて言及していないからです。lousy.悲しいことに、読者の頭の中に残るのは、PostgreSQLがひどい、ということだけです。book.もし、私が説明する諸々を気に入っていただけるのであれば、おそらく私の本(※訳注:日本語版)も気に入ってもらえるのではないかと思います。ありがとうございます。experts.』の部分についてですが、「because」をmacosx付属の英和辞典で調べると、以下のような意味があります。「データベースのエキスパートに限らずSQLに携わる開発者はすべて、トランザクションについての知識を持ってる必要があるのに、たいていの開発者はデータベースの知識をほとんど持っていない」という意味かな、と思いました。(英語に自信があるわけではないので、間違っていたらごめんなさい。18:36:00ありがとうございます。ここの文章、確かに訳すのが難しかった個所のひとつだったんですが、文脈と勢いで訳してました。databases」(否定文)という構造なんですね。「データベースエキスパートだけではなく、SQLに触るすべての開発者がトランザクションについて知っていなければならないにも関わらず、ほとんどの開発者はデータベースについてわずかしか理解していない」ということになるわけですね。ありがとうございます。NagayasuオープンソースRDBMSのPostgreSQLを中心に、データベース近辺からデータセンタ周辺に渡って幅広く回遊するデータマエショリスト。