お疲れ様です、桑野です。
なんとなく思ったことをつれづれなるままに書くしりーず。
これで何かを主張したい、決めたいわけではなくて思考実験です（汗
この議論結構繰り返すんですよ
Xとかで定期的にこれやる、「RDBがデータもきれいに持てるし、何よりSQL使えるのがいいよね」「いやいや、用途ごとにユースケースにあったNoSQLを使えるのが良いよやっぱ」「NewSQLはNoSQLのスケーラビリティと、使い慣れたSQLも使えるので最強だ」とか。そういう奴。
悲しいけどそれ戦争なのよね？（違
言ってることはみんな正しい
まずいいたいのは、みんな間違ってるわけじゃないってこと。なぜかというとみんなバックグラウンドが違っていてそのバックグラウンドで何かを選択するしかないわけだし。
でも戦って決めないといけないわけじゃない
Xとかだとなんか舌戦になってて、戦うべきことなのだろうか？って思う。（Xの性な気はするけどｗ）
敵はそこにいるわけではないのです。RDBerもNoSQLerもNewSQLerも敵ではないのです。
敵ではないけどデータベースの使い分けって実際どうすればいいのだろう。
データベースの使い分けってどうするの？
自分が思う使い分けはこうかな、ざっくりだけど。
RDBはもちろんトランザクションが得意なデータベースなのと、もちろんSQLが使えることが大事（SQL最近燃えてたけど）。MySQLやPostgreSQL、Oracle、SQL Serverみたいなものが代表格ですね。あと大事なのはSQLというインタフェースや、RDBというデータベースの経験を持っているエンジニアがやはり大半だということ、なので基本の軸足はどうしてもRDBになると思う。
NoSQLはNoSQLって括りにするとめっちゃ主語デカだと思っているｗ 各種特化したデータベースでSQLを使ってない独自のインタフェースを使っているデータベースの総称なので、Redis？Valkey？みたいなキーバリューストアもあればMongoDBみたいなドキュメントストアもあれば、Cassandraの様なワイドカラムストアもなんでもアリです。ユースケース的に合っているデータベースがあれば使えばよろしい。
NewSQLは昔から欲求としてみんながもっている「読み書き含めて水平スケールするRDBがほしい！」を実現するために出てきた、分散データベースだけどSQLが喋れるよ、のデータベースです。TiDB、YugabyteDB、CockroachDBなどが代表格。もちろん欲求が欲求だけにSQLが喋れて、水平分散できるよ、が実現できるわけだけど分散データベースゆえのRDBとの差異もある。例えば整合性を確保するのにRDBならノード内で整合性を確保できていればいいけど、NewSQLだとRaftみたいなノード間で一貫性を取る必要があるとか。ノードにデータが分散している前提でクエリもチューニングも考えないといけないとか。なので「RDBのかわりに何も考えずにNewSQLつかっとけばいいんでしょ」というわけでもないのでそこは注意。
ああ、そうそう、NewSQLといえば、NEONは面白いなーって最近おもっている。NEONはAmazon Auroraを元につくられたデータベースなんですが、ストレージにデータのログ（WAL）をもっていて、好きなタイミングに戻すことができる。Auroraとそこは確かににてるんだけど、ブランチを切ってデータベースを瞬時に戻したりと、アプリケーションのマイグレーションと組み合わせてアプリケーションの開発に寄り添った形でデータベースの運用ができるのは楽しそうだなーｔ、、、
閑話休題。
とまあ色々なデータベースがあるわけで、これを使い分けていく、みたいなのが現代のアプリ開発現場なわけです。とはいっても感覚値としては上にも書いたけどRDBが多いっていうのが現状なんじゃないかな？NewSQLは流行ってきてる感じあるから今後はどうなるかわからないけど。
満たしたいものはなんだ？
つらつら書いてきましたけど、じゃあ、あなたが新しいサービスでデータベースを選定したいときに満たしたいものってなんでした？
- 使い慣れたSQLを使いたい
- 水平スケールしたい
- 柔軟にデータを持ちたい
- レイテンシを低くしたい
- 堅牢にデータを持ちたい
- 大量にデータを持ちたい
- トランザクションを使いたい
- サービスを安定運用したい
まだまだ色々ありますし、論理的な要素もあれば、非論理的な要素もあれば、感情的な理由も、社内的な理由も、あるはず。それに優先順位をつけて満たしていくわけです。
この前X？Twitter？でMongoDBの話をしたときにこんなことをいっていた人がいた。
「ドキュメントDBでプロダクションサービスを運用してる経験者が圧倒的に少ないので、結構ネットの議論は空中戦なんだよな」
ホントそうだなって思って、結局のところ繰り返しになるけど冒頭にもちょっと言った自分のバックグラウンドの中で選択していくしかないんだよなって思うのと同時に、じゃあ使いなれたバックグラウンドから一歩出ていくためのモチベーションってなんなんだろうとも思った。
一歩出ていくために
この前こんなブログを見つけた。
FlipkartってインドのECサイトをやってる会社（インドのAmazonみたいなサービス？）のめちゃくちゃでかいHBase(1PBのデータ容量、10000 vcore、50TB以上のメモリ合計ってすごない？)の運用改善についてのBlogで、このBlogを見て自分は衝撃を受けた。
あんまり良い言い方じゃないかもだけど、HBaseって世界でものすごく多く使われてるデータベースというわけではないと思っている。でも彼らはこれだけHBaseにベットしているわけで。
HBaseだから分散コンピューティングでの水平スケーリングがいるのだろうな、とかカラム指向である必要があったのかなぁとかマルチリージョンでの同期レプリケーションでのレイテンシが課題でマルチリージョンの非同期レプリケーションが必要だったとあるのでマルチリージョンでの情報のやり取りが結構あるのかなぁとか考えるのですが、それよりなにより自分たちのサービスのためにHBaseをこの規模で動かす必要がこの人たちにはあったんだろうな、っていうのとHBaseについて知り尽くしたうえでサービスの定常的な運用のためにそれを乗りこなす必要があったんだろうなっていうのがBlogから伝わってきた。
この例でいうと「マルチリージョン」「分散コンピューティングによる高い水平スケーリング性能」「低レイテンシ」「カラム指向がフィットするデータモデル」「スキルセット」などの要素から選択したのかもしれないし、別の理由かもしれない（なんやねん）
だから、さっきいったそこから一歩出ていくためのモチベーションって必要に迫られる要件があって、それに対して解決になるソリューションを見つけてそれを必要に応じた検証して使うってことなんかなぁと思った。（それが世の中にどのくらいあるんだろうってのも思うんだけどね。）
こんなことも書いた。
データストア選択の戦略についての感覚
でも、RDBの安定感のある技術は大事だし、NoSQLは特化しててフィットすると良い気がする、NewSQLはSQLを使えてスケールする。そんなとっかかりで選ぶのもアリだと思う。もう一歩踏み出す前には機能検証して、負荷試験だって、社内の啓蒙だってしないといけない（当たり前）
でも最初からそんな大変なことする必要あるのかな？とも思う、だからそれだけじゃなくて、ステージによって変化していける力をつける必要はあると思う。すごいスケールが必要なサービスに成長したけど、RDBで手動でシャーディング組むのは運用的にも、コスト的にも辛いからその辺を自動で行えるNewSQLに移行したいってなるかもしれないし、一部新機能はアプリを分割してNoSQLでスケールしたいって要件もでるかもしれない。もしくはNoSQLでやってたけど結果整合性だとどうしても厳しい部分がでてきたのでRDBで決済部分だけ切り替えたいよ、みたいなのもあるかもしれない。だからといって何でもかんでも使ってデータベースの動物園みたいな状況にすることが良いとは思わないので使う人側が困らないためにどうするかを考える必要はある（採用する上限数を決めるとか、オンボーディングを充実させるとか？）結局は当たり前だけど「それを採用することでどのくらいメリットが出せるか、組織としてそれに注力するだけの価値が出せるか」だと思う。
それと多分RDB以外のものを選択することは一般的に抵抗があることなんだと思うんだよね、使用者が多いほうが情報も多いし、無理にファーストペンギンになる必要はないしね。最後は精神論みたいになっちゃうけど検証で足元固めた上でわたり切るかどうかなのかな。
以上でーす。
256bitのミステリ世界 
コメントを残す