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

「データベースを異なる環境や互換性のあるマネージドサービスなどに移行する際、どういうことを考えてるか、幅広い層に向けて話してください」みたいなことをいわれたのでかきました

Transcript

1. 互換性のある（らしい） DBへの移行など 考えるにあたって たいへんざっくり sejima
2. 免責事項 - 本資料において示される見解は、私自身の見 解であって、私が所属する組織の見解を必ずし も反映したものではありません。ご了承くださ い。 2
3. はじめに - 社内で「データベースを異なる環境や互換性の あるマネージドサービスなどに移行する際、どう いうことを考えてるか、幅広い層に向けて話して ください」みたいなことを言われたんですが。 - いろいろ考えてるので、今日は簡単な概要だけ 話します。 3
4. 世の中的な背景的な - 現代においては「〇〇互換のマネージドサービ ス」「〇〇互換の分散DB」みたいな選択肢が増 えてきて、かつ、それらに移行するためのコード の生産性も上がってきてると思います。 - ただ、互換性などで知識として知っておいた方 が良いことはあるかなと思ったので書きました。 4
5. 補足・その一 - 個人的に、データベースの移行については否定 的ではないです。 - むしろ、古いものを塩漬けにして環境の変化に 追随できなくなるのはたいへん不味いと思いま す。 - ただ、移行する前に知っておいた方が良いです よ、という話です。 5
6. 補足・その二 - MySQLを前提とした話でありつつ、RDBMSご との振る舞いの違いを示す例として、 PostgreSQLやSpanner、TiDB、Aurora DSQL などについても、ところどころで触れています。 - ただMySQLみたいにソースコード読んだことな いので、個人的にざっくりとした印象で書いてま す。 6
7. 補足・その三 - ゲームやWebサービスなどでのデータベースの 利用を想定した内容となっているため、内容に 偏ってる部分がある可能性があります。 - 例えば、ミッションクリティカルなサービスなどであれば、 また違う考え方になるところもあったりするかと思いま す。 7
8. アジェンダのようなもの - まず最初に - 次に、データの保護やバックアップについて - 振る舞いについて - トランザクション関連 - 設計思想に起因する性能特性 - 性能 - メンテナンスやバージョンアップ - まとめのようなもの 8
9. では 9
10. まず 最初に 10
11. 「◯◯と互換性100%」と 言われても 11
12. そんな わけない 12
13. 信じられ ない 13
14. 「◯◯と互換性 100%」 - 独自実装であれば、そもそも互換性100%とは 普通ならない。 - 互換性100%と言ってる場合は、同じクライアントライブ ラリが使える == プロトコル的に互換性がある程度で、 実際の機能や挙動、性能特性までは互換性がない。 - MySQLからforkしたものであっても、独自実装 の部分で振る舞いが変わったりする。 14
15. - SQLのsyntaxに一部互換性がないケースも考 えられる - SQLを独自に拡張している場合、予約語を独自に追加 されている可能性も考えられる。既存のツールはそのま ま動くのか？（いまどき気にするようなことでもないだろう けど）アプリケーション側のソースコードでちゃんとエス ケープできてるか？ 15
16. 互換性のある DBに移行する際の心構え - （実際にそこまで大変なケースは限られている だろうが）メジャーバージョンアップと大差ないつ もりで臨んだ方が無難 - 「〇〇をベースに」とか「〇〇互換」と言われて も、そのまま動作するとは限らない - 例えば、Aurora DSQLはPostgreSQL非互換の部分も ある 16
17. - 普通、他のRDBMSに移行するよりも、いま使っ ているRDBMSのメジャーバージョンアップをす る方が、実現性は高い。 - もし互換性がないRDBMSに移行するとなると、（基本的 に）アプリケーション側で大規模な改修が必要になると 考えて良い。 17
18. 独自実装であるがゆえのデメリット - 本家との差分が大きいということは、本家で新し いメジャーバージョンが出たとき、追随するのに 時間がかかる - 例えばMySQLは8.0のときに Coding Guideline などが 一気に変わってソースコードがかなり書き直された。 MySQLをforkしている各社のマネージドサービスで差分 が大きいと、こういうとき追随するのが大変になる。 18
19. 複数のバージョンを運用する可能性 - もし、複数のパブリッククラウドを利用して複数 の環境を運用していると、複数のメジャーバー ジョンを運用し続けなければならなくなる可能性 がある。他の環境では延長サポート料金の発生 を避けるために、メジャーバージョンアップする ことはある。 19
20. - 例えば、RDS for MySQL 8.0の標準サポート終 了は2026年7月31日、CloudSQL for MySQL 8.0の拡張サポート開始日は2027年1月1日と なっている。 - 自分たちが利用しているMySQL互換のマネージドサー ビスが他にもあって、それが8.4対応できていなければ、 8.0と8.4の環境両方をメンテナンスし続けることになる。 20
21. - 延長サポート料金を避けるためにDBのメジャー バージョンアップをする際、クライアントライブラ リ側のバージョンアップも必要になる可能性が ある。それでも他の環境のDBのバージョンが古 ければ、クライアントライブラリなども複数の バージョンを管理する必要が出てくる恐れがあ る。 21
22. 次に、 データの保護や バックアップについて 22
23. データ保護の観点 - （いまどき当たり前だろうけど）暗号化機能があ るかどうか - 例：EBSの volume snapshotなどは、暗号化されていな い場合、設定ミスの結果、他のAWSアカウントにclone できて漏洩してしまうリスクが想定される。 - volumeやsnapshotが、アカウント内に閉じた鍵で暗 号化されていれば、鍵がなければ別のアカウントで cloneして中身を見ることはできない。 23
24. データのバックアップ - AZ障害は発生すると想定する必要がある。 - AWSの東京リージョンだけでも、2019-08-23と 2021-02-20にデータセンターの冷却システム起因の大 規模障害が発生した。 - AZレベルの大規模障害が発生したとき、影響 範囲がAZ内に限定されない、不測の不具合が 発生することがある（じっさいあった）。 24
25. リストアする際の整合性も気に掛ける - どんなパブリッククラウドであっても、シングル AZに閉じた設計は一定のリスクがある。複数の AZあるいはリージョンでデータを複製しバック アップできる構成が取れるか、バックアップから 整合性の取れた状態でリストアできるかどうか などが重要になってくる。 25
26. バックアップとリストアの補足 - ランサムウェア対策という観点においても、バッ クアップやリストアは重要なテーマ。 - 私はこの分野には疎いですが「DBのランサム ウェア対策どうしたらいいですか？」と聞かれた ら、まず次のblogを読んでみましょうという話を します。 26
27. - https://cloud.google.com/blog/ja/products/ide ntity-security/5-pillars-of-protection-to-preven t-ransomware-attacks - 単に「ランサムウェア対策どうしよう？」だと扱う テーマが広範で議論が発散しやすいので、「今 日は復元をテーマにバックアップとリストアにつ いて検討しましょう」みたいな提案をしていま す。 27
28. 移行する前に整理すること - これから移行するシステムは、どの程度の規模 の障害を想定し、どの程度の時間で復旧できる 必要があるのか - AZ障害だけでなくリージョン障害も想定するのか - 何時間以内に復旧する必要があるのか - 移行前の構成で想定されていたRecovery Time Objectiveは維持できるのか、あるいは改 善するのか 28
29. 振る舞いについて 29
30. 振る舞いの観点 - データベース側だけでは決まらない - プログラミング言語ごとにDBのクライアントライブラリの 実装が異なるケースがある。プログラミング言語ごとに、 クライアントライブラリの振る舞いが異なるケースがあ る。クライアントライブラリの実装とDB側の実装の組み 合わせが重要。 - 参考： - https://labs.gree.jp/blog/2024/03/23110/ - https://labs.gree.jp/blog/2023/07/22581/ 30
31. 文字コード - アプリケーションで使っている文字コードを、 RDBMSでサポートできていればよいというもの ではない。（いまどきUTF-8使ってないところは 珍しいだろうけど） - 例えばMySQL は character set について client <-> server 間で handshake する - （MySQL8.0まではそのhandshakeをスキップするオプ ションが有る） 31
32. - MySQLのhandshakeに関する振る舞いは、プ ログラミング言語ごとに独自実装されているクラ イアントライブラリに依存する。 - 例えばPHPのmysqlndはmysqld側で設定され たcharacter_set_serverの値に従い handshakeをスキップするので、mysqld側で character_set_serverを設定できるかが重要 32
33. 文字コードの不可逆変換 - MySQLはclient <-> mysqld 間で自動で文字 コード変換をすることもできるが、仕様上不可逆 変換が存在する。これはUnicodeの仕様の問 題。 33
34. 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
35. Unicodeの仕様が修正されることも - Unicode 7.0以前の仕様書ではU+301C, WAVE DASH を使うべきところでU+FF5E, FULLWIDTH TILDEが使われてしまっていた が、Unicode 8.0以降で修正されたことがあっ た。 - Wikipedia | 波ダッシュ 35
36. 文字コードの変換は要注意 - クライアントライブラリとRDBMS間で文字コード の変換をしてくれるのは便利ではあるが、不可 逆変換が発生しないか注意する必要がある。 - できれば、プログラミング言語とクライアントライ ブラリとRDBMS間で、文字コードは揃える方が 無難。 36
37. Unicodeのcollation（照合順序） - アプリケーションやRDBMSでUTF-8を使ってさ えいれば良いという話ではない。 - collation（照合順序）含めて互換性の問題があ る。 37
38. 絵文字や合字の扱い - MySQLのサポートしているUnicodeのバージョ ンは9.0と古いので、最近の絵文字や合字の扱 いに一部制限がある。 - 例えば、2019年に追加された令和の合字を”令和”と同 じものだと識別できない。”㍻”と”平成”はわかる。 - 例： - https://gist.github.com/sejima/40174345ff2714e7 53d2fd448696a618#file-gistfile3-txt 38
39. ソート順や一意性制約への影響 - collation含めて互換性が担保できないと、文字 列のソートの順番が変わってしまう。また、文字 列のUNIQUE KEYがあったときに挙動が変 わってしまう。 - MySQLは8.0でdefaultのcollationが変わってし まったので、5.7以前から稼働しているDBを8.0 に移行する場合、5.7以前のdefaultのcollation に設定可能かというのも重要。 39
40. 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
41. MySQL 8.0でdefaultのcollation設定 - （いくつか方法はあるのだが）MySQL互換のマ ネージドサービスであれば、SUPER権限も CONNECTION_ADMIN権限もないアカウント でアクセスするなら init_connect パラメータで collation 周りの設定を毎回上書きするようにす れば、わりと上手く行く。 - 参考：https://labs.gree.jp/blog/2024/03/23110/ 41
42. - MySQL互換のマネージドサービスへ移行を検 討する場合であったとしても、次のような点は移 行しやすさを実現するうえで重要 - アプリケーション側で使うMySQLアカウントに、必要以 上に強い権限を持たせない。 - アプリケーション側で使うMySQLアカウントやパスワー ドを、変更しやすい仕組みにしておく。（移行時に init_connectなど使うなら、新規作成したアカウントに切 り替えやすい設計になっているか） 42
43. Unicodeのcollationについて補足 - 例えばTiDBはMySQLのソースコードをforkして いるのではなく独自実装なので、collationなど 文字列の扱いについては要注意 - PostgreSQLはOS側に（外部ライブラリに） collationの処理を委譲しているので、MySQLと はそもそも挙動が一致しない。 - 参考： とみたさんの資料が秀逸 43
44. 認証プロトコル - MySQL 9.0でmysql_native_password が削除 された。 - MySQL 9.x 以降では caching_sha2_passwordが必須になったが、 この振る舞いもプログラミング言語ごとに異な る。このことを想定した事前調査などはやった方 が良い。 44
45. caching_sha2_passwordの補足 - （たいへんざっくりいうと）mysqldと接続を確立 する際、SSLで通信するか、公開鍵をmysqld側 から取得するオプションを使うことが必要にな る。 - そして、プログラミング言語ごとにクライアントラ イブラリの実装が異なっている。（オプションで はなく、デフォルトで公開鍵を取得する挙動のラ イブラリがある） 45
46. TLSやOpenSSLのバージョン - TLS使って接続しようとしても、クライアント側で 使えるTLSのバージョンが古すぎるとmysqldに 接続できない。MySQL 8.0.28以降、TLSv1や TLSv1.1は削除されている。 - （いまどきあまりないと思うが）環境が古すぎる とOpenSSLのライブラリが古くて TLSv1.2や TLSv1.3を使えない可能性もある。 46
47. トランザクション関連 47
48. トランザクション分離レベル - 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
49. - ANSI/ISO SQL標準で SERIALIZABLE、 REPETABLE READ、READ COMMITTED、 READ UNCOMMITTEDといった４種類のトラ ンザクション分離レベルが定義されている。た だ、それぞれの振る舞いは、MySQL互換云々 以前に、そもそもRDBMSごとに微妙に異なった りする。 49
50. 主要RDBMS製品の比較について - 近年、渡部さんが db tech showcase で登壇し てお話されてるテーマなので、公開された資料 を読んだら参考になると思います。 - https://x.com/wrcsus4/status/1943499418541629626 - https://x.com/wrcsus4/status/1811305297413059067 50
51. ロングトランザクションは避けたい - ロングトランザクションはロックの競合やデッド ロック、性能劣化などの原因となりうるので基本 的に避けたいところ。 - ロングトランザクションとの相性は、RDBMSの 設計次第で更に悪くなるケースもある。 - DBを移行した結果、ロングトランザクション起因の問題 が悪化する可能性もある。 51
52. 例：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
53. 例：TiDB - Transaction too largeでエラーになるケース や、REPEATABLE READでLost Updateが発 生してしまうケースなど、Cygamesさんの丁寧 な解説資料が存在します。 - 【TiDB GAME DAY 2024】TiDBにおけるテーブル設計 と最適化の事例 - 【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術 53
54. 例：PostgreSQL - ロングトランザクションによってVACUUMが効 かなくなるため、PostgreSQLのCommitterであ らせられる藤井さんも「トランザクションの粒度 は、本当に必要な処理だけに絞り込む」と仰ら れています。 - トランザクションを「本気で使いこなす」ための必須知 識。PostgreSQLコミッターが教える活用術 54
55. Upsertなどのロックの範囲 - MySQLのバグ修正で5.7.26以降、一部のス テートメントでロックの範囲が厳しくなってデッド ロックが発生しやすくなったと、Aurora MySQL のドキュメントなどで注意喚起された。 - 具体的には INSERT...ON DUPLICATE KEY UPDATE などのようなもの 55
56. ロックの範囲やデッドロックなど - Upsert のロックの範囲やデッドロックは、アプリ ケーションで使うトランザクション分離レベルを 変更することで緩和できるケースもある。 - ただ、TiDBやAurora MySQLの例を見るよう に、同じREPETABLE READ、同じREAD COMMITTEDでも、完全な互換性があるわけ ではない。 56
57. 設計思想に起因する 性能特性 57
58. 性能特性の観点 - レイテンシ - 設計上、MySQLなどと比べて分散DBはレイテンシが増 加する傾向にあると考えられる。分散DBに移行したい 場合、アプリケーション側でN+1のループがあったときに 耐えられるか - 分散DBでなかったとしても、マルチAZを前提としたアー キテクチャだった場合、AZ間のレイテンシはアプリケー ションから許容できる範疇に収まっているのか 58
59. 設計思想に基づく違い - MySQLなど分散データベースでないRDBMS は、primary key がシーケンシャルな値だと空 間効率が良いケースがある。 - MySQLのInnoDBはprimary keyをランダムな値でラン ダムにINSERTすると、テーブルがフラグメントする。 59
60. - 一方、Spannerはprimary keyがシーケンシャ ルな値だと hot spot ができやすい問題がある。 - Spannerに限らず、分散DBにおいてMySQLの auto_incrementのようなものはボトルネックになりがち。 - SpannerもSEQUENCEをサポートするようになったが、 bit_reversed_positive が必須など、他のRDBMSとは 異なる特性がある。 60
61. MySQLのauto_increment - MySQLのauto_incrementでさえ、複数のロック モードが存在していて、それぞれ挙動が異なり、 性能特性が異なる。 - 他のRDBMSで似たような機能があったとして も、MySQLのauto_incrementのどのモードと互 換性があるのか、それとも全く異なる挙動なの かというところがある。 61
62. 性能 62
63. 性能の観点 - アーキテクチャやそれに伴うハードウェア構成 はどのようなものか - 最初からマルチAZ前提の設計になっていれば、更新時 にCOMMITのレイテンシへの影響が発生する可能性が ある。 - 後づけでマルチAZ構成でデータをレプリケーションする 場合、レプリケーションの遅延を考慮して更新性能を評 価する必要がある。 63
64. 例：Amazon Aurora の場合 - 最初からマルチAZ構成を前提とした設計で、 COMMIT時には（内部的に）他のAZにもredo logを書き込んでいる。その結果、 CommitLatencyはAZ間通信のRTTの影響をあ る程度受けると考えられる。 - その一方で、COMMITに対する様々な最適化は独自実 装されている。 64
65. 例：MySQLを自前で立てる場合 - sourceとreplicaが非同期レプリケーションの場 合、sourceのCommitLatencyはreplicaの影響 を受けないが、Auroraと比べてレプリケーション の遅延は発生しやすくなる。 - sourceとreplicaが準同期レプリケーションだっ た場合、sourceのCommitLatencyはsourceと replicaの間のRTTの影響を受ける。 65
66. ベンチマークを取るうえで - ベンチマークを流した際、見かけ上は高い性能 を出しているように見えたとしても、レプリケー ションなども考慮しつつ、実際に許容できるのは どの程度の更新性能になるのかを見極めるの が重要。 - 更新頻度が高いと CommitLatency が悪化するならば、 許容できる範囲の CommitLatency に収まる更新頻度 はどの程度か、といったことなど考える。 66
67. 見かけ上の性能と許容できる性能 - AZ間でレプリケーションしつつバックアップする ことが前提であれば、最終的にAZ間で同期可 能な速度によって、更新性能は律速されうる。 - 非同期レプリケーションであれば一見更新性能 は高そうに見えることもあるが、実際はレプリ ケーションで遅延しない範囲の更新頻度が求め られる。 67
68. SQLの実行計画 - 「〇〇互換」といってるデータベースは、何かし らの拡張をしたり、Optimizerに手を入れている 可能性がある。ゆえに、そのようなデータベース に移行する場合、アプリケーションで使っている 既存のSQLで実行計画が変わってしまい、性能 に影響が出る可能性も考えられる。 68
69. 実行計画についての補足 - MySQL自身であっても、バージョンアップに 伴ってSQLの実行計画は変わってくる。 RDBMSはバージョンアップすれば、何かしら実 行計画は変わる可能性があると考えた方が良 い。 69
70. インデックスやオプティマイザ - バージョンアップのときであれ、互換性のある データベースに移行するときであれ、optimizer の挙動が変わったり、使うindexが変わってしま う可能性などはある。 - 必要に応じてインデックスヒントなどを使ったり、 MySQLであればoptimizer_switchなどで optimizerの挙動を調整する必要がでてくること も。 70
71. MySQLのoptimizer_switchの補足 - バージョンアップなどでオプティマイザの挙動が 変わって一部のSQLの実行計画が変わり性能 上の問題が出たときなど、必要最小限の設定 変更に留める方が無難と考えられる。 - 必要以上にパラメータチューニングしてしまうと、次回の バージョンアップの際に足枷となりうる。 71
72. SQLを保守する上で意識したいこと - （サービスの必要上仕方のないケースもあるだ ろうが）できる範囲でシンプルなSQLをメンテナ ンスし続けるよう心がけた方が、DBの移行や バージョンアップの足枷となりにくい。 72
73. SpannerのOptimizer - SpannerはdefaultだとOptimizerの新しいバー ジョンが出て30日以上経過したら、新しいバー ジョンを使うようになるとある。 - このようなことも考えると、やはりSpannerは FORCE_INDEXを指定することで、Optimizer が変わっても使うインデックスが変わらないよう にした方が安定するのでは 73
74. メンテナンスや バージョンアップ 74
75. 通信断を伴うメンテナンスの頻度は - 今使っているものとは異なるマネージドサービ スに移行する際、通信断を伴うセキュリティアッ プデートやメンテナンスの頻度は、どれくらい変 わるのか。 - 運用しているサービスのSLAとして許容できる範囲なの か。 75
76. バージョンアップの頻度は - 対象のRDBMSのメジャーバージョンは、どれく らいの期間メンテナンスされるのか - 例：MySQLは一つのメジャーバージョンが8年メンテナン スされる - 一定期間での強制マイナーバージョンアップな どは、発生しないのか 76
77. バージョンアップの際に要する時間は - ゼロダウンタイムでアップデート可能なのか？ - あるいは、数秒程度の断が発生し、トランザク ションのリトライなどで吸収できる範囲なのか？ - それとも、バージョンアップの際は数時間単位で 運用しているサービスを止めないといけないの か？ 77
78. トランザクションのリトライ - DBの移行に伴ってリトライ処理を追加する必要 がある場合、どのレイヤーで実装するのか、移 行する際にアプリケーション書き換える必要が あるのか。 - 例えばSpannerはトランザクションがabortしやすい特性 があるものの、クライアントライブラリ側でリトライする仕 組みが提供されている。クライアントライブラリの機能を 含めて、RDBMSは評価したほうが良い。 78
79. failover時の再接続処理 - Amazon Aurora では、フェイルオーバーを高速 化して数秒程度の切り替えできる Advanced JDBC Wrapper Driver が公開されている - SLAによってはサービス停止なしでswitch over など検討できる可能性も出てくるので、クライア ントライブラリ込で評価するのはとても大切。 79
80. 周辺のサービス - Amazon Auroraを使う際にAdvanced JDBC Wrapper Driverが使えなかったとしても、 Amazon RDS Proxy を使うことでfailoverの時 間を短縮できたりもする。 - 周辺のサービスも込みで評価することは大切。 80
81. まとめのようなもの 81
82. - 他のRDBMSに移行するより、いま使っている RDBMSのバージョンアップをやっていく方が、 普通は圧倒的に容易。 - 特に互換性のないRDBMSに移行するのは、かなり ハードルが高いと認識した方が良い。 82
83. - 一部の仕様や機能、スケーラビリティの改善や コストなどの理由から移行したいこともあるだろ うが、実現性はあるのか、移行のために費やし たコストは回収できそうか考慮して取り組んだ方 が良い。 83
84. - 現代において、異なるRDBMS間の移植は生成 AIなどによってハードルが下がってきているか もしれない。 - ただ、SQLなどを書き換えることができたとして も、挙動や性能特性などが異なったりもするの で、テストや負荷試験などをそのぶん手厚くやっ た方が良いのでは。 84
85. テストが 大事ですよ！ 85
86. References - ArkEdge Space Blog | できれば知らずに済ませたかった Aurora DSQL非互換集 - MySQL Blog Archive | MySQL 8.0 Source Code Improvements - 組織をランサムウェアの脅威から守るためのベスト プラク ティス - MySQL Blog Archive | MySQL 8.0: ひらがなカタカナを判 別する日本語用Collation 86
87. References - tmtms のメモ | MySQL と PostgreSQL のコレーション - 【TiDB GAME DAY 2024】TiDBにおけるテーブル設計と最 適化の事例 - 【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術 - トランザクションを「本気で使いこなす」ための必須知識。 PostgreSQLコミッターが教える活用術 87
88. References - Cloud Spanner の自動生成主キーを使ってみる - Amazon Aurora 向け Advanced JDBC Wrapper Driver のご紹介 - Amazon RDS Proxy を使用したアプリケーションの可用性 の向上 88
89. おわり 89