NewSQLとは何か
こんにちは。いつもの雑談、まじめな技術、訳していつまじラジオのJです。
森原です。
今日は第2回ということで、僕がJの方から1つ持ち込みです。
僕の持ち込みですが、年末年始に、NewSQL徹底入門っていう書籍を読んだんで、
それの感想とか、こういうものだよっていう、ちょっとした話をできればなと思っています。
あれさ、僕も読もうと思ってたんだけど、Kindle版だとめっちゃ遅いっていうね。
あ、発売がね。
そうそう。
まだかな、1月の下旬ぐらいだったのかな。中頃から下旬ぐらいだったなと思ったから、
僕もどっち買おうかなと思って、あ、まだねえやと思って、書籍、紙の方を買いました。
でかいの?
いやいや、全然でかくないですよ。
ページ数もそんなになくて、サイズもそんなに大きくない。
ページ数が230とかぐらいかな。
240ぐらいか。240ページだから。
そんなにボリュームもないし、読みやすかったんで、内容も良かったんで、基本的には全員におすすめです。
ニューSQLに興味なくてもおすすめ。
作者がMickさんで、かなりSQL周りの名調を出してる方。
Mickさんと小林孝博さんという方が書いてて、Mickさんが1章、5、6、7章、小林さんが2、3、4章を担当してるみたいですね。
小林さんってあれだ、小説データベースってオライリーの、僕好きな書籍だけど、翻訳してる人だ。
そんなお二人から出ている書籍を読みましたというところですね。
これを今日話すにあたって、ちょっとした注意事項というかですが、
口頭のみの説明なので厳密性に書く説明があると思います。
簡易的な説明を今日はしますので、その点ご了承ください。
発信されるから注意しないといけないな。
説明足りてなくない?みたいな話もあるかもしれませんが、こういった事情です。
じゃあ早速入っていくんですけど、まだNewSQLとは?っていうところから入っていくんですけど、
NewSQLって、僕がNewSQL界隈をウォッチし、軽めにウォッチしだしたせいか、
最近よく見るようになった気がしていますが、
世間的にもちょっとずつよく見るようになったんだろうと勝手に思っているんですけど、
とはいえそんなにまだちゃんと知らないなっていう方も全然多くいるのかなと思うので、
そういった方にとって、こういうもんなんだっていうのを理解してもらえればなと思って話すんですが、
一旦超ざっくりな説明から入ると、
よく言われるものとしては、RDBとNoSQLのいいとこどりっていう話はよくされるかなと思います。
何を持っていいとこどりなのかっていうと、
まずRDBからはスキーマ定義とアシットトランザクション SQLっていうところを取っていて、
NoSQLからはスケーラビリティと効果要性を取っている。
なのでこのスキーマ定義、アシットトランザクション、SQL、スケーラビリティ、効果要性、
こういうところを跳ね備えたものがNewSQLです。
RDBとNoSQLの課題
っていうのが超ざっくりな説明です。
すごいやつよ。
そう、すごいんですよ。
こいつすごいわけですが、登場した背景とかを一旦話せればと思うんですけど、
RDBとNoSQLを軸に振り返っていくんですけど、
RDB自体は古くからあるというところで、その辺の歴史とかはここでは触れませんが、
RDBのスケーラビリティ、特に書き込み性能っていうところに限界を感じ出したっていうのが、
2000年代の中頃から後半ぐらい。
主にはSNSが盛り上がり出したっていうのがその頃っぽいんですけど、
FacebookとかTwitterとかその辺がすごく盛り上がっているっていうところで、
この盛り上がりに比例して書き込みもしんどくなってくるみたいな課題感があったっていうのがRDBですね。
そこから2010年前後にその課題をもとに生まれたのがNoSQL。
NoSQLは分散構成をして水平スケーラビリティを確保していますと。
ただその代わりRDBでする意味であったマシットの整合性とかその辺とかSQLを手放すっていうようなことがありましたと。
NoSQL誕生当初はRDBを置き換えるっていう話もあったようなんですが、
現在はこの二つは補い合う関係に落ち着いているっていうところですね。
今、この補い合う関係に落ち着いているんですが、
補い合うからこそある課題が発生しているっていう状況があるようで、
その課題を解決するためにNewSQLっていうものが登場していくっていう話なんですけど、
NewSQLが出てきた当初、コンセプトは最初あったようなんですが、
それがスケーラブルRDBっていうのが当初のコンセプトとしてあったようで、
なのでNoSQLを良くしていくっていうよりはRDBを進化させるっていうのが大きな方向性なのかなと勝手に読み解いたんですけど、
この段階でどういった課題があったのかっていうところでいくと、
この辺とかあんまり書籍に詳しく書いてなかったんで、
ディープサーチとか使いながら見ていったんですけど、2から3。
2から3?
課題がある。
3つ目はNewSQL。
この課題って何の課題だっけ?NewSQLにおける課題。
これはRDBとNoSQLがそれぞれ独立して存在しているっていう状況での課題。
こっちを立てればこっちは立たないみたいな状況がそれぞれあるから、
そういう状況だとなかなか解消が難しい課題があった。
それはRDBをチョイスした場合の課題と、
NoSQLをチョイスした場合の課題についての話?
そんなイメージ。
両方使ってるとかそういうわけじゃないですかね。
両方使ってやれるっていう話もあるのかもしれないんですが、
多分そうじゃなしに一つで解決しようと思うと、
NewSQLみたいな構想が必要だよねっていう話かな。
今から話そうとしてるのはそれぞれの課題?
それぞれひとまとめとして扱ってる。
世間のサービスの課題として挙がっているものがあって、
それがRDB単体だと解決できないし、
NoSQL単体でも解決できないっていうようなイメージ。
なるほど。
ちなみにちょっと戻るんだけど、
SNSが盛り上がってきたときに、
なんでRDBの限界が迎えたの?
RDBだとプライマリーである書き込みライターと呼ばれるやつっていうのは、
基本的にはスケールが難しいとされているので、
例えば日本のTwitterのユーザーもイギリスのユーザーもアメリカのユーザーも、
例えばアメリカのライターに書き込みに行くとかなってくると、
そこで時間がかかったりとかして、
そうすると書き込みに時間がかかってしまって、
全体的なパフォーマンスが落ちてしまうというような課題があるというような感じです。
じゃあSNSになってから、それまでのサービスと違って、
リード、要するに読み取るよりも書き込みの頻度がすごく上がったことによって、
シングルライターを基本とするRDBだと無理が出てきたみたいな。
そうですね、そんな感じですね。
なるほど。
ありがとうございます。
課題の方に戻るんですが、
今話したように各地域ごとにユーザーがいるという状況が、
ビッグテックとかだと発生している、
しだしていて、なのでグローバルに分散しつつ、
強い一貫性の両立というのが一つ課題としてありました。
それがさっき言ったようにRDBだと難しいとか、
あとその辺のスケーラビリティとか、SQLは強いは強いんですが、
例えば今までSQLで書いていたそれを前提としたコードとか、
ORMで使っていればそういうコードとかというところは資産としてあるので、
そこを捨てなきゃいけないとか、そういう課題があったりとか、
最後3つ目が、これはNewSQLに対する課題というよりは、
全体的な何にでも言える課題というところがあるんですけど、
デジタル化とか進むにつれて、データ規模の爆発的増加、
世の中にコンテンツ増えるとか、
そういうサービスを使う人が増えるとか、
というところの増加みたいなところが課題としてあって、
それを解決するためにNewSQLが誕生していくというのが流れとしてあったっぽいですね。
ただそういう構想自体はずっと前からあったみたいなんですけど、
NewSQLの定義と特性
それを実現するために進化した部分っていうのが、
分散合意アルゴリズムと呼ばれるもの。
この後、軽く紹介するんですけど、
RUSTとか、Paxosっていうのかな、P-A-X-O-S、Paxosみたいな。
この辺の進化によってNewSQLっていうのが、
運用に耐えるものになっていったっていう感じらしいですね。
ここからは、実際にNewSQLってどんなやつなんですかっていう、
少し細かい話。あくまで少しなんで、そんなに深掘りはしません。
まず、この書籍で言われていたNewSQLの定義を読み上げると、
強い整合性とアシットトランザクションをサポートする、
地球規模に分散可能なSQLインターフェースを持つデータです。
要するに、従来のRDBに加えて分散可能になればOKって感じですね。
超粗い説明ですけど、それをNewSQLと呼ぶって感じ。
なんかギョーギョーしい。
ざっくり要素は3つあって、整合性っていうところと、
分散っていうところと、SQLインターフェースっていうのが3要素。
まず整合性のところとして、この辺って結構難しくて、
あんま知見がないんで、読んでへーってなっただけなんですけど、
ちょっと読み上げますね、その辺について書いたところ。
書籍まんま読みます。
NewSQLが複数のノードによって構成されるということは、
すなわち全ノードが共有する絶対的な時刻というものが、
存在しないことを意味するからです。
NewSQLにおいて各ノードの持つ時刻はわずかにずれており、
それがトランザクションの一貫性担保を劇的に難しくしています。
っていうことが書いてあって、
こういう時刻のずれによる難しさっていうのは、
整合性を保つための工夫
僕は考えたこともなかったんで、そうなんだっていう感じで、
しっかりと深掘りとはないんですけど、
ここに難しさがあるようです。
ただ、NewSQLの製品っていくつかあって、
そのうちのTidyBっていうやつ、
これはMySQL互換があるとされてるやつなんですけど、
プレイスメントドライバーっていう指令塔みたいなやつがいるんですけど、
そいつが共通の時刻を発行して時間を統一するとか、
あとGoogleのSpannerっていうやつだと、
原子時計っていうのを使用していて、
むっちゃ性能がいい、ずれない時計らしいんですけど、
そういうのを使って時刻を合わせるっていうような取り組みをしているようで、
そういう時刻を合わせることによって、
整合性っていうのは担保できるようにしやすくなったらしいですね。
書き込みのときにデータの素が起きちゃうんじゃないのとか、
そういうことを僕は思ってたんですけど、
課題感としてはここが強く書かれていたんで、
ここが一番どうやら難しいところみたいですが、
今言ったような対応をすることで、ここは解消したようですね。
それあれなのかな、ユースケースとしては書き込み量がめちゃくちゃ多いとか、
どういう場合だよね、きっと。
そうですね。なんで、例として上がってたのは、
そんなの起きるかっていう話ではあったんですけど、
例えばSNSとかだと投稿があって、そのリプライがあったときに、
時間のずれでリプライが先に来ちゃう可能性もあるみたいな。
リプライだとなかなかあんまりイメージ湧きづらいんですけど、
イメージとしてはデータの基本的にはAがあってBがあるよねっていうところの
ずれが起きる可能性はあるらしいですね。
マルチライターになっているから正確な順序性を担保するのが重要で、
RAFT合意アルゴリズムの役割
それが時刻に依存しているからっていう話なんですね。
そうですね。
なんか全然そんなこと考えたことなかったから、あ、そうなんだ。
俺も小説データベースの10章ぐらいでその話、文さんの話してるんだけど、
始めたとき俺もよくわかんなくて、原始時計とかもそうだけど、出てきたけど。
あれはとっつきづらい。
書き込みがすげーあるサービスっていうのがそもそもあんまり、
存在自体、2C向けのサービスだと結構あると思うけど、
我々が扱っているのは2B向けだとあんまりないから、そこまで考えないよねみたいなのは。
あるなーって思う。
そうですね。だからここに対する課題感を持ったことって過去一度もないから、
そうなんだっていう。
つきづらさはあるよね。
これが最初の整合性を担保するためにやってることで、
あと地球規模に分散可能なってあるんですけど、
分散の話としては、そもそもとしてNew-A-Scaleが分散前提なので、
各地域にストレージの配置っていうのは可能。
日本のユーザーであれば日本にデータを置くとか、
アメリカのユーザーのデータはアメリカに置くとかっていうような設定ができるそうなんで、
そういうユーザーのどこのユーザーなのかとかっていうところで、
最適なストレージの配置っていうのが可能っぽいですね。
あと、一旦このタイミングでRAFTの話をします。
RAFTっていうのが分散合意アルゴリズムと呼ばれるもので、
さっきとろっとスパナーって話をしたんですけど、
スパナーはこれじゃないPAXOSっていう方を使ってるようなんですが、
RAFTの方が一般的なのかな?だと思うんで、
こちらについて話すんですけど、
組織にあった主な役割としてはリーダーの選出。
リーダーっていうのはリードライトじゃなくてチームリーダーとかのリーダーですね。
リーダーの選出とログの複製っていうのがあって、
リーダーっていうのが分散するにあたって、
同じデータをいくつかのノードで持つことになるんですけど、
そのノードのいくつか同じデータを持ってるノードの取りまとめ役みたいな。
それ以外はフォロワーと呼びます。
例えば3つのノードで同じデータを持ってるんであれば、
リーダー1、フォロワー2っていう関係ですね。
リーダーの選出っていうのは仮にリーダーに障害が起きた場合に、
じゃあ次誰がリーダーになるんだっていう動きですね。
リーダーがいないと動かないんですけど、
そこで障害が起きても自動的に新しいリーダーが立つっていう仕組みをリーダーの選出と言っています。
それってさ、今のRDBで言う、
マイスケールで言うとソースとレプリカの関係。
マスターなんて昔は呼ばれていたけど、
その関係性でマルチレプリカ環境みたいなので、
要するに書き込みできるやつがリーダーになってると思うんだけど、
こいつがいなくなった時にレプリカが昇格するみたいなのと一緒だよね。意味合い的に。
そうですね。部分的に見れば一緒だと思いますね。
なんかニューエースケールのすごいところって、
リーダーとフォロワーの関係って多分今までのRDBのソースとレプリカの関係で、
そのさらに上にリーダーが複数いて、
こいつを取りまとめるやつ、オーケストレーションみたいな割り振るやつがいて、
複数マルチリーダーを実現しているっていう僕は理解なんだけど。
僕はどちらかというと、今回読んだ書籍の場合にもタイDBの本を読んでるんですけど、
さっきちょろっと話したプレースメントドライバー、PDって呼ばれるものが、
どのリーダーに対して、このデータにアクセスしたいんであれば、
どのリーダーに対してアクセスしてね、みたいなルーティングみたいのはしてる。
それがそれに値するのかな。
ラフトが使われるのってこの1個のリーダー、複数のフォロワーに対するものだよね、きっと。
そうです。この小さいエリアに対してあって、それがいくつもあるって感じですね。
はいはい、そうです。
もう一つある役割としてはログ複製ってあるんですけど、
超ざっくり言えばソーサログみたいなものを記録していて、
リーダーが何かしら書き込みとかの操作を受け取ったときに、
一旦そのフォロワーに対して、こういう操作をこの後しますよっていうのをお知らせして、
受け取ったフォロワーがそのログを自分たちに書き込んだ後に書き込みましたっていうのを返して、
その返答を待ってから実際に書き込むっていう、
2フェーズコミットとか呼ばれると思うんですが、っていう動きをしているっていうところですね。
何かあった場合はそこで作成したログを元に新しいノードを立てることで、
同じ状況、3台構成を基本としている場合、
1台落ちてもそのログを元にもう1回2台になったのを3台目を作り直すっていうことをしています。
こういうことをするのがRAFTです。
地球規模の分散ストレージ
超簡易的な説明だと思いますが、こういうやつですね。
で、ちょっと話が戻って、
地球規模の分散っていう話があったんですけど、
例えば、どういう配置がよくあるのか、
僕は分かってないんで、やや適当な感じで言っちゃうんですが、
リーダー日本にいます、
フォロワーアメリカとかイギリスとか韓国、中国とか、
いることがあるのかわかんないんですけど、
仮にあった場合に、今5カ所言ったのかな。
RAFTって、さっきログを書き込みます、返答待ちますって言ったんですけど、
この時、過半数返ってくれば次の動作に移るんですね。
なので、例えば今言ったところでいくと、物理的に近いのは韓国と中国、
イギリスとアメリカはちょっと遠いっていうところなんで、
韓国と中国のノードからおそらく先にレスポンスが返ってくる。
となると、その遠いノードのレスポンスを待たずに次行ける
みたいな特性もあったりするんで、そこも遅延を少なくする要因としてあるっぽいですね。
地球規模の分散するにあたって。
っていうようなことが書いてましたね。
っていうところが地球規模の分散をするざっくりな仕組み。
地球規模の分散をして、どうなの?
韓国から情報を見たい、読み取りたいっていう時に、
その韓国にあるフォロワーに行ってくれる?それとも
日本的にはリーダーへのアクセスになるんで、
韓国の人が日本の人のプロフィールを見るとかっていう時は、
基本的にはやっぱり日本には来なきゃいけない。
だからあくまでフォロワーがいるのはバックアップ用というか、
壊れた時用にっていう話なのかな?
そうですね、ちょっと待ってくださいね。
ちょっともう一回整理すると、
例えばリーダー日本フォロワー、韓国、中国、アメリカ、イギリスとかだったケースは、
全ての人が一回日本に来ます。リーダーに来る。
ただその複製する、レプリケーションするのは各地域に対してレプリケーションする。
なのでマルチリージョンで公開をせよとかっていうケースはこうするのかもしれない。
はいはい。
ただそうじゃなくて、
例えば韓国の人は韓国にデータを置いて、韓国のデータにアクセスしたいっていうケースであれば、
韓国にリーダーのあるものを置いて、そこで完結するようにするっていう風になるはず。
リーダーは各地に点々としている可能性があって、
そこの各地でどういうデータを使うか、
それはドメイン次第なんだと思うんだけど、
その各地でリーダーとフォロワーみたいな構成が、
いろんな世界各地に分散できるよっていう話。
そうですね。はい。
で、最後がSQLインターフェースを持つデータベースということですが、
ここは特に詳しく深掘りとかはないんですが、
クエリエンジンになるものが、
さっきまでずっと話してたのってストレージエンジンの部分の話なんですけど、
その手前にクエリエンジンがいるんで、そこがSQLを解釈した上で、
NewSQLの基本概念
実際ストレージエンジンにはキーバリューで持っているんですけど、
そのキーバリューを取るような形に変換した上で、
ストレージエンジンに対してリクエストするので、
実際のデータベースのクライアントとしては、
SQLでアクセスができるような仕組みになっている。
というところで、さっきの整合性の話と、
地球系の分散という話と、SQLインターフェースを持つという、
この3点をもって、NewSQLと呼ぶという感じですね。
もっと細かいことを話せば、かなりいろんなことがあるんですが、
とりあえず簡易的には説明としてはこんな感じかなっていうところですね。
次、じゃあこいつに欠点ないのかという話も一応触れておくと、
いくつか挙げられていたうちの4つほど持ってきているんですけど、
まず1つ目はネットワーク転送オーバーヘッドがあるというところで、
ノードがいくつかあると、そのノード間はネットワーク越しでのアクセスが発生するので、
ここはオーバーヘッドがあるよねというところでした。
ノード数が増えてくると、さっきのラフトの合意形成ということが行われるわけですが、
そこの時間が増えてくる可能性はあるというような指摘がありました。
あとコスト面も割高で、高性能を求めるとノード数が増えるということになってくるんですけど、
そうすると当然コストが増えるというところですね。
今だとRDBとニューSQLで同じ性能を出そうとするとニューSQLの方が高くなることもあるっぽいので、
まだまだコスト面ではこっちの方がニューSQLの方が高いというのがあるようですね。
あとは障害だったり遅延が発生したときの調査が難しいというところですが、
ノード数が多いので単純にどこで問題が起きたのかというところを探っていくのが、
RDBみたいな一つで完結するものに比べれば難しいというのはイメージしやすいかなと思います。
実際どういう調査をするのかとかまでは書かれてなかったのでわからないんですが、
難しそうな機会はあるという感じですね。
あと、さっきSQLインターフェースを持つという話をしたんですが、
完全な互換性があるわけではないというのも一つあります。
各サービス、なるべく互換性を保つようにやってはいるそうなんですが、
場合によってはこれは担保、互換性ないよというのもあるようなので、
この辺とかは互換性がないケースもあるので、
アプリケーションの修正が必要なケースもあるという感じですね。
この辺の4点、とりあえず欠点として挙げていますが、
導入事例の紹介
いくつかある中で許容できるのであれば選択肢としてはありなのかなという感じですね。
ユースケース、どういうサービスにフィットしているのかという話なんですけど、
作者曰くですが、最もフィットするケースというのは書き込みヘビーなシステム。
例えばEC、注文が大量に発生するようなECとか、金融の決済周りとか、
あまり世の中的には使われていないらしいんですけど、
IoTなんかもいいんじゃないかということを言ってましたね。
この辺の分野には向いているという話で、
実際の投入事例として2パターン持ってきているんですけど、
まずパフォーマンス的な問題を抱えていたケースです。
ドアダッシュというUber Eatsのライバルみたいな会社がアメリカにあるようで、
ここも結構人気のあるサービスらしいんですけど、
注文とかが多くなってくると在庫、注文できるよとか残り少ないよとか在庫ないよとか、
というのを更新する人があるらしいんですけど、
注文が増えてくると書き込みの遅延によって更新が間に合わないという問題があったようですね。
なのでこの部分が書き込みヘビーになっている部分ですね。
それを何に使ってたって言ったのかな、ちょっと忘れちゃったんですけど、
RDBを使っていたところからNewSQLに変えることで、
この辺が解消したという事例が挙げられてましたね。
いろいろと細かく書いてはあったんですけど、ざっくりとそんな感じです。
というのが一パターン目。
もう一つあるパターンとして、これは日本の事例としてDMMの事例が挙がってたんですけど、
さっきパフォーマンスの話をしたんですけど、
DMMのケースはパフォーマンスというわけではなくて、
いろいろな種類のデータベースの混在によって複雑化しているという状況がありました。
例えばログイン情報とかはMySQLで持ってますRDBですね。
セッション情報はコーチベースというのかな。
ドキュメント型のNoSQLで使ってたりとか、
ログイン履歴にはカサンドラというキーバリュー形式のNoSQLを使っているとか、
いくつか複数種類のデータベースを使っているということで、
運用コストがかなり上がっていたらしいんですけど、
これらをRDBに置き換えたようで、
そうすることで3つ上げてましたが、
MySQL、コーチベース、カサンドラの3つを対DB化に統一することで、
運用コストを下げるという使い方、導入事例もあるようで、
本社的にはパフォーマンス観点と一種DBの混在による複雑化の2点、
2ケース上げられていて、そういった導入事例は今のところあるようですね。
NoSQL導入の考察
他にもいくつか事例が上がっていたので、興味があればぜひ読んでみてほしいんですが、
こういったところが主なケースでしたね。
一旦ここでNoSQLの紹介みたいな話は終わりなんですが、
今話した内容とかユースケースを踏まえて、
うちのシステムにNoSQLは有効なのかという話を最後にして終わりたいなと思っています。
NoSQLを導入するってなるとやっぱりアーキテクチャが複雑だから、
すごいその辺りで理解がないと結構、
さっきの調査とか障害調査とかっていう話があったけど、
その後に難しくなるんだろうなとは思う。
そうですね。
なんか場合によっては入れたいなとか思ってたけど、
正直ユースケース見たりとかすると、
なんかわざわざうち入れなくてよさそうだなって思っているっていうのが正直なところ。
うちはそんなに書き込みヘビーでもないし、
今後ユーザー増えてくればどうなるかっていう話もありますが、
まあとはいえまだ大丈夫なのかと思ったりもするんですが、
ただ唯一この辺がいいよなって思うのは、
アップデートとかは無停止でできるので、
ローリングアップデートしていけるっていうのがあるんで、
今のところうちはマイエスケールを使っていますから、
アップデートしようとするとどうしても停止した上でスケールアップするとか、
っていう選択になるのかなと思うんですけど、
使うとすればタイDBになるかなとざっくり妄想していますが、
タイDBとか入れればユーザーの増加に伴うアップデートみたいなことは起きないので、
その辺はメリットとしてありそうだなと思いますが、
その他の部分がどの程度ペイするのかはちょっと怪しい。
今の状況だとやっぱり、今一番恩恵があるのはスケールアウトしやすいよねっていうところが強いんで、
うちもやっぱデータ量結構多くなってきてるし、
今後多分増やしていかないといけないってなった時に、
じゃあ一台のDBをスケールアップし続けるのかっていう話もある。
2台目用意して何かでシャーディングしたとして、
要するにユーザーを分割したとした場合に、
アプリケーション側で結局行き先を制御するとかしないといけなくなるのも辛いなっていうのが。
そうですね、パーティションとかそういうの使い出すんであれば、
その時はやっぱなんかNewSQLも議論の土台に上がってきそうな気はします。
あとは今すべての情報がRDBで管理されているけど、
本来はスキーマレスでいいよねっていう情報も結構たくさんあると思っていて、
そのあたりを細かく適切なデータベースにとかやっていくとDMMと同じ状況になるんだろうなみたいな。
その辺のスキーマレス力がちょっと低いからあんまピンときてないところは正直あるけど、
実際そういうことがあれば、確かにじゃあNewSQLに行った方がいいんじゃないみたいな、
その他のメリットとかも見ればみたいな話は確かにありそうですね。
結局、例えば操作履歴、たびたび僕が何かどっかで言ってるけど、
操作履歴とかって別に隙間必要ない。操作したたびにじゃんじゃん書き込みに行くから、
それこそドキュメントDBみたいな、ただJSONの形みたいなので保存していくでいいと思うんだよね。
確かにあんまり操作履歴がRDBとかと一緒になってると、操作履歴って本質的じゃないじゃない?
システムにおいてってこと?
そう、業務において。ユーザーの業務において本質的じゃない、別に関心のない部分。
だから、そいつを分離しとくっていうのはなんだろうな。
そいつに引きずられて障害が発生するっていうのもなくなるだろうし、
いい設計にはなるけど、それだけ新しい存在が増えると複雑化していくんで、
理解が難しくなるっていうのもあるよねっていう。
このトレードオフどうするみたいな話はすごいある気がする。
実際今、かなり部分的にRedis使ってるところあるけど、
この辺って普段触ってないから、何か起きたときに多分操作履歴になって思うもん。
Redis何でどこで使ってるのっていうのってちゃんと言える人ってあんまりいないし、
じゃあこれだからRedisっていうのもうまくまとまってない気がしていて。
そうだね。
そういう暗黙地みたいなのは増えやすいかもしれないですね、こういう構成。
そうだね。だからもしも今後、じゃあもっとサービスシステムを洗練させていくってなったときに、
そういったいろんな機能を分離していくみたいな、
引きずられないようにするみたいな考えでアーキテクチャが複雑になっていくたときに、
NewSQLとアーキテクチャの複雑さ
それそれぐらいにはNewSQLにもやっちゃうみたいな話も出てくるのかもしれない。
そうですね。でもとりあえずはすぐにはすぐにっていう感じではなさそうですね、いずれにしても。
なんだろうな、こういうのってなんとなくもしかしたら業務に活かせるかもっていうのも一部思いつつやってると、
すごい学びよくあるけど、学んだ上でこれちょっとまだいらんなと思うとちょっとモチベーションが下がるもんね。
そうですね。これ勉強してたときにちょうどマイクロサービスも流行っていて、
今なんかマイクロサービスなのか、モノシリなのかみたいな、モノリスなのかみたいな議論ってまた再現してるけど、いろんなところで。
再評価のタイミングになってるけど、ちょうどそのマイクロサービス向けのアーキテクチャと、
アーキテクチャってあるんだ。さっき言ってたオーケストレーションとか、コレオグラフィーみたいなっていうアーキテクチャのパターンがあるんだけど、
アプリケーションアプリケーションでそういうアーキテクチャになっていて、データベースはデータベースで、
似たようなオーケストレーション、指揮者がいて一人が指示を出して、その先にもリーダーとフォロワーみたいな関係があって、
ラクトのように合意形成の仕組みがあってみたいな。どこ見ても複雑すぎて、わけわかんなってなった記憶がある。
ごっちゃになるんだよね。マイクロサービスを勉強してると似たような仕組みになってるから。
AV周り、USQL周りに関しては、クラウドのサービスとか、SaaSみたいなのに乗っかれば、
金で解決、複雑さを金で解決っていう手段もなくは。
あれを自分たちで管理は地獄だろうな、確かに。
いろいろとシステムの問題を解決するためにアーキテクチャが複雑になっていくというのは、逃れられないのかなと思ったりも。
しかもアーキテクチャ、新しいアーキテクチャができるときって、100いったら、100サービスがあったとしたら、
1のサービスが困ってることに対してのアプローチだったりするから。
1は本当に困ってる。サービスを継続する上で、本当の本当に直面している課題で解決しないと先にいけないみたいな状況だからこそ、
新しいものを編み出して、それが世間で広がってカッチョイってなってみんな使うけど、別に俺らに必要なかったよねっていうことにも結構多い気がするんだよね。
いやーそうですね。だからこう、履歴書を豪華に、職務系履歴書を豪華にするためだけの導入みたいな感じの可能性があるから。
これも今で導入すると、そうだからな。
書籍の推奨と振り返り
でもなんか派生するけど、面接で聞きたい内容ってなんでそれをその時に採用したんですか? への多分、適切な返事?だから。
そうですね。この段階で言えると、ああ、まあ人だったんだよみたいな。
技術って結構再評価されるから、なんかすげー盛り上がるじゃん。新しい技術って。AIもそうだけどさ。すげー盛り上がって。
今マイクロサービス、みんなこう導入して、運用してみて、辛っ!ってなり始めてるから、再評価タイミングになってきてるけど。
なんか、だから結構時間が経って進化、本当のそいつの価値みたいなのが見えてくることは多い気がするよね。
そっから、いろんな痛みが集積されていって、じゃあこうすればいいのっていうのも出るケースもあるし。
逆に、いややっぱこれだめだって戻ってくることもあるあるし。
そうだね。
そこは難しいですね、判断は。やってみないと分かんないことが多すぎるからな。
容易に飛びつかないことは大事。
そうですね。でも新しいのを勉強すると飛びつきたくなっちゃうんだよな。
新しいのを勉強するのは楽しいし、いいと思う。知識が増える分には。
それを商用に適用するかどうかはまた別問題っていう話だよ、きっと。
新しいのやりたいっていう気持ちと、なんか読んだばっかりでめちゃくちゃバイアスかかって、めっちゃこれ良さそうじゃんっていうのもあるから。
あれはもう、あれ暴走してる時だから。周り見えてない。
はい、じゃあそんなところかな。
多分概要欄に書籍のリンクを貼ると思うので、興味があれば読んでみていただければと思います。
ニューエース・ケールに興味なくてもすごくいい本だったので、
ニューエース・ケールはこうだけどRDBはこうだよねっていう振り返りみたいなのも書いてあるので、
振り返れるような内容も書いてあるので、ぜひ手に取っていただけると良いかなと思います。
はい、ということでニューエース・ケール徹底入門分散DBのアーキテクチャからユースケースまでを読んだ感想でした。
はい、ありがとうございました。
ありがとうございました。
