yukiotechblog

All posts

Articles

aiamazon-auroraapache-kafkadatabasefintechgolangjavalinuxmysqlnixossperformancepostgresqlsoftware-designsql-serversqlitetechnical-debttidb失敗小説

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列を指定し

[読書レビュー] 「松岡まどか、起業します　AIスタートアップ戦記」は2025年のAIエージェントの普及を描いている

はじめに 2024年の年の瀬にシュッと読んだ本がなかなか面白く、テーマも生成AIと皆さんのお仕事にも少し役立ちそうな気がしたので、せっかくなのでブログで共有します。 概要 この小説は新卒で生成AIスタートアップを立ち上げるSF小説です。 日本有数の大企業・リクディード社のインターン生だった女子大生の

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

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

[書評] ソフトウェアエンジニアが「生産技術あるある (著)生産技術の馬」を読んでみた

はじめに 私はfintech企業でプログラマーをしており、工場の生産技術者とは全くの関係がありません。 しかし、YouTuberの「生産技術の馬さん」が出版した「生産技術あるある」がプログラマーにとってもあるあるな内容を含んでいたので、書評のような形でプログラマーにとってもあるあるな部分と、生産技術

コード例で深ぼるEffectiveJava~「第2章コンストラクタの代わりにstaticファクトリメソッドの使用を検討する」の深掘り~

はじめに 本記事では名著Effective Java第3版https://amzn.to/4hwNdQhで言及されているtipsをより深掘りするために、さまざまなコード例を交えて考えるというものになります。 今回は第2章 オブジェクトの生成と消滅の中の項目1「コンストラクタの代わりにstaticファ

正規表現のコンパイルをメモ化すると若干速くなるらしいのでローカル環境で検証してみた

はじめに 「Effective Java 第3版」の第2章の項目6に「不必要なオブジェクトの生成を避ける」という内容のものがあり、そこで正規表現のコンパイルはクラス変数にキャッシングした方がパフォーマンスを大幅に改善できるとのことが書いてあったので、実際に試して確認してみました。 検証環境 条件は以

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

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