互換性のある（らしい）DBへの移行など考えるにあたってたいへんざっくり

by Takanori Sejima

Slide 1

Slide 1 text

互換性のある（らしい） DBへの移行など考えるにあたってたいへんざっくり sejima

Slide 2

Slide 2 text

免責事項 - 本資料において示される見解は、私自身の見解であって、私が所属する組織の見解を必ずしも反映したものではありません。ご了承ください。 2

Slide 3

Slide 3 text

はじめに - 社内で「データベースを異なる環境や互換性のあるマネージドサービスなどに移行する際、どういうことを考えてるか、幅広い層に向けて話してください」みたいなことを言われたんですが。 - いろいろ考えてるので、今日は簡単な概要だけ話します。 3

Slide 4

Slide 4 text

世の中的な背景的な - 現代においては「〇〇互換のマネージドサービス」「〇〇互換の分散DB」みたいな選択肢が増えてきて、かつ、それらに移行するためのコードの生産性も上がってきてると思います。 - ただ、互換性などで知識として知っておいた方が良いことはあるかなと思ったので書きました。 4

Slide 5

Slide 5 text

補足・その一 - 個人的に、データベースの移行については否定的ではないです。 - むしろ、古いものを塩漬けにして環境の変化に追随できなくなるのはたいへん不味いと思います。 - ただ、移行する前に知っておいた方が良いですよ、という話です。 5

Slide 6

Slide 6 text

補足・その二 - MySQLを前提とした話でありつつ、RDBMSごとの振る舞いの違いを示す例として、 PostgreSQLやSpanner、TiDB、Aurora DSQL などについても、ところどころで触れています。 - ただMySQLみたいにソースコード読んだことないので、個人的にざっくりとした印象で書いてます。 6

Slide 7

Slide 7 text

補足・その三 - ゲームやWebサービスなどでのデータベースの利用を想定した内容となっているため、内容に偏ってる部分がある可能性があります。 - 例えば、ミッションクリティカルなサービスなどであれば、また違う考え方になるところもあったりするかと思います。 7

Slide 8

Slide 8 text

アジェンダのようなもの - まず最初に - 次に、データの保護やバックアップについて - 振る舞いについて - トランザクション関連 - 設計思想に起因する性能特性 - 性能 - メンテナンスやバージョンアップ - まとめのようなもの 8

Slide 9

Slide 9 text

では 9

Slide 10

Slide 10 text

まず最初に 10

Slide 11

Slide 11 text

「◯◯と互換性100%」と言われても 11

Slide 12

Slide 12 text

そんなわけない 12

Slide 13

Slide 13 text

信じられない 13

Slide 14

Slide 14 text

「◯◯と互換性 100%」 - 独自実装であれば、そもそも互換性100%とは普通ならない。 - 互換性100%と言ってる場合は、同じクライアントライブラリが使える == プロトコル的に互換性がある程度で、実際の機能や挙動、性能特性までは互換性がない。 - MySQLからforkしたものであっても、独自実装の部分で振る舞いが変わったりする。 14

Slide 15

Slide 15 text

- SQLのsyntaxに一部互換性がないケースも考えられる - SQLを独自に拡張している場合、予約語を独自に追加されている可能性も考えられる。既存のツールはそのまま動くのか？（いまどき気にするようなことでもないだろうけど）アプリケーション側のソースコードでちゃんとエスケープできてるか？ 15

Slide 16

Slide 16 text

互換性のある DBに移行する際の心構え - （実際にそこまで大変なケースは限られているだろうが）メジャーバージョンアップと大差ないつもりで臨んだ方が無難 - 「〇〇をベースに」とか「〇〇互換」と言われても、そのまま動作するとは限らない - 例えば、Aurora DSQLはPostgreSQL非互換の部分もある 16

Slide 17

Slide 17 text

- 普通、他のRDBMSに移行するよりも、いま使っているRDBMSのメジャーバージョンアップをする方が、実現性は高い。 - もし互換性がないRDBMSに移行するとなると、（基本的に）アプリケーション側で大規模な改修が必要になると考えて良い。 17

Slide 18

Slide 18 text

独自実装であるがゆえのデメリット - 本家との差分が大きいということは、本家で新しいメジャーバージョンが出たとき、追随するのに時間がかかる - 例えばMySQLは8.0のときに Coding Guideline などが一気に変わってソースコードがかなり書き直された。 MySQLをforkしている各社のマネージドサービスで差分が大きいと、こういうとき追随するのが大変になる。 18

Slide 19

Slide 19 text

複数のバージョンを運用する可能性 - もし、複数のパブリッククラウドを利用して複数の環境を運用していると、複数のメジャーバージョンを運用し続けなければならなくなる可能性がある。他の環境では延長サポート料金の発生を避けるために、メジャーバージョンアップすることはある。 19

Slide 20

Slide 20 text

- 例えば、RDS for MySQL 8.0の標準サポート終了は2026年7月31日、CloudSQL for MySQL 8.0の拡張サポート開始日は2027年1月1日となっている。 - 自分たちが利用しているMySQL互換のマネージドサービスが他にもあって、それが8.4対応できていなければ、 8.0と8.4の環境両方をメンテナンスし続けることになる。 20

Slide 21

Slide 21 text

- 延長サポート料金を避けるためにDBのメジャーバージョンアップをする際、クライアントライブラリ側のバージョンアップも必要になる可能性がある。それでも他の環境のDBのバージョンが古ければ、クライアントライブラリなども複数のバージョンを管理する必要が出てくる恐れがある。 21

Slide 22

Slide 22 text

次に、データの保護やバックアップについて 22

Slide 23

Slide 23 text

データ保護の観点 - （いまどき当たり前だろうけど）暗号化機能があるかどうか - 例：EBSの volume snapshotなどは、暗号化されていない場合、設定ミスの結果、他のAWSアカウントにclone できて漏洩してしまうリスクが想定される。 - volumeやsnapshotが、アカウント内に閉じた鍵で暗号化されていれば、鍵がなければ別のアカウントで cloneして中身を見ることはできない。 23

Slide 24

Slide 24 text

データのバックアップ - AZ障害は発生すると想定する必要がある。 - AWSの東京リージョンだけでも、2019-08-23と 2021-02-20にデータセンターの冷却システム起因の大規模障害が発生した。 - AZレベルの大規模障害が発生したとき、影響範囲がAZ内に限定されない、不測の不具合が発生することがある（じっさいあった）。 24

Slide 25

Slide 25 text

リストアする際の整合性も気に掛ける - どんなパブリッククラウドであっても、シングル AZに閉じた設計は一定のリスクがある。複数の AZあるいはリージョンでデータを複製しバックアップできる構成が取れるか、バックアップから整合性の取れた状態でリストアできるかどうかなどが重要になってくる。 25

Slide 26

Slide 26 text

バックアップとリストアの補足 - ランサムウェア対策という観点においても、バックアップやリストアは重要なテーマ。 - 私はこの分野には疎いですが「DBのランサムウェア対策どうしたらいいですか？」と聞かれたら、まず次のblogを読んでみましょうという話をします。 26

Slide 27

Slide 27 text

- https://cloud.google.com/blog/ja/products/ide ntity-security/5-pillars-of-protection-to-preven t-ransomware-attacks - 単に「ランサムウェア対策どうしよう？」だと扱うテーマが広範で議論が発散しやすいので、「今日は復元をテーマにバックアップとリストアについて検討しましょう」みたいな提案をしています。 27

Slide 28

Slide 28 text

移行する前に整理すること - これから移行するシステムは、どの程度の規模の障害を想定し、どの程度の時間で復旧できる必要があるのか - AZ障害だけでなくリージョン障害も想定するのか - 何時間以内に復旧する必要があるのか - 移行前の構成で想定されていたRecovery Time Objectiveは維持できるのか、あるいは改善するのか 28

Slide 29

Slide 29 text

振る舞いについて 29

Slide 30

Slide 30 text

振る舞いの観点 - データベース側だけでは決まらない - プログラミング言語ごとにDBのクライアントライブラリの実装が異なるケースがある。プログラミング言語ごとに、クライアントライブラリの振る舞いが異なるケースがある。クライアントライブラリの実装とDB側の実装の組み合わせが重要。 - 参考： - https://labs.gree.jp/blog/2024/03/23110/ - https://labs.gree.jp/blog/2023/07/22581/ 30

Slide 31

Slide 31 text

文字コード - アプリケーションで使っている文字コードを、 RDBMSでサポートできていればよいというものではない。（いまどきUTF-8使ってないところは珍しいだろうけど） - 例えばMySQL は character set について client <-> server 間で handshake する - （MySQL8.0まではそのhandshakeをスキップするオプションが有る） 31

Slide 32

Slide 32 text

- MySQLのhandshakeに関する振る舞いは、プログラミング言語ごとに独自実装されているクライアントライブラリに依存する。 - 例えばPHPのmysqlndはmysqld側で設定されたcharacter_set_serverの値に従い handshakeをスキップするので、mysqld側で character_set_serverを設定できるかが重要 32

Slide 33

Slide 33 text

文字コードの不可逆変換 - MySQLはclient <-> mysqld 間で自動で文字コード変換をすることもできるが、仕様上不可逆変換が存在する。これはUnicodeの仕様の問題。 33

Slide 34

Slide 34 text

EUC-JP <-> Unicodeの不可逆変換 - MySQLで具体的な例を挙げると - EUC-JP 0xA1C0 -> U+005C REVERSE SOLIDUS - https://gist.github.com/sejima/40174345ff2714e7 53d2fd448696a618#file-gistfile1-txt - EUC-JP 0x8FA2B7 -> U+007E TILDE - https://gist.github.com/sejima/40174345ff2714e7 53d2fd448696a618#file-gistfile2-txt - EUC-JPに戻すとき、0xA1C0 や 0x8FA2B7 ではなく 0x5C や 0x7E になる。 34

Slide 35

Slide 35 text

Unicodeの仕様が修正されることも - Unicode 7.0以前の仕様書ではU+301C, WAVE DASH を使うべきところでU+FF5E, FULLWIDTH TILDEが使われてしまっていたが、Unicode 8.0以降で修正されたことがあった。 - Wikipedia | 波ダッシュ 35

Slide 36

Slide 36 text

文字コードの変換は要注意 - クライアントライブラリとRDBMS間で文字コードの変換をしてくれるのは便利ではあるが、不可逆変換が発生しないか注意する必要がある。 - できれば、プログラミング言語とクライアントライブラリとRDBMS間で、文字コードは揃える方が無難。 36

Slide 37

Slide 37 text

Unicodeのcollation（照合順序） - アプリケーションやRDBMSでUTF-8を使ってさえいれば良いという話ではない。 - collation（照合順序）含めて互換性の問題がある。 37

Slide 38

Slide 38 text

絵文字や合字の扱い - MySQLのサポートしているUnicodeのバージョンは9.0と古いので、最近の絵文字や合字の扱いに一部制限がある。 - 例えば、2019年に追加された令和の合字を”令和”と同じものだと識別できない。”㍻”と”平成”はわかる。 - 例： - https://gist.github.com/sejima/40174345ff2714e7 53d2fd448696a618#file-gistfile3-txt 38

Slide 39

Slide 39 text

ソート順や一意性制約への影響 - collation含めて互換性が担保できないと、文字列のソートの順番が変わってしまう。また、文字列のUNIQUE KEYがあったときに挙動が変わってしまう。 - MySQLは8.0でdefaultのcollationが変わってしまったので、5.7以前から稼働しているDBを8.0 に移行する場合、5.7以前のdefaultのcollation に設定可能かというのも重要。 39

Slide 40

Slide 40 text

MySQL 5.7と8.0のcollationの例 - utf8mb4_0900_ai_ci, utf8mb4_general_ci, utf8mb4_bin, utf8mb4_ja_0900_as_cs, utf8mb4_ja_0900_as_cs_ks でのソート順の違いや振る舞いの違いなどの実例 - https://gist.github.com/sejima/40174345ff2714e753d 2fd448696a618#file-gistfile4-txt 40

Slide 41

Slide 41 text

MySQL 8.0でdefaultのcollation設定 - （いくつか方法はあるのだが）MySQL互換のマネージドサービスであれば、SUPER権限も CONNECTION_ADMIN権限もないアカウントでアクセスするなら init_connect パラメータで collation 周りの設定を毎回上書きするようにすれば、わりと上手く行く。 - 参考：https://labs.gree.jp/blog/2024/03/23110/ 41

Slide 42

Slide 42 text

- MySQL互換のマネージドサービスへ移行を検討する場合であったとしても、次のような点は移行しやすさを実現するうえで重要 - アプリケーション側で使うMySQLアカウントに、必要以上に強い権限を持たせない。 - アプリケーション側で使うMySQLアカウントやパスワードを、変更しやすい仕組みにしておく。（移行時に init_connectなど使うなら、新規作成したアカウントに切り替えやすい設計になっているか） 42

Slide 43

Slide 43 text

Unicodeのcollationについて補足 - 例えばTiDBはMySQLのソースコードをforkしているのではなく独自実装なので、collationなど文字列の扱いについては要注意 - PostgreSQLはOS側に（外部ライブラリに） collationの処理を委譲しているので、MySQLとはそもそも挙動が一致しない。 - 参考：とみたさんの資料が秀逸 43

Slide 44

Slide 44 text

認証プロトコル - MySQL 9.0でmysql_native_password が削除された。 - MySQL 9.x 以降では caching_sha2_passwordが必須になったが、この振る舞いもプログラミング言語ごとに異なる。このことを想定した事前調査などはやった方が良い。 44

Slide 45

Slide 45 text

caching_sha2_passwordの補足 - （たいへんざっくりいうと）mysqldと接続を確立する際、SSLで通信するか、公開鍵をmysqld側から取得するオプションを使うことが必要になる。 - そして、プログラミング言語ごとにクライアントライブラリの実装が異なっている。（オプションではなく、デフォルトで公開鍵を取得する挙動のライブラリがある） 45

Slide 46

Slide 46 text

TLSやOpenSSLのバージョン - TLS使って接続しようとしても、クライアント側で使えるTLSのバージョンが古すぎるとmysqldに接続できない。MySQL 8.0.28以降、TLSv1や TLSv1.1は削除されている。 - （いまどきあまりないと思うが）環境が古すぎるとOpenSSLのライブラリが古くて TLSv1.2や TLSv1.3を使えない可能性もある。 46

Slide 47

Slide 47 text

トランザクション関連 47

Slide 48

Slide 48 text

トランザクション分離レベル - MySQL互換を謳っていたとしても、defaultのトランザクション分離レベルはMySQLと同じなのか？挙動もMySQLと同じなのか？ - 例えば、TiDBのドキュメントには Difference between TiDB and MySQL Repeatable Read やDifference between TiDB and MySQL Read Committed といった項目がある - Aurora MySQL でREAD COMMITTEDを使う場合、 readerの挙動はMySQLと完全には一致しない。 48

Slide 49

Slide 49 text

- ANSI/ISO SQL標準で SERIALIZABLE、 REPETABLE READ、READ COMMITTED、 READ UNCOMMITTEDといった４種類のトランザクション分離レベルが定義されている。ただ、それぞれの振る舞いは、MySQL互換云々以前に、そもそもRDBMSごとに微妙に異なったりする。 49

Slide 50

Slide 50 text

主要RDBMS製品の比較について - 近年、渡部さんが db tech showcase で登壇してお話されてるテーマなので、公開された資料を読んだら参考になると思います。 - https://x.com/wrcsus4/status/1943499418541629626 - https://x.com/wrcsus4/status/1811305297413059067 50

Slide 51

Slide 51 text

ロングトランザクションは避けたい - ロングトランザクションはロックの競合やデッドロック、性能劣化などの原因となりうるので基本的に避けたいところ。 - ロングトランザクションとの相性は、RDBMSの設計次第で更に悪くなるケースもある。 - DBを移行した結果、ロングトランザクション起因の問題が悪化する可能性もある。 51

Slide 52

Slide 52 text

例：Aurora MySQL - Aurora MySQL は undo log を writer と reader で共有するアーキテクチャなので、 autocommit=1で運用することや、長いトランザクションを避けることを推奨するホワイトペーパーが公開されている。 - https://d1.awsstatic.com/whitepapers/ja_JP/RDS/am azon-aurora-connection-management-handbook.pdf 52

Slide 53

Slide 53 text

例：TiDB - Transaction too largeでエラーになるケースや、REPEATABLE READでLost Updateが発生してしまうケースなど、Cygamesさんの丁寧な解説資料が存在します。 - 【TiDB GAME DAY 2024】TiDBにおけるテーブル設計と最適化の事例 - 【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術 53

Slide 54

Slide 54 text

例：PostgreSQL - ロングトランザクションによってVACUUMが効かなくなるため、PostgreSQLのCommitterであらせられる藤井さんも「トランザクションの粒度は、本当に必要な処理だけに絞り込む」と仰られています。 - トランザクションを「本気で使いこなす」ための必須知識。PostgreSQLコミッターが教える活用術 54

Slide 55

Slide 55 text

Upsertなどのロックの範囲 - MySQLのバグ修正で5.7.26以降、一部のステートメントでロックの範囲が厳しくなってデッドロックが発生しやすくなったと、Aurora MySQL のドキュメントなどで注意喚起された。 - 具体的には INSERT...ON DUPLICATE KEY UPDATE などのようなもの 55

Slide 56

Slide 56 text

ロックの範囲やデッドロックなど - Upsert のロックの範囲やデッドロックは、アプリケーションで使うトランザクション分離レベルを変更することで緩和できるケースもある。 - ただ、TiDBやAurora MySQLの例を見るように、同じREPETABLE READ、同じREAD COMMITTEDでも、完全な互換性があるわけではない。 56

Slide 57

Slide 57 text

設計思想に起因する性能特性 57

Slide 58

Slide 58 text

性能特性の観点 - レイテンシ - 設計上、MySQLなどと比べて分散DBはレイテンシが増加する傾向にあると考えられる。分散DBに移行したい場合、アプリケーション側でN+1のループがあったときに耐えられるか - 分散DBでなかったとしても、マルチAZを前提としたアーキテクチャだった場合、AZ間のレイテンシはアプリケーションから許容できる範疇に収まっているのか 58

Slide 59

Slide 59 text

設計思想に基づく違い - MySQLなど分散データベースでないRDBMS は、primary key がシーケンシャルな値だと空間効率が良いケースがある。 - MySQLのInnoDBはprimary keyをランダムな値でランダムにINSERTすると、テーブルがフラグメントする。 59

Slide 60

Slide 60 text

- 一方、Spannerはprimary keyがシーケンシャルな値だと hot spot ができやすい問題がある。 - Spannerに限らず、分散DBにおいてMySQLの auto_incrementのようなものはボトルネックになりがち。 - SpannerもSEQUENCEをサポートするようになったが、 bit_reversed_positive が必須など、他のRDBMSとは異なる特性がある。 60

Slide 61

Slide 61 text

MySQLのauto_increment - MySQLのauto_incrementでさえ、複数のロックモードが存在していて、それぞれ挙動が異なり、性能特性が異なる。 - 他のRDBMSで似たような機能があったとしても、MySQLのauto_incrementのどのモードと互換性があるのか、それとも全く異なる挙動なのかというところがある。 61

Slide 62

Slide 62 text

性能 62

Slide 63

Slide 63 text

性能の観点 - アーキテクチャやそれに伴うハードウェア構成はどのようなものか - 最初からマルチAZ前提の設計になっていれば、更新時にCOMMITのレイテンシへの影響が発生する可能性がある。 - 後づけでマルチAZ構成でデータをレプリケーションする場合、レプリケーションの遅延を考慮して更新性能を評価する必要がある。 63

Slide 64

Slide 64 text

例：Amazon Aurora の場合 - 最初からマルチAZ構成を前提とした設計で、 COMMIT時には（内部的に）他のAZにもredo logを書き込んでいる。その結果、 CommitLatencyはAZ間通信のRTTの影響をある程度受けると考えられる。 - その一方で、COMMITに対する様々な最適化は独自実装されている。 64

Slide 65

Slide 65 text

例：MySQLを自前で立てる場合 - sourceとreplicaが非同期レプリケーションの場合、sourceのCommitLatencyはreplicaの影響を受けないが、Auroraと比べてレプリケーションの遅延は発生しやすくなる。 - sourceとreplicaが準同期レプリケーションだった場合、sourceのCommitLatencyはsourceと replicaの間のRTTの影響を受ける。 65

Slide 66

Slide 66 text

ベンチマークを取るうえで - ベンチマークを流した際、見かけ上は高い性能を出しているように見えたとしても、レプリケーションなども考慮しつつ、実際に許容できるのはどの程度の更新性能になるのかを見極めるのが重要。 - 更新頻度が高いと CommitLatency が悪化するならば、許容できる範囲の CommitLatency に収まる更新頻度はどの程度か、といったことなど考える。 66

Slide 67

Slide 67 text

見かけ上の性能と許容できる性能 - AZ間でレプリケーションしつつバックアップすることが前提であれば、最終的にAZ間で同期可能な速度によって、更新性能は律速されうる。 - 非同期レプリケーションであれば一見更新性能は高そうに見えることもあるが、実際はレプリケーションで遅延しない範囲の更新頻度が求められる。 67

Slide 68

Slide 68 text

SQLの実行計画 - 「〇〇互換」といってるデータベースは、何かしらの拡張をしたり、Optimizerに手を入れている可能性がある。ゆえに、そのようなデータベースに移行する場合、アプリケーションで使っている既存のSQLで実行計画が変わってしまい、性能に影響が出る可能性も考えられる。 68

Slide 69

Slide 69 text

実行計画についての補足 - MySQL自身であっても、バージョンアップに伴ってSQLの実行計画は変わってくる。 RDBMSはバージョンアップすれば、何かしら実行計画は変わる可能性があると考えた方が良い。 69

Slide 70

Slide 70 text

インデックスやオプティマイザ - バージョンアップのときであれ、互換性のあるデータベースに移行するときであれ、optimizer の挙動が変わったり、使うindexが変わってしまう可能性などはある。 - 必要に応じてインデックスヒントなどを使ったり、 MySQLであればoptimizer_switchなどで optimizerの挙動を調整する必要がでてくることも。 70

Slide 71

Slide 71 text

MySQLのoptimizer_switchの補足 - バージョンアップなどでオプティマイザの挙動が変わって一部のSQLの実行計画が変わり性能上の問題が出たときなど、必要最小限の設定変更に留める方が無難と考えられる。 - 必要以上にパラメータチューニングしてしまうと、次回のバージョンアップの際に足枷となりうる。 71

Slide 72

Slide 72 text

SQLを保守する上で意識したいこと - （サービスの必要上仕方のないケースもあるだろうが）できる範囲でシンプルなSQLをメンテナンスし続けるよう心がけた方が、DBの移行やバージョンアップの足枷となりにくい。 72

Slide 73

Slide 73 text

SpannerのOptimizer - SpannerはdefaultだとOptimizerの新しいバージョンが出て30日以上経過したら、新しいバージョンを使うようになるとある。 - このようなことも考えると、やはりSpannerは FORCE_INDEXを指定することで、Optimizer が変わっても使うインデックスが変わらないようにした方が安定するのでは 73

Slide 74

Slide 74 text

メンテナンスやバージョンアップ 74

Slide 75

Slide 75 text

通信断を伴うメンテナンスの頻度は - 今使っているものとは異なるマネージドサービスに移行する際、通信断を伴うセキュリティアップデートやメンテナンスの頻度は、どれくらい変わるのか。 - 運用しているサービスのSLAとして許容できる範囲なのか。 75

Slide 76

Slide 76 text

バージョンアップの頻度は - 対象のRDBMSのメジャーバージョンは、どれくらいの期間メンテナンスされるのか - 例：MySQLは一つのメジャーバージョンが8年メンテナンスされる - 一定期間での強制マイナーバージョンアップなどは、発生しないのか 76

Slide 77

Slide 77 text

バージョンアップの際に要する時間は - ゼロダウンタイムでアップデート可能なのか？ - あるいは、数秒程度の断が発生し、トランザクションのリトライなどで吸収できる範囲なのか？ - それとも、バージョンアップの際は数時間単位で運用しているサービスを止めないといけないのか？ 77

Slide 78

Slide 78 text

トランザクションのリトライ - DBの移行に伴ってリトライ処理を追加する必要がある場合、どのレイヤーで実装するのか、移行する際にアプリケーション書き換える必要があるのか。 - 例えばSpannerはトランザクションがabortしやすい特性があるものの、クライアントライブラリ側でリトライする仕組みが提供されている。クライアントライブラリの機能を含めて、RDBMSは評価したほうが良い。 78

Slide 79

Slide 79 text

failover時の再接続処理 - Amazon Aurora では、フェイルオーバーを高速化して数秒程度の切り替えできる Advanced JDBC Wrapper Driver が公開されている - SLAによってはサービス停止なしでswitch over など検討できる可能性も出てくるので、クライアントライブラリ込で評価するのはとても大切。 79

Slide 80

Slide 80 text

周辺のサービス - Amazon Auroraを使う際にAdvanced JDBC Wrapper Driverが使えなかったとしても、 Amazon RDS Proxy を使うことでfailoverの時間を短縮できたりもする。 - 周辺のサービスも込みで評価することは大切。 80

Slide 81

Slide 81 text

まとめのようなもの 81

Slide 82

Slide 82 text

- 他のRDBMSに移行するより、いま使っている RDBMSのバージョンアップをやっていく方が、普通は圧倒的に容易。 - 特に互換性のないRDBMSに移行するのは、かなりハードルが高いと認識した方が良い。 82

Slide 83

Slide 83 text

- 一部の仕様や機能、スケーラビリティの改善やコストなどの理由から移行したいこともあるだろうが、実現性はあるのか、移行のために費やしたコストは回収できそうか考慮して取り組んだ方が良い。 83

Slide 84

Slide 84 text

- 現代において、異なるRDBMS間の移植は生成 AIなどによってハードルが下がってきているかもしれない。 - ただ、SQLなどを書き換えることができたとしても、挙動や性能特性などが異なったりもするので、テストや負荷試験などをそのぶん手厚くやった方が良いのでは。 84

Slide 85

Slide 85 text

テストが大事ですよ！ 85

Slide 86

Slide 86 text

References - ArkEdge Space Blog | できれば知らずに済ませたかった Aurora DSQL非互換集 - MySQL Blog Archive | MySQL 8.0 Source Code Improvements - 組織をランサムウェアの脅威から守るためのベストプラクティス - MySQL Blog Archive | MySQL 8.0: ひらがなカタカナを判別する日本語用Collation 86

Slide 87

Slide 87 text

References - tmtms のメモ | MySQL と PostgreSQL のコレーション - 【TiDB GAME DAY 2024】TiDBにおけるテーブル設計と最適化の事例 - 【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術 - トランザクションを「本気で使いこなす」ための必須知識。 PostgreSQLコミッターが教える活用術 87

Slide 88

Slide 88 text

References - Cloud Spanner の自動生成主キーを使ってみる - Amazon Aurora 向け Advanced JDBC Wrapper Driver のご紹介 - Amazon RDS Proxy を使用したアプリケーションの可用性の向上 88

Slide 89

Slide 89 text

おわり 89