00:14
はい、ということで、じゃあ、アサイさん、今日もよろしくお願いします。
よろしくお願いします。
はい。
今日は、DDIA本のチャプター6、パーティショニングの回を、みんなで臨読会をしてきた後の収録になります。
今日はですね、ゲストのTomohisa Takaokaさんをお呼びしていて、参加者の一人と、Tomohisaさんをお呼びしていて、一緒に議論をしたので、今回一緒に参加していただきます。
Tomohisaさん、よろしくお願いします。
はい、よろしくお願いします。私は、株式会社J-Tech Japanという日本の会社と、アメリカにあるJ-Tech Creationsという会社、これが兄弟会社で、両方の会社で働いているという感じで、私、今住んでいるのは、カリフォルニア州のロスの近くのロングビーチというところに住んでいます。
で、このLondon Tech Talkを聞いたきっかけがあります。
はい。
私がちょうど、このDDIA本に関する臨読会をやるというのと、この本に関して厚く語っている会というのに、最初に聞きまして、
そっから、ちょうど、臨読会を始めるということだったので、参加させていただいています。
仕事に関しては、小さい会社のCTOという立場で、会社内で使われている技術について、色々調査しております。
はい。
ありがとうございます。
ありがとうございます。
調査したりとか、今一番やっているのは、特にエンタープライズ系の小さいシステムですね、小さい中小企業向けのシステムをイベントソーシングで解決するフレームワークができるんじゃないかということで、その開発をしていて、ちょうどドキュメントデータベースとか、今一番ホットな話題として興味深く聞かせていただいています。
嬉しいですね。ありがとうございます。この輪読会をしたまま参加者の一人と一緒に収録しちゃうっていう、前回からやってますけど、結構楽しいですね、これ。
楽しいですね。面白いですね。
浅井さん、ナイスアイディアですね。
今回はチャプター6のパーティショニングですね。
チャプター6のパーティショニング。今回本のボリューム自体はちょっと短めだったと思うんですけれども、
主にパーティショニングをどうやって、どういうパーティショニングの仕方があるかっていうので、説明があったりとか、
あとはインデックスがどうやって振り分けていくかみたいなとか、リバランシングどうするかみたいな話とか、そういったところを今回パーティショニングで扱われていました。
内容を入る前に一言だけ、輪読会の感想を言ってもいいですか?
03:04
はい、お願いします。
なんか、浅井さんが作ってくれたフォーマットで皆さん読んだ後のテイクアウェイを事前にドキュメントに書くみたいな感じしてるんですけど、
今回のテイクアウェイめちゃくちゃ皆さん細かく書いてくれてですね、
なんか僕最初読んで3行ぐらいポンと書いて終わったんですけど、
輪読会の前に見てみたら、すごいなんか詳細に皆さんね、参考記事へのリンクとか、あと論文へのリンクとか買ってくれて、
なんかこれを読むだけで。
めちゃくちゃ勉強になるというか、なんかこの輪読会に対する熱を感じて、
なんかすごい楽しく参加したパーティション6の会でしたね、今回。
いやー本当に、なんか自分この本読んで、あまり具体的なところがイメージがわからなかったんですけれども、
皆さんのコメントを読むことでかなり具体的に分かることも多かったり、
皆さんの参考にした文献とかを読んで、理解が深まったりしたので、
本当にありがたい。一人で読んでては絶対に。
手に入らない知識があって、すごい良かったですね。
あと6人でやってるんだけど、やっぱり人によって興味ポイントが違うので、
コンシスタントハッシングに興味がある方もいれば、会社で使ってるからということで、
RDSとかPOSGREの分散DBのフレームワーク調べてみたりとか、
友久さんとかはCosmos DBとか、あとイベント送信が絡みでコメントしてくれたりして、
なんかそこの多様性もすごい面白かったですね。
確かに。
そうですね。
みんなよく、
よく準備してくるっていうのが、やっぱり非常に有益なのかなと思って、
多分普通に読んだだけでも、多分1、2時間かかるところだから、
やっぱりちゃんとそれぞれが興味を持って話題を作るっていうのが、
よく準備されていて、ファシリテーターがうまくやっておられるなと思いました。
安西さん、上手です。
ちなみに友久さんは何で読んでますか?
Kindle?オーディオ?
オーディオ?
Kindleじゃなくって、
EPUBですね。
EPUBで購入できるところで購入して、
一応日本語と英語で購入して、
iBooksで読んでるんですけれども、
英語はやっぱりちょっと目で読むスピードが遅いので、
オーディブルで聞きながら英語は斜め読みしてるっていう感じです。
おーすごい。
じゃあ日本語と英語とオーディブルと全部買って、
アーチ先生に献金されたということで。
なんかオーディオで聞くのちょっと流行ってません?
てっぺいさんもオーディオで聞くみたいになってたし、
僕も買っちゃったんですよ、オーディオ。
えー。
実は。
ちなみにいくらくらいで買えるんですか?オーディオ。
4000円くらいかな。
僕はAmazon JPで買いましたけど。
どのくらいでしたっけ?
同じくらいだと思いますね、多分。
06:01
僕は英語のKindleじゃなくて、
オーディオブックス、
ドートコムっていうところで買いましたけど、
20何ドルだったので。
これ本当のところ日本語も欲しいなと思いました。
そっか、日本語はまだないか。
ないかもしれないです。
一応、iPadで、iBookで、ダブルスワイプで読ませるという機能があるので、
それで1ページくらいだったら連続してSiriが読んでくれるっていうのを使って、
なんか聞きながらの方が入ってくるなと。
思ってますね。
なるほど。
これ普通にじゃあ、
アサイさん収録終わったら出版社に連絡してみたらいいんじゃないですか?
自分が収録するんで。
なるほど。
確かに。
それは楽しそうですね。
ないのであればやるっていうのは確かに。
ね。
いいマイクも揃えたし。
確かに。
聞いてみようかな。
ね。
うん。
はい。
じゃあ内容いきます。
どうする?
前回みたいに最初にアサイサマリーが軽く入って、ディスカッショントピックする感じします?
そうですね。
サマリー入れますか。
はい。
じゃあサクッと。
はい。
サクッと。
ってことで、パーティショニング、前回のレプリケーションと繋がってるトピックでありまして、
パーティショニングをすると出てくる問題っていうのがまず紹介されてて、
スキューとホットスポットっていうのがあって、パーティショニングした結果、そのデータの歪みが出てしまう。
このパーティショニングごとのトランザクション量の違い。
トランザクション量の違いとか、データ量の違いみたいな。
が生まれてきて、その結果、さらにホットスポットっていう、10個ノードがあっても1個だけにリクエストを集中しちゃうみたいな。
そういう問題が起きますみたいな話が。
で、その中でキーレンジとかハッシュを使ったパーティションの仕方みたいなのが紹介されていて、そういう強み弱みがあります。
で、さらにそのキーを使ってパーティショニングするので、セカンダリーインデックスはどうやって対応するのか。
みたいな話があったりとか。
あとは、パーティションのリバランシングっていうのがあって、パーティションのサイズにばらつきがあったりとか、ノードごとにサイズが変わってしまったときに、どうやってそのデータをリバランシングするかっていう話で、
パーティション数を固定にするやり方とか、パーティション数を変えて動的にしてやるやり方みたいなのがそれぞれ紹介されていて、これもメリット・デメリットがありますというところ。
しています。
最後に、ごめんなさい、リクエストルーティングの。
最後に、リクエストルーティングがあって、パーティション情報をどこに持たせるかというところで、クライアント側に持たせるのか、もしくはルーティング・ティアーっていうロードバランサーみたいなふうに持たせるのか、ノードに持たせるのかみたいな3つのやり方が紹介されていました。
お二人的に、前回のレプリケーションチャプターと比べてざっくり返していただきました。
はい。
09:00
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
新しい発見もありつつ
割と現場の経験と絡めて
読みやすいとは言わないけど
イメージしながら読み進めやすい
ショーではあったのかな
っていう印象ですね
そう思いますね
なるほどね
今日の
おさえさん的には
テイクアウェイとかどうですか
そうですね
さっきも話ありましたけど
皆さんのコメントとかを見ながら
自分もこの本以外の
ドキュメントとかに当たってみて
どうやって実際に
リバランシングとか
パーティショニングをするのかみたいなのを
読んでいます
一つ例があったのが
PostgreSQLのCytusっていうやつで
そのCytusっていう
PostgreSQLを
パーティショニングする
エクステンションがあるんですけど
そういったものを
読んで
いく中で
こういう風にやっていくのかって具体的に
分かっていって
さらに本の体験的な知識もあって
理解がかなり深まったかなという感じがしました
目線は僕と同じ運営者目線ですよね
SREなのに
そうですね
確かに
一方 友久さんは割と
もうCTOということで
書くこともあれば
設計することもあれば
True Full Stack Engineerみたいな目線で
読まれたという印象で
認識でいいですか
そうですね
でも私たちは比較的小さいシステムっていうんでしょうかね
が多いので
開発者目線の方が強いと思うんですけれども
どうしてもですね
ある程度小さいといっても
何百人何千人で使われるシステムを使ってくると
12:02
どうしてもトランザクションが同時に
かかってしまうので
どうしてもその同時アクセスに耐えるシステムを作ろうとすると
RDBって難しくなってくるなというのがあって
いろいろ調べ始めたっていうのが
それが2、3年前ですね
それでCosmos DBとかDynamo DBに出会って
そこでパーティションっていうのが
それを解決するっていうのが
それを解決するっていうのが
それを解決するっていうのが
それを解決するっていうのが
それを解決するっていうのが
やっぱり必要なんだなっていうのは
やっと分かってきたっていうところで
それがあって読んだので
非常に腑に落ちたっていうんでしょうかね
違うデータベースのように
違うテーブルのように扱うことができるっていうのは
普通にRDBで作って
パーティショニングを使わないで使っていたら
ちょっと考えられないような概念なので
これは非常にうまく使えば
使い勝手があるなと思いましたね
なるほどなるほど
なんかその複数のクライアントさんかユーザーさんが
使ってくれるマルチテナントな一つの
使ってくれるマルチテナントな一つの
大きいサービスを作ってるんですか
それとも複数の別のプロセスで動くサービスを
作ってるみたいな感じなんですか
そうですね
私たちはどちらかというと
顧客に向けて作っていて
その顧客の中には
マルチテナントで運営している顧客もあったり
その顧客の中にはマルチテナントで運営している顧客もあったり
あったり例えば工場を稼働させる のに必要なデータを管理したり
っていういろんなパターンがあるんです けれどもやっぱりユーザーが増えて
きて同時にデータにいろいろアクセス すると開発時には問題が起きない
けれども運用になってから問題 が明らかになるというどうしても
そんな問題がありましてテスト というか開発中は非常に早く動いてる
んだけれども実運用し始めると なんかこの機能遅いなとか時々
500エラーになってこれは困るな みたいなそういうのがあります
ね
あるあるですねそれそこらへん やっぱ分かるのって負荷テスト
とかロードテストの仕組みを入れて 定期的にとかクォーターごとに
入れたりしないと分からないので ローカルでパーティションの設計
するときに
うん
将来のワークロードをイメージ してこんな感じかなみたいな感じ
でスキーマ設計するんですけど 実際にそれが当たるかどうかっていう
のは本番のサービスの成長とか ワークロードとかあとはbotのアクセス
とかねいろんな複合的要素で決ま ってくるので分かんないですよ
ね
そうなんですよね
じゃあマルチテナント系も普通 のスタイルもどっちも経験できる
15:05
っていうのはいいですね僕の会社 はecサイトで
基本的にはマルチテナントでやってる のでいろんなマーチェントさん
が乗ってくれてるって感じでショップ ごとのシャーディングパーティション
っていうのは割と必須というか それを使ってる感じになるんですけ
れども
うん
マサイさんの前職とかどんな 感じでしたマルチテナント違う
か
いやシングルテナントでやって たんでパーティション自体は僕は
経験したことがなくて今回はやっぱり だからこそそんなにイメージが湧き出なかった
っていうところはあるんですけ れども確かに実際自分も運用者側なんで
そのパーティションキーをどうやって 分割するかみたいなところもそんな
に具体的にイメージが湧かない ところがあるんでやっぱりちょっと
開発者目線というかバックエンド とかの開発者目線で実際にテーブル
設計とかしてみてっていうところ を行ったり来たりしないとこういう
ところってうまくやっていけない のかなっていう感じは少ししました
ね
そうですよねいきなりシングルテナント とか経験したことがなくていきなり
必要に応じてパーティションしろ って言われたときにもともと開発者
でずっと経験済んでると多分 裏側の将来的なインフラのスケーラビリティ
の話とかあとどのインデックス を作ったときにどんな制限がある
かみたいなのが最初は見えなくて 逆に運用者から入るとどんなスキーマ
設計にしたほうがサービスの成長 に伴って行動側の変化を変更しやすい
のかみたいなクラス設計みたいな 観点が抜けちゃうのでなんかどっち
の観点もどこかのタイミングで 身につける必要があって開発者
だったらこういうふうにddiみたい に読んでイメージするし運用者
だったら開発者とコラボレーション しながらどっちの意見も吸い上げる
必要があってそういう意味では お互いの観点をブリッジしてくれる
本当にいい章だなと最初に読んだ ときに思ったんですよね
本当そうですね
モニタリングとかもすごい大事 だなっていうのはここで読んで
て思ったんですけどやっぱりこの パーティショニングするにあたって
実際にそのパーティショニング した後にどこに負荷がたくさん
来ているかっていうのが分からない と新しくうまく理屈をさばけない
と思うのでその辺も運用者側として も結構やれることが多いかなと
思います
そうですねなんか今日とか例えば ぜひ収録の方でも話してみたい
のが割とパーティションを切るって 言ってもパーティションの切り方
っていろいろあると普通に適当 なハッシュ関数でも使ってパーティション
18:03
しましたっていうのでは全然実 運用に耐えられなくて話の中でも
本の中でもまず出てきたのがあと ホット
スキューというかサラブレティ 問題有名人問題みたいな感じで
普通に適当なハッシュ関数をして ハッシュしてしまったときに歪み
が生じてしまうっていうのがパーティション あるある問題ですよね例えば
そのツイッターみたいなイメージ だとレディーガガーのユーザー
アカウントに割り当てられたフォロワー フォローイー数のパーティション
は数百ギガになってしまうみたいな 感じででも他の普通の僕らの
一般ユーザーのアカウントは数 数メガバイトぐらいで何かこう
歪みが生じてしまうみたいなそんな ホットパーティションをどう対応
するかみたいな話があってそこに 対して多分ddi絵本が書かれた後
からもいろんな現場でのあとは 研究の発展みたいなのもあったん
ですけどそこら辺についてもちょっと 触れていきたいなと思うんです
がどうしよう最初にcosmos dbとか の
デビュースケースというか仕組み とかだと階層パーティションキー
みたいなのがあったり他の僕が 事前に調べたアリババのケース
とかもいくつかちょっと触れたい なと思うんですけどどうしよう
なんか簡単にcosmos dbについて 棚下さんのほうからちょっと紹介
してもらうことって可能ですか
了解ですcosmos dbは物理テーブル 違う物理
物理パーティション
物理パーティションそうですね 物理パーティションと論理パーティション
に分かれていて論理パーティション はパーティションキーごとに分かれて
いるんですけれどもどうしても 小さいのと大きいのが出てくる
のでそれをどうグループ化する かっていうのは基本的には内部
実装に任されているつまり一つの ものが大きくなったら自動的に
テナント分けをしてくれるっていう そういう意味で非常に使いやすい
と思うんですけれども
でも物理パーティションごとに 結局はリソースユニットみたいな
のが設定されていてこれが実際 何ていうか計算式が公開されている
わけじゃないんですけれどもクエリ をテストで投げるとこのデータ
量でこのクエリだとどれだけ使 えましたっていうのが出てきて
それによって費用が決まってくるん ですけれどもそれの限界というのが
パーティションごとに決められている のでやっぱり有名人問題という
のは結構非常に難しいというところ ですねそれを解決するために提案
されたのが階層パーティション キーっていうのでこれ非常に新しい
21:00
もので発表されたのが今年のマイクロソフト のビルドとかだったと思うので
今年の春ぐらいですね5月6月ぐらい からジェネラリーアベルトで
誰でも使えるようになったんです けれどもそれをすると3つぐらい
のキーを設定してその上位キー 中位キー下位キーそのどれでも
検索したらその必要なところ だけ見るつまり全部のパーティション
をなめる必要がないという意味 でテナントだけでなくてあと2つ
ぐらいのパーティションを開発 者が選考できるようになってきている
ので設計次第ではパフォーマンス が上がるだろうなという感じで
考えています
なるほどこれは結構新しい機能 なんですね
そうなんですそうなんです
これを要望してくるユーザーが 多かったんでしょうねなんか
臨読会のすごい良かったところ 他に元マイクロソフトの中の方
も参加者がいてなんかコスモス dbの話になったときに昔自分の
チームではこんなことしました みたいなそこのやり取りが発生
したのも面白かったですけど なんか
コスモスdbを聞いてて面白いのは 僕はちょっと使ったことないん
ですけどなんかそのクラウドベンダー というかこれ作る側としてはどこ
までユーザーにこうパブリック インターフェースとして渡すか
っていうのが結構ポイントでなんか その要求ユニットruってのをスタッツ
として渡すことによってある程度 見える化させつつでも物理パーティション
とかの設定とかはもちろん隠して カプセル化してそこら辺のどこ
までこうインターフェースとして 出せるかどうかっていうのを考え
ましてどこまでこうチューナブル な設定にするかみたいなのはクラウド
ベンダーとしても開発者として も気になるポイントだと思います
けどそこら辺は実際運用されて てどうですかねこうやってその
階層パーティションキーみたい に新しい機能も定期的に出して
くれてて不満はないって感じですか ね
そうですねやっぱりawsとazure両方 使ってはいるんですけれども私たち
の会社はどちらかというとazure が多くて
そうですね
azureは多分思想としてあんまり 深掘りはさせないというか一番
そのスイッチを少なくしてその 少ないスイッチの中で簡単に使える
というのが非常にやりやすくて 新しい機能を使うときとかもその
知識がすごくなくてもマネージド サービスでなんとかなるという
ものが結構多いのが気に入っている ところでcosmos dbも私も学び始めて
まだ1,2年になってきてそういう のが結構多いんですけれども
結構不満なく使えているなという 感じですね
ソフトウェアのデザインとして はそれが理想ですよねなんかノブ
が多いと困っちゃうので開発者 はできるだけ設定できるものは
少なくしていい感じにしてくれる というのが理想ではありつつも
24:06
cosmos dbとかはないですか
コントロールしやすいというのは awsはやっぱり細かな設定でコントロール
しやすいチューニングしやすい というのが理想ですよね
うんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうん
うん
この雰囲気は3つのパワーワーク
もが12,400はちょっと大きいという のはあるあるなと感じてますね
うん どうしてさのチームでは文揚社
というかはいらっしゃるとも 開発者の方が全部面倒を見てる
わけじゃないですか
そうですねプロジェクトにもよ るんですけれども5人とか10人以 Marines
K drowning이内のプロジェクトが多いの で開発者の中で運用に残ってチューニング
で froze デブオプスまでやってい
やっていく人が残るという感じで
全体的にはチームの中で
立て全部やっているという感じですね
データベースの専門家とかいなくても
なんとかやっていけるようなデータベースということなんですか
そうですね
Cosmos DBの回想パーティションの機になるんですけど
これは今から使っていく感じですか
既に使ってたりします
例えばこの回想パーティションキーのドキュメントとかで
一つ話題にあったのが
どんなキーをパーティションにするかみたいな話で
例えば公式ドキュメントでもレコメンドとしては
カーディナリティがなるべく高いキーを選び
かつ要求ユニット
RUの消費とデータストレージを
全ての論理パーティションに均等に分散する
みたいなことが推薦されています
逆に言うとカーディナリティが低い
例えば
これも話にあったけど
ブーリアンフラグ
トゥルーフォルスみたいなのを選んじゃうと
普通にパーティションが2つになってしまったので
歪みが生じやすいとか
あと全ての論理パーティションに均等に分散できないと
さっき言ったサラブリティ問題みたいなのが出てきてしまうので
こういうレコメデーションがあるんですけど
もし話せる範囲で
現場でこういうパーティションキーを使っててとか
逆にこういうパーティションキーを使おうとしてるんですけど
悩んでてみたいな
ユースケースとか
そういうのがあれば
ここら辺もちょっと込みで話していきたいなと思ってるんですけど
何かありますかね
これがですね
実はイベントソーシングと関係していまして
イベントソーシングっていうのは
グレッグヤングっていう開発者が提唱したもので
集約ごとにデータを分けていって
集約のヒストリーは
全て1つのパーティションに入れるということで
その仕様というか
定義の時点から
パーティションをどう切るかっていうのが
決まっているんですね
基本的には集約IDで分けるっていうのが
基本原則で
そうすると
集約をどういうグループで設定するか
集約というのは
1レコードっていうことではなくて
例えば
カートだったら
27:01
カート自体を1つの集約として
そこにアイテムを追加したり
購入を決定したりするっていう
その複数の処理が1つに入ると
それが集約となります
それごとに分けるので
分け方という点では
イベントソーシングを使っている私たちとしては
あんまり困ることがないですけれども
それだけではなくて
それだけでは
例えばテーブルごとの一覧を出したいときに
全パーティションを見てしまうこととか
テナントに分けてしまったときに
テナントの中でのクエリを発行するときに
全テナント見たら
嫌だなとか
そういうのがちょっと困っていたんですけれども
そこであと2つ
階層パーティションを設定できるということで
逆に言うと
助けられたみたいな感じで考えています
そうなんですよね
こういったデータベースを使うときの
パーティションキーで
どんなクエリを発行するかで
リードのワークロードのライトアウトも
めちゃくちゃ変わってくるじゃないですか
僕も
DynamoDBで1回設計したときには
将来発行しうるクエリのリストみたいなのを
全部書いて
スプレッドシートに全部分けて
それがどんな影響を及ぶしうるか
そのパーティションで
例えば下手なクエリを将来的に投げちゃうと
それを例えば書き込みするときに
すべてのパーティション基本を
書き込まなきゃいけないので
インデックスとも合わせてですけど
っていうのをやったんで
なんか林道会でもコメントありましたけど
まあこういった
Cosmos DBとかDynamoDB使うときに
基本的にワークロードがある程度
予想できる
見えてるものに対して
パフォーマンスを上げるのに使う
でも将来的に見えないときには
RDBMSを使わざるを得ないよね
というかパフォーマンスを切り捨つも
柔軟性を取りに行かざるを得ないよね
みたいな話もありましたよね
そうなんですよね
ここが難しいところで
やっぱりCQRSっていうんでしょうかね
読み込みと書き込みを
別のデータベースにするっていうのは
イベントソーシングでも
勧められていて
基本的な書き込みは
ドキュメントDBに書き込むんですけれども
それを
一気に取り込んで
読み込み用のデータベースを
RDBなどを使って
生成する
グラフDBで生成する
みたいなのを
別DBにすることによって
オーバーロードを分けていくみたいな
ことが推奨されてますね
うん
CQRSってデザインパターンみたいなやつですよね
コマンドクエリ
レスポンシビリティ
セキュリケーション
責任分離ということですね
ちなみにそのパーティションを分割してみて
実際にそのパーティションをまたぐような
30:00
クエリが発行されたりっていうことは
どのくらいあるんですか
アプリケーションによるとは思うんですけれども
それはやっぱり常にありますね
なので
実際に使う必要があるんですよね
そういう場合は
エクスタンスというか
アプリケーションによって
何かいろんな
データを取得しないといけない
とか
そういうのをかなり工夫していかないといけないな
という感じです
どういったパーティションを使ったというのは
ビジネスドメインとかも
結構関わってくると思うんですよね
ECサイトを作るのか
IoTのログデバイスの
デバイスのログを作るのかみたいな感じで
僕も今回の林読家夜景に一つ
最初に
最新のユースケースないかなと思 って見てたんですけど
アリババECサイトですね中国の アリババが面白い論文を2020年に
出しててこれをちょっと簡単に 紹介させてもらいたいんですけど
アリババはマルチテナントでサービス を作っていて要するにいろんな
ECサイトがマルチテナントで動 いてるんですけどもちろん人気
のECサイトと人気じゃないECサイト でスキューが歪みが出てしまう
となのでうまくパーティション していくっていう必要もあるん
ですけど全てのECサイトのワーク ロードを見つつ手動で一個一個
割り当てていくっていうのはもう 限界があるのでいい感じに自動化
したいみたいなのがあったんですね ここら辺は僕らもちょっと普段
悩んでるところではあるんですけど アリババが提唱してたのがダイナミック
セカンダリーハッシングっていう 仕組み
あったんですけどアリババが提唱 してたのがダイナミックセカンダリーハッシングっていう仕組み
あってこれがちょっと面白かったん ですけど発想としてはすごい
シンプルでまず普通のハッシング がありますと普通のハッシング
は一回だけハッシングをして同じ キーは同じパーティションにしか
割り当てられないそれだと有名人 問題みたいなすごい大きいデータ
サイズが一つのサイズノードに 割り当てられてパンクしちゃう
のでその後ダブルハッシングみたいな 仕組みとかも多分回想パーティション
と発想は似てるんですけど二回 ハッシングする
もしくは三回二回三回ハッシング することで大きいものは分ける
みたいな発想があるんですけど ダブルハッシングの問題はすべて
のキーを二回ハッシングしちゃう ので例えば他の有名人じゃない
ような人気じゃないecサイトとか 人気じゃないそのユーザーアカウント
も無駄に二回ハッシングしてしまう ので彼らの普段のワークロード
に対してオーバーヘッドが追加 で発生してしまうんですよねだから
その人気ecサイトのデータをパーティション するっていうものに関しては
前進したんですけど逆にその他の 普通のノーマルのワークロード
に対して更新してしまうということで 発想としてはシンプルで一回の
33:01
ハッシングでいいやつはもう一回 だけハッシングして有名人とか
人気ecサイトみたいな二回三回ハッシング しなきゃいけないようなやつには
自動でそれを二回ハッシングする けどその人気ecサイトのデータを
パーティションするっていうもの に関してはもう一回だけハッシング
するっていうのがダイナミック セカンダリハッシングということで
発想としてはシンプルなんですけど それをアリババは実装したと
そのダイナミックかどうかの判断 にリアルタイムに入ってくるシステム
のログ例えばリクエストのレイテンシー とかパフォーマンスとかを使って
例えばこのサイトecサイト人気 だなじゃあこいつは二回ハッシング
しようみたいなことでハッシング するみたいな論文があったんで
これは面白い
と思いつつも全ての事業とメイン というか全てのサービスにその
まま適用できるシステムでもない なと思ってあとかつこれは多分
アリババの内製システムなんで 今後はもしかしたらこういうの
があるフレームワークもある かもしれないですけどフレームワーク
とかマネジドサービスにコンフィギュレーション 一つで実装されるようになって
くるともう一つまた業界として 進むのかなとか思ってたりはする
かなと思ってこれは面白い事例 でしたね
スマートですねやっぱりログ とか
インアウトの量とかでダイナミック にするっていうのは一番なんか
正しい方法のような気がします
ね
そうそうそこのそのスマートな 本当にスマートなファンクション
を実装できれば最高だと思うん ですけどなかなかそれも何かイテ
レーティブなプロセスだと思います が
パーティションキーはね永遠の 課題ということで
どうですか浅井さん他にもちょっと 触れてみたいディスカッショントピック
とかありますか
話せなかったのはないかな
まあ個人的にやっぱ面白いなと思 ったのはセカンダリインデックス
の扱いの難しさみたいなところ でまあそのキーをもとにパーティション
分けるのでそのキーがプライマリー キーとかユニックキーを使って
まあパーティションを分けると思 うんですけどその結果としてセカンダリ
インデックスが効かなくなる っていう問題が起きてまあパーティション
ことにインデックスが置かれる ローカルインデックスっていうやつ
があってそれだとインデックス を取りに行くのに各パーティション
にアクセスしなきゃいけないっていう オーバーヘッドがあるけれども
一方でグローバルインデックス っていうタームごとのインデックス
を使うことでその問題を解決できる みたいなそういった話もあって
インデックスを一つ取ってもパーティション することでまた変わってくるっていう
のがすごい面白かったですね
コスモスDBにもインデックスはあります か
あるんですねそれが一応インデックス も自動に生成するということになって
36:06
いてよくアクセスされるキーを 自動的にインデックスするということ
になっていて
ちょっとその
それがグローバルなのかローカル なのか探してみたんですけど
今のところ記述がちょっと見つから なかったので聞いている方でご
存知だったら教えてほしいんです けれどもでもそれプラスそれが
うまくいっていないと感じたときに 自分でこのキーについて作って
くださいっていう設定もできる ようになっているのでクエリは
結構早いなというので一応僕も なんかあんまりよく最初理解して
なかったんですけど
ノーsqlというのがsqlダメみたいな そういうふうに最初思っていて
使えないのかなと思っていたら 実はnot only sqlでsqlとさらにプラス
できるっていうのもが最初使う 前は誤解をしていてそういう意味
ではsqlでできることもドキュメント dbでもできるんですよっていう
のは最初から知っておけばもっと ハードル引き上げることができる
と思っています
分かる分かるノーsqlって言われる とねこれはこうrdbmsに対する宣誓
布告かなみたいな感じが思います けど意外と仲良くやってこうぜ
みたいな
そうですね
自動でやってくれるんですね でもクラウドベンダーとしてうまい
ですよね基本は自動でやるけどう まくいかなかったら逃げる道も
ありますよみたいな自分でできます よみたいな
何かないですかクラウドベンダー としてはうまいですよね基本は
自動でやるけどうまくいかなかったら 逃げる道もありますよみたいな自分で
できますよみたいな
実際にrdbmsでもクエリプランみたい なのがあってある程度の統計という
か最適化みたいなのをやってくれる みたいなのをさらにインデックス
までつけてくれるみたいな感じ なんですかね
そうだと思います
すごいですね
多分クエリの実行エンジンが 賢いんでしょうねそれってもし
覚えてたらでいいんですが例えば メトリックスでどこまで分かります
かインデックス使ってるかどうか も分からないってことですよね
多分クエリを投げたときに理想 性に
わかるru次第でしょうねおそらく 思ったよりruが多分まだ運用し始
めてすごくたくさんデータある わけじゃないのであれなんですけ
れどもやっぱりruはやっぱり全体 を見るクエリであると初期のとき
と1年後と2年後とやっぱり量が 変わりますよね
変わってくると思うのでこれは 結構定期的に同じクエリでどれぐらい
ru使うかみたいなのは見ていかない といけないんですけど結構これ
並べ替えっていうのをよくやって いて並べ替えで結構特定のキー
39:03
の小順高順で取得するみたいな それが結構頻発するんですけ
れどもテストデータで使っている 限りは結構その辺はうまくやって
くれるっていうか思ったよりru を消費していないようだったので
この辺はやっぱりインデックス が効いてるのかなと思いました
ね
なるほどじゃあruのカプセル化 っていうのも諸刃の剣ですねそこ
でそれをどこまでストーリーとして 読み込めるかみたいなのがなかなか
実際の運用知見っていうことになって くるんでしょうねそこがね
そう思いますね
ある日突然何か急にlightの
ワークロードがruがめちゃくちゃ 増えてみたいなサポートケース
を投げてみたら複数のパーティション にファンアウトしなきゃいけなく
なってみたいなそういうのとか 普通にありそう
ありますあるでしょうねなので 気をつけないといけないなと思
ってます
うまく動いてる分には最高っていう どのシステムもそうですけどね
これはcosmos dbあんまりazureの会社 で働いたことがなかったんで全然
ノーマークでしたけど面白いな と思って今後ウォッチしてみたい
なと思います
ぜひダイナモdbも対応やってるん ですけれどもダイナモdbはテスト
ケースだけで実運用をまだして いなくてただ同じソフトでセレクティブ
にダイナモでもcosmosでも使える みたいなそういうのを今目指して
開発をしているところです
おーそれは面白そう
僕の知識は古いですけどダイナモ だったら多分lsiローカルセカンダリー
インデックスとグローバルセカンダリー インデックスは自分たちで切んな
きゃいけなかった気がします
いいですねそれは設定しがいが ありますね
そうそうもう設計思想が違います ねcosmos dbという感じかな
ここら辺も結構僕も最初ダイナモ 触ったときにlsiとjsyがあるっていうのが
あったんですけどそれぞれ全然リミテーション も違うのでできることできない
ことも違ってなんで違うんだろう セカンダリーインデックスと同じ
名前だよなってずっと思ってたん ですけどその最初にこのddia本を
読んで答えが全部書いてあった ので目から鱗というか当時の自分
を助けてくれた章でもあったん ですけど思い出深い読み直しながら
それを思い返しましたね
やっぱり結構広範な知識っていう かね具体的な実装がわかるわけ
じゃないけれど
もう広範な知識が書かれている ので使ったことがないdbでもこういう
ところが得意なんだっていうの がそういうのがわかるという点
42:01
でこの本やっぱりすごく勉強になる なと思いましたね
なんかちょいちょいカサンドラ の例とかも出てましたけどもし
ここでデータベースの内部実装 の方に興味が出るみたいな昔の
僕みたいな人がいたら多分次に 読む本としてはデータベースが
インターナルっていうカサンドラ のコミッターの人が書いたオライリン
の本とかもあってそこは実質コード は出てないんですけど次のコンセプト
キーワードが出てたりするので もしリスナーの方で興味がある
方がいればそういった本もぜ ひ読んでみてください
まあパーティション総じてなんか すごい現場の知見とか他のクラウド
サービスの話とか盛り込みつつ なんか全然2回目にしては僕は
学びがめちゃくちゃあったいい 回でしたね
学び多かったですねこういう実際 に実践経験がある方々が何人も
参加されていてっていうのが本 読んだだけではわからない知識
がすごい入ってくるんで自分も 早く実践経験積みたいなと思い
ましたしすごい本当にいい勉強 になりました
いやーそしてまあね次から次トランザクション ですからね頭が重いトピック
が
トランザクションは大きいですね
いやー大きいですよこれ1回でどこ までいけるかちょっとやってみて
だけど
結構本のボリュームもありますね 今回は
次あるよね結構ね
50ページくらい書こう
まあ1回やってみてちょっと消化 不良不良な感じだったら2回目も
フォローアップとかもしてもいい だろうし
そうですね30分ではちょっと足り なそうですねいつも30分でやってます
けど
まあパーティションに関してはこんな ところかなお二人のほうからもう
ちょっと触れておきたいキーワード とかありますか
いや十分話しました
ね十分話しましたということで じゃあ今回はddiaチャプター6の
パーティションについて話しました ということで次回はトランザクション
についてやっていこうと思います
じゃあ今日はゲストとして友久 さんにも来ていただきましたありがとうございました
ありがとうございました
ありがとうございました
ありがとうございました
