yukiotechblog

Category

database

31 articles

TiDBのLONGTEXT型にはデフォルト設定では6MiBまでしか保存できないことを検証してみた

はじめに TiDBのLONGTEXT型の最大列長は 4,294,967,295 ですが、実はデフォルト設定では6MiB以上のデータはエラーで保存できなくなっています。 今回はその回避方法について1つずつ検証しながら解説します。 結論 先に結論を書いておくと、以下の通り設定をいじって保存できるデータサ

マルチテナントのスキーマレベル分離をどのように実装するか？[マルチテナントアーキテクチャ]

現状のテナント分離構造「インスタンスレベル分離」 私が関わっているプロダクトでは図のような「インスタンスレベル分離」というテナント分離構造になっています。 具体的にはテナント毎にアプリケーションが別れており、DBクラスタSQL Serverも同様にテナント毎に別れている状況です。 DBからテナントの

TiDB Cloudで外部キー制約のチェックをGLOBALスコープでオフにしても、引き続きチェックが走る [TiDB Cloud Dedicated]

やりたかったこと「外部キー制約のチェックをオフにしたい」 TiDB Cloudでの性能試験時にインサートのクエリが遅くなっており、実行計画を見ると外部キー制約のチェックで4秒ほど時間を使っていることがわかりました。 TiDBにおいて外部キー制約によってインサートが遅くなる理由については以下の記事で紹

外部キー制約によるインサートの性能劣化はNewSQLの意外な欠点

NewSQLの代表的な欠点「レイテンシー」 NewSQLの欠点としてよく上がるのが「レイテンシー」です。 これは分散DBである程度強いデータ整合性を達成しようと思うと、仕方ない話なのかなと思います。 構造的にも納得できます。 意外な欠点「外部キー制約で性能劣化する」「外部キー制約が使えない」 多少レ

[SQL Server] パーティション化したテーブルのidのユニーク性を保障する方法に関する検討

課題「パーティションテーブルではテーブル内でidがユニークであることを保障できない」 パーティションを導入したテーブルはパーティションキーとidの複合キーが主キーになる そのため、原理上、テーブル内でidがユニークであることを保障できないと言う懸念点が存在する また、idにidentity列を指定し

7億行のテーブルにパーティション導入することでdelete文の速度が4.7倍高速化した

はじめに 今回は、7億行ものデータ行を持つテーブルの日付カラムにパーティションを導入することで、delete文が高速になるかどうかを検証しました。 また、検証対象テーブルのファイルグループを、デフォルトでデータが格納されるPRIMARY以外にすることで、さらに高速化の効果が得られるかについても調査し

[SQL Server] 行ロックを取りすぎるとテーブルロックに変わる

ロックエスカレーションとは SQL Serverには注意すべき挙動として、ロックエスカレーションというものがあります。 ロックエスカレーションとは、あるテーブルに対して行ロックを取得しすぎた場合に、代わりにテーブルロックを取得する挙動です。 ロックエスカレーションの発生条件 具体的には、以下のいずれ