#331 データベースの新潮流NewSQLを抑える!
2025/2/19 ·
-
この番組はエンジニアの成長は楽しい学びからをモットーにエンジニアリングに関する学びをワイワイお届けするラジオですはいということで声変わってますかちゃんとえ?変わってましたね
-
配信の時どうなってんだろう感想を聞きたいなんか結局圧縮された同じ感じになってたら切ないですね声質変わってそうな気しますけどどうなんでしょうね別に前のマイクも悪くないマイクだからまあ確かにオンライン収録史上一番よくはあると思いますそうですね物々の家にマイクが来たんではいでは今日なんですけどやっぱりねエンジニアたるものたるもの
-
新しい技術が出てきたらそれをキャッチアップするべきかなと思っておりましておっしゃる通りすぎるグーのでも出ない今撮ってるの土曜日なんですけどちょうどですね木曜金曜で私デベロッパーズサミット羨ましすぎ楽しそうだったなタイムラインがちょっとこれはいつか雑談でも話そうかなって感じなんですけどとりあえずその中で見かけた技術の潮流としてですね
-
結構大きく2つの傾向あるかなと思ってて1個は生成AIを使って開発プロセスがどう変わるかみたいなやつこれは一番多かったかなこれ系がもう1個これも結構注目されてるようなのがあってですねNewSQLちょっと恥ずかしながらマジで知らんすマジっすか初めて聞いたかもしれないですねマジっすか
-
これじゃああのもしかしたらのサービス名とか聞いたことあるかもしれないんですけど 最近話題のタイDBとかお便りとかでも来てましたね来てたかもしれないあれとか実はニューSQLって言われてるジャンルのものなんですけど ちょっと今日はそのお話をしていこうかなと思っておりますありがたいお願いします じゃあもう生成AIの次ぐらいに結構
-
いろんなセッションがあったみたいな感じなんですか言うてそんな多くないんですけどとはいえおのおの全然違うこと話すじゃないですかその中で重複があったってことはやっぱり注目され度高いのかなっていう確かにセッションの内容的にはミックさんってデータベースの本をよく書いてる方がいらっしゃいましてその方が結構ニューSQLについて紹介しててですね
-
非常にわかりやすかったのでとっても参考にさせていただいて今回用意してます素晴らしいなデブサミの資料とかはまだ参考になるものがあるなと思ってるんで機会があれば紹介したいですねですねちょっとスライドまだ見つけられなかったんで手元のメモから
-
書いていったんですけどすげーなそれちなみにデブサミって年一とかでやってる感じなんですか?年一ですねそうなんですね派生系のデブサミなんちゃらかんちゃらみたいなのが他にも何回かやってるイメージあるなるほどありがとうございます場所は画城園でやっておりましたねホテル東京の和風のホテルでいっちゃいいホテルのイメージがある目黒の
-
規模的にどんなもんなんですか何人何千人何千人規模だと思うすげえ多分何千人規模ですねガジョンってあそこでしたっけAWSとくっついてるとこですかそうAmazonの人だったわAWSじゃねえAmazonだわ近くに会場の近くにレストランみたいなとこあったんですけど
-
ちょっとここでランチしちゃおうかなと思ってハンバーガー見たら3000円くらいしてですねいや目黒だなちょっときついと思ってラーメン食いに行きましたね大丈夫ですかラーメン5000円くらいしませんでしたラーメンは外行ったんで1000円くらいでしたちょっとこのニューSQLってそもそも何なのよっていうところからなんですけどその前にですねこれまであるデータベースといえばRDBとノーSQLだったじゃないですか
-
はいはいもうSQLかNOかまあそうすでに民主な気はしますけどそうなんですようんでちょっとそれぞれの特徴ってちなみにじゅんぺいくんどんなのあったかわかりますか出たこれあの懐かしいですねあのオフ会ではいやったと思うねあやったっけこの問題でしたオフ会で出てきたかもしれないねこれはいうんうわーRDBがはいリレーショナルデータベースでうん
-
基本的にテーブル構造を持っていてそこら辺をつなげながらデータを取得してきたりする構造化されたやつっていうんですかねノンSQLが当時の説明思い出せないノットオンリーSQLの略拡張性?柔軟?
-
な構造を持てるみたいなので一般的なのがJSONみたいな形式でみたいなJSONかとかが結構一般的で直で値を取得しに行けたりする使いやすいのかなちょっと分かんないですけど用途によりますがそんなやつでいいですか絶妙なラインの回答ちょっと成長したかな
-
ちょっと成長したほうじゃとりあえずRDBの特徴としてはまずスキーマの定義ができるテーブル作れるよねとかそれによって無駄なくデータ保存できるしあと特徴的なのが一貫性あるデータが保証できるってところですねトランザクションとかで要は整合性取れたデータ扱えるというか一方ですね弱点があって水平に分散しにくいんですよ
-
水平に分散しにくい上からギューって押して伸ばすとかじゃないよそうだよ漬物石とか乗せないからね違うんですかサーバーの台数を増やしてスケールしにくいこれ何でかっていうと実は読み込みだけだったら結構簡単にできるんですよ一方書き込みを水平に分散するのってめっちゃ難しくてですね
-
例えばサーバー100台あって全部書き込めますよってなった時にユーザーが何かの操作して1台書き換わるじゃないですかあとの99台まで保証するのめっちゃ大変じゃないですかうん確かに一方読み込みは簡単でもしデータが変わらないのであればどっから読み取ってもいいから大丈夫じゃないですかなのでデータベースでよくスケールする時ってリードレプリカみたいなやつ作んないですかあったかー
-
書き込みは1台だけにして読み込みのできるデータベースをめっちゃ増やして分散するみたいなそういうのやったことないかもしれないプロダクトでもなんかのなんでしたっけひまプロのエピソードでもなんかありましたねそれひま寿司でやんなかったっけひま寿司はいお寿司握りショーみたいなやつあれ結構印象的ですね
-
そういうのがあって水平に分散しにくいよっていう特徴がありますともう一個ノンSQLの方に関して言うとスキーマとかは定義できなくて比較的タイプによっていろんなデータの保存のされ方があり特定のユースケースではすごいパフォーマンス発揮するしあとは水平に分散しやすいという特徴があったんですね今回出てきたそのニューSQLっていうのが
-
ノーSQLとかのいいところも取ったRDBみたいな感じですどういうこと?どうやったらできるのそんなこと?これがねちょっとこの後のエピソードにも出てくるんですけどまずなので特徴をちゃんと言うとまずはスキーマ定義できてSQLで操作できますよとしかもアシット保証トランザクションとか貼って整合性保つことができますよと
-
今のところRDBですよそしてその上で水平方向にスケールすることができますよというなんで?そういうデータベースでございますだからすごいっていうちょっと難しいですね不思議だな仕組みが知りたいなつまりRDBってめっちゃいろんなケースで便利だったんですよただどうしてもスケールしにくいっていう弱点があったんですけどそれを克服できたデータベースって感じですねすごいもうRDBいらんやんそう
-
そうとか言ったけどそうでもないかもしれないそうなんだちょっとデメリットとかも後で紹介していくんですけど一旦ですねじゃあこれなんでそもそもスケールできるようになったのということで実はこの書き込みをスケールする際って分散合意アルゴリズムっていうやつが結構大事なんですねブロックチェーンみたいな感じなんですか
-
そう言われるとそうかもしれないちょっと絶対細かい仕組みは違うんでしょうけど全部の台数で合意して処理を進めていかないと順番ミスったりして整合性取れなくなるよねとかそういうことだとは思うかつてアルゴリズムでパクソスっていうのがあったんですよ知らないどなたですか
-
アルゴリズムで韓国人パクソスってことソスはいないけど多分そのパクソスっていうアルゴリズムあったんですけどこれ弱点があってですねめちゃくちゃ難しかったらしいんですねはちゃめちゃに難しかったですかなんかプロのすごい人がちゃんと読んでも固まってしまうぐらい難しかったらしい分かりやすい指標ですねこれ以上ない
-
プロのすごい人が見て固まっちゃうわそれすごい難しいわそれぐらい難しかったんであんまり普及しなかったんですよだけどそれがですね新しいアルゴリズムとしてラフトっていうのが出てきてこいつが結構直感的に分かりやすくてその登場によって一気にニューSQLっていうものの製品の実装が進んでいったっていう背景がありますこのラフトっていうのがですね
-
すっごいわかりやすいアニメーションのサイトがあるよってミックさんが言っててさっきそれを見ててすっごいわかりやすかったんですよなのでそのリンクは概要に貼っておくんですけどあれを口頭で説明しきる自信が全くないんですよなるほどポッドキャスター失格じゃないですか一応大きな要素としては2つあって1個は選挙っていう
-
エレクションっていうのがあってまずですねラフトで複数サーバーに分散できますよって言ったじゃないですかこれそれぞれのノードにおいて役割を持たせてるんですねリーダーっていう読み込みじゃなくてLの方引っ張ってくやつチェゲバラみたいなやつが一個とあとは他はフォロワーっていうやつ
-
あとはリーダーが消滅した時にキャンディデートっていう候補者っていうロールが出てきてこれらのロールがアルゴリズムの中で切り替わりながらうまく協調動作してますよとなんかあれですねちょっと言い方古いんですけど文語のマスタースレーブ構成みたいな文語のマスタースレーブ構成よくわかんないわ俺リーダーライターみたいなのだっけななんだっけな
-
やべえ適当なこと言ってるわでもマスター死んだらスレーブからマスターに昇格してみたいなそういうのは似てるなと思いましたそれ系かもしれんまずリーダーが基本的には強い権限を持ってコントロールしますよとクライアントからのリクエストとかを受け取ってそれをフォロワーに受け流したりするみたいなよくわかってないんですけど
-
なんだルーターみたいなことですかそれっぽいわもちろんそのルーター自身も書き込まれるからちょっとニュアンス違うっちゃ違うんですけどプレイングマネージャーってことですかプレイングマネージャーだねそうなんだなんでそんな複雑なことしてんだろうなまあいいや切り替えれるようにするためかな多分
-
そもそも一貫性保つ必要あるんで全員がリーダーみたいなことしたら絶対保てないじゃないですかAが何かやってる間にBが違うことしたらみたいなことが起きちゃうんでなので基本的にはリーダーがリクエストを受け取ってコントロールしてますよとフォロワーは応答するだけリーダーって実は常にハートビートっていうのを送っててハートビート俺生きてるよって
-
よく見るんですね監視周りでは確かに確かに死活監視とかでよく使うよね多分そのハートビートと多分送ってるもの違うとは思うんですけどそういうのをノード間で送り合ってますよとでそのハートビートを受け取れなくなった時にエレクションっていうのが始まるんですね選挙受け取れなくなったのはフォロワーですかフォロワー
-
フォロワーで受け取れなくなったら選挙が始まるんですねリーダーはまだいるがリーダーはいないハートビート来なくなったってことは多分リーダー死んだそういうことかフォロワーはリーダーからのハートビートを受け取っててリーダーからリーダーの冷圧が消えたってなったらじゃあ俺がやるよって選挙始まるってことね
-
わかりやすいその時がキャンディデートっていう状態ですね候補者キャンディデートは即座に投票APIを違うなRPCか投票RPCっていうのを使って他のメンバー全員にですねリクエストを送信するんですね俺がやるよって
-
今ダチョークラブ状態ですねただここでダチョークラブじゃない点としては受け取ったメンバーはあいつがリーダーだってなっちゃうところなっちゃう?どういうこと?言ったもん勝ちですか?先に気づいたやつがリーダーになるってこと?アニメーション見た感じだとタイムアウトするタイミングが微妙にずれててノード感で設定が違うのかそれとも受け取るのに時差あるからそうなってるのかちょっとあれなんですけどうん
-
そのキャンディデートが冒頭なんちゃらかんちゃらRPCみたいなのを送ってそれを受け取ったらあいつがリーダーだってなってみんながそっち向くみたいなめっちゃ愉快な集団じゃないですかリーダーしなーどうしようでも俺が一番早く気づいたから俺がリーダーやるいいよーってことですよねそんな感じ
-
多分同時に起きちゃうこととかもあるからそういう場合とかは再選したりとかもあるらしいリーダーが決まったら次はまたリーダーがハートビート全員に送りますとそのハートビートを受け取ったら受け取ったタイミングで他の人たちがリーダーの情報を更新してフォロワーに戻るみたいな感じっぽいなめちゃめちゃ伝わってるわこれが選挙の仕組みですね
-
面白いもう一個はログレプリケーションといってこれは多分トランザクションの仕組みなんですけど例えばリーダーが書き込みのリクエスト受け取りましたフォロワーに発信しましたフォロワーが返ってきました合意取れたら書き込みするっていうやつ要は全員に確認取ってから書き込むよねみたいなところがログレプリケーションですねっていうのをはい
-
いいですか質問ログの確認というかやっていいっていう確認はリーダーが先導してやるんですかこの書き込みリクエストが来たぜってフォロワーに投げる結構パワープレイですね書き込みの整合性むずいとか言いつつもマルチリージョンでレプリケーションしてるのはむずそうだなマルチリージョンとかどうなるんだろうそこはもしかしたら製品のアーキテクチャとかによるのかもしれない
-
もしくはそうならないようなうまいことをやってるのかなそこは分からんなそうですねというのでその2つを組み合わせているアルゴリズムがラフトって呼ばれててこいつの登場によってすごいいっぱい実装が進みましたよと現在主要プレイヤーがいくつかいるんですけど結構有名なやつだとクラウドスパナーとかGoogleが出している
-
Googleクラウドの製品ですかそうですこれはさっきラフトが登場してめっちゃ実装されたって言ったんですけどこれはPaxosが使われてるらしいですGoogleの人すごすぎて実装できちゃったんだと思うあと日本に出てきてないらしいんですけどコックローチDB出たゴキブリですか名前だけ知ってる強そう
-
そうなんだなんでそんな名前つけたんだろう大量に繁殖するからかなだってさもしそうだとしても優秀な製品だったとしてもさちょっと嫌じゃないですかわかるアイコン見たんですけどしっかりゴキブリでしたからねうわーなんでそんなことしちゃうんでしょうね確かにインパクト強すぎますねインパクトあるね覚えたな多分でこれネットフリックスとかが使ってるらしいですねへーうーん
-
あとはどこが使ってるか分かんないですけどUgaByteDBUgaByteとかあとはさっき出てきたTyDBあと12月にあった2024年の12月にあったのリインベントで発表されたそうなんですけどAuroraDSQLとかもAuroraDSQLAuroraDBみたいなのありましたよねAuroraはねもともとRDSの
-
MySQL互換のあるデータベースですね分散しやすいみたいな分散というかスケールしやすいみたいな感じで出てきたけどそれのAurora DSQLっていうニューSQLバージョンもあるらしいですねDって何のDなんですかねディストリビューテッドじゃない分散型分散された素晴らしい推理ですね合ってるか分かんないけどとかあとオラクルでも実は実装が進んでるらしいですへー
-
そんなにいっぱいあるんですねこれどういうユースケースがあるのかっていうところなんですけどとにかく大量のリクエストがある場合ちょっとこれアメリカの事例の話されてたんですけどドアダッシュっていうなんだっけなあれUber Eatsみたいなサービスって言ってたかな名前的にそんな感じするかもしれない結構大きいサービスらしいんですけどコロナの時にめっちゃ
-
リクエスト増えるようなサービスのローンチがあってその時にどうしても在庫の更新がずれてしまうみたいな問題が起きたらしいんですねリクエスト増えすぎてその時にコクロチDBとカフカっていうストリーミングのストリームデータを扱うサービスかなを使ってほぼリアルタイムで在庫ステータスの反映ができるようなシステムを構築した結果120万QPSって言って
-
秒間で120万クエリを捌く仕組みを作ったりとかまあ秒間?秒間でまあ120万マジでさ付加試験どうやってるんですかねそういうのわかんないすげーなとかあとちょっとこれ本来多分ニューSQLが想定してた使い方じゃないと思うんですけどDMMとか実はこれ導入したらしくて
-
もともとMySQLとCouchbaseとCassandraを使って3種類のデータベースを使ってシステム構築してたらしいんですねそれをNewSQLに集約することによってそもそも3種類のデータベースに精通しているメンバーを集めるの大変だったっていう問題を解決したとかそもそもNewSQLに精通しているメンバーはどうしたんでしょうねNewSQLはあれじゃないインターフェースほぼRDBだから
-
やっぱそうなんだ特にタイDBとかMySQL互換とかもあってそんな感じなので使いやすいは使いやすいですね多分キャッチアップコストとかはそんな高くないはず
-
じゃあネックはお金だけなんだな多分いいとこに気づきましたねはいいいとこに気づきましたじゃあちょっとその話してるんです欠点のところも話していくんですけどまずこれ書き込みとかのスループットは上がりますでしょうねただ一個一個のレスポンスタイムまず悪化するんですよ
-
複雑なことやってるからですねまあそうだそうね結局分散してるんでそれはどうしてもかかるよねっていうまあしょうないですねなのでまあそんな何秒も遅れるわけじゃないですけど何ミリ秒単位とかでやっぱ遅れは発生するらしいですねまあまあまあまあそのシステムの規模を考えたらねいいんじゃないっていうあとは割高
-
やっぱり新しい技術で結局研究開発コストとかを回収しなきゃいけないので今のところちょっと高いですねそうですね確かに落ち着いては後で来るだろうけどさらに障害発生した時ちょっと大変っていう結局分散してるんでどこに原因あるかとかを調査するってなった時にデータベースを見なきゃいけない系だと結構調査大変になりがちらしいですね
-
普通はどうなるんでしょうね普通だったら普通のRDBだとDBに障害がありましたトランザクションの途中で何かが起きてデータ壊れてましたっていうのが見つけられるけどそうじゃないとまず見慣れないエラーみたいなのが起きててだからかつての
-
RDBの知識が使えるところと使えないところがあったりするのとかかなあと多分その時どれがリーダーだったのとかもありそうだよねログ残ってそうですけどねさすがに残るか確かにそうかでもとはいえやっぱ分散してたら大変だよねってのがあるらしいですねそうですね大変にはなりそうDBの障害ってどのくらい起きるもんなんですかねどうなんだろう
-
正直それっぽいのを見たことあんまりないかもしれないそうなんですよねハードウェアトラブルめっちゃ使われてるめっちゃ叩かれてるDBとかだったらあるのかもしれないですけどね確かに秒間120万って言いましたっけそのぐらいだったら確かにそりゃ1年間で1年間っていうか1日何万回叩かれてるんだっていうとんでもないよねところだしな僕とか行くよね全然そりゃ壊れるわななるほど
-
というのでこういう欠点もあるから必要じゃない時はRDBの方がやっぱ向いてるんじゃないかなっていう気はするありがとうございます確かにそうですねでかくならないことが想定されてる時だったら多分普通にRDBの方が安いし早いし障害対応も簡単になるっていうところあるんで本当にパフォーマンス問題出てくるとかあとはあれですかねパフォーマンス考えて今ノーSQL使ってるけど
-
それによって新しい機能の実装とかが大変になってるとか機能の回収が大変になってるとかだったら乗せ替えてみたいなことなんですねこれをNewSQL入れるときは大体は最初から入れるんじゃなくてリプレイスするんでしょうねそうだねリプレイス確かにTidyBの場合だったらMySQL互換あるから結構リプレイスもスムーズにいけたりするのかな
-
RDBからだったらいけると思うんですけどノイズキュールからはあれだねノイズキュールからでもしそうですよねそれこそさっきのDMMの話しそうですもんねうん確かにそうだわ想像絶するわどうやってんだろうちょっと謎だね多分職人技がいくつも重なって頑張って変えるしかないと思うんで
-
ありがとうございますすごいなんか理解できましたというので今後の新潮流としてとりあえずでもこのニューSQLは結構来るだろうってことは想定されてるのでちなみに12月昨年2024年12月にちょっと話題になったMixi2ってあったじゃないですか出たMixi2あれはデータベースこれでやって今のところまだ2ヶ月とかですけど無停止でずっと稼働させ続けられてるらしいですね
-
マジでやってる人聞いたことない2,3日ぐらいしか見なかった気がしますねSNSとかは良さそうですね確かに想定よりもめちゃめちゃリクエスト来たらしいんですけどそれでも全然耐えれたみたいなでもすごいなそれはパフォーマンス出るのめっちゃすごいわ特にタイムラインに反映させるみたいなところをすごいこだわってたらしくてすぐにほぼリアルタイムでみたいな
-
その辺とかはすごいチューニングしまくったみたいな感じでしたねへーというのでなんかこういうの久しぶりにやった気がするんですけど割と最近話題になりつつあるニューSQLのお話でございましたありがとうございましたヒマプロはこれからでかくなってくんで心地デイビー使ったほうがいいですからねやったほうがいいね何に?適当すぎるお便り適当すぎるお便り
-
お便りに何万も来るかもしれないねそうねもしかしたらGoogleフォーム裏で使ってるかもしれないですけどねもしかしたら確かにねありがとうございます以上ですじゃあ締めますかハッシュタグひまじんプログラマーでSNSでフィードバック募集してますのでニューSQL周りの情報とか読むといいよみたいな記事ありましたら共有いただけるとありがたいです使ってる人とか
-
そうですね使い勝手とか聞きたいですね本当にこういうめっちゃユーザーいるサービスの話に聞こえてしまうしキャッチアップしておいた方がいいんだけどいざそういう開発ってあんまりないというかその辺のモヤモヤあるよねっていうところであとは
-
ポッドキャスト説明欄からGoogleフォームで番組へのお便り要望感想質問何でもお待ちしてますのでお気軽にお願いしますお願いします各種ポッドキャストプラットフォームでのフォロー高評価もお願いします待ってますノリさんのデブサビ話はどっかでどっかでやる感じでどっかでやりましょうではまた次回バイバイ
-
やめて!ラーのバグ侵入の特殊能力でマスターザブランチが焼き払われたら闇のスパゲティコードと見つけつこをしているじゅんぺうちの心までクラッシュしちゃう!お願い!死なないでじゅんぺうち!あんたがここでクラッシュしたら先方との契約はどうなっちゃうの?ソースコードはまだ修正の余地があるここを耐えればコードを納品できるんだから!次回!納期間に合わず!デバッグスタンバイ!
#331 データベースの新潮流NewSQLを抑える!