まえがき 再帰SQLを使うと、テーブルに一時的に名前を付けることで、再帰処理(ループ)を実現できます。どのように実行されるのか難しかったため図解してみます。 with句 メインクエリの中で同じサブクエリを何度も呼び出している場合に使われるのがwith句です。with句を使うとサブクエリに名前をつけることができるので、メインクエリから何度でも呼び出すことができます。便宜上、with句によって作られる一時テーブルをwithテーブルと呼ぶことにします。with句を利用したクエリは、以下のように評価が進みます。 with句を評価し、withテーブルを作成する メインクエリを実行する。 まずは簡単な例でwith句の使い方を見てみましょう。営業マンたちの月別売上を表す営業成績テーブルを考えます。 【営業成績テーブル】 名前 月 月次売上

どういうことか たとえば created_at が最も新しいレコード 1 件だけ取ってきたいとか、成績のよいレコード上位 5 件を取ってきたいといったとき、よくある方法として RANK() や ROW_NUMBER() のような番号付け関数を使う方法が思い浮かぶと思いますが、BigQuery ではこれらの関数ではなく ARRAY_AGG() 集計分析関数を使うことが推奨されています。 先に結論を ARRAY_AGG() を使うことでクエリの計算を最適化でき、スロット使用量（計算量）が少なく済みます。スロット使用量の上限を定めている場合、非効率なクエリがいくつも実行されるとキューイングされる可能性があるため理由がなければ ARRAY_AGG() を使いましょう。 ドキュメントによれば ORDER BY 句が各 GROUP BY 句のトップレコードを除くすべてを捨てることができるため効率がいい

SurrealDB offers a dynamic and adaptable platform for business. With an integrated suite of cutting-edge database solutions, tools, and services, SurrealDB empowers your workforce to discover innovative answers using products meticulously crafted to meet their requirements. Database, realtime API layer, and security permissions all-in-one SurrealDB combines the database layer, the querying layer,

n番煎じ、今更ながら…。 ChatGPTは過去遊びでしか使ったことがなかったのですが、 今、超長文SQL群を改修してまして、何重にもなった副問合せと集計関数を読み解くのに疲れて…ChatGPTに手を出しました。 そして、 え！！ChatGPTやばい！！ 介護は必要だけどすぐ形にしてくれるしなんなら私より知識あるわ！！ 只今、職を失いました！！ ってなったので、この衝撃を書き残しておこうと思います。 やりたいこと 作るSQLの要件はざっくり、 dba_hist_sysstatから、physical readsなど各統計情報のvalueの増分値を取得する 統計情報種別毎・1日毎に、1ヶ月間集計 日時判別のために、dba_hist_snapshotと結合する valueには累積値が入っている。ただし、インスタンス再起動があるとリセットされる。 つまり、「累積だから」と直前のスナップショットのva

Are You Sure You Want to Use MMAP in Your Database Management System? Memory-mapped (MMAP) file I/O is an OS-provided feature that maps the contents of a file on secondary storage into a program’s address space. The program then accesses pages via pointers as if the file resided entirely in memory. The OS transparently loads pages only when the program references them and automatically evicts page

分析のためにSQLを使う際、window関数はとても便利です。一方でとっつきにくい考え方や、情報が少なかったりしてどうしても敬遠してしまいがちです。例を交えて簡単にまとめてみたいと思います。 window関数とは PostgreSQLの公式ドキュメントには以下のように説明があります。 A window function performs a calculation across a set of table rows that are somehow related to the current row. This is comparable to the type of calculation that can be done with an aggregate function. But unlike regular aggregate functions, use of a wind

5,500超のMySQLインスタンスを少人数で運用するには - LINEのDB運用効率化・自動化の取り組み 大きなサービスであれば、それを支えるデータベースの規模もまた大きくなるでしょう。LINE社のデータベースの規模は、2021年11月時点でMySQLのインスタンス数5,500超。巨大なデータベースの運用を効率化、自動化するための工夫やノウハウをLINE社のDBAに聞きました。 日本国内だけで、8900万人以上という膨大なMAUを抱えるコミュニケーションアプリ「LINE」をはじめ、多くの大規模サービスを運営するLINE株式会社（以下、LINE）が取り扱うデータ量は膨大です。使用するデータベースの規模は、なんと、2021年11月時点でMySQLのインスタンス数5,500超。これほど多くのインスタンスを管理しているにも関わらず、同社でMySQLの運用に携わるDBA（Database Admi

初めまして。株式会社カミナシPMの@gtongy1です。 みなさんはNewSQLをご存知ですか？ 強い整合性を持つ分散型のSQLデータベースサービスのことをNewSQLと呼びます。 RDBMSではなし得なかった分散アーキテクチャを、またNoSQLではなし得なかった強い整合性をいいとこ取りした新しいSQLデータベースサービスです。 なんかとても理想的な仕組みに見えますね。この裏にはどのような知識が詰め込まれているのでしょうか。 今回はそんなNewSQLを支える仕組みを一緒に紐解いていきましょう！ NewSQLが乗り越えた壁 どんな仕組みが動いているのか、の前にNewSQLはこのSQLデータベース界へ何を投げ込んだのでしょうか。 NewSQLには以下のような特徴があります。 SQL-Likeなクエリ言語のサポート 強い整合性 ACIDサポートのトランザクション NewSQLの有名所であるCoc

前回の記事で少し触れましたが、 go-sql-driver/mysql にドライバ側でのプレースホルダ置換を実装するプルリクエストを出していました。 それがマージされたので、背景のおさらいと利用方法を紹介しておきます。 背景 Go の database/sql の概要については前回の記事で解説しました。 そこで説明したとおり、 DB.Prepare() を使わずに直接 DB.Exec() や DB.Query() を使った場合、 ドライバ側でのプレースホルダ置換に対応していないドライバでは prepare, exec, close で3回のラウンドトリップが発生することになり、パフォーマンスが悪くなります。 基本的には DB.Prepare() を使えばいいのですが、前回の記事で修正したスケーラビリティの問題は Go 1.5 になるまで直りませんし、 IN 句があるSQL文などで事前に P

トランザクション分離レベルについての教養があったほうがこの記事の内容を理解しやすいため，必要に応じてまず以下を参照されたい。 背景 以前， Qiita で以下の記事を投稿した。今回の議題に直接的な関係はないが，関連している部分があるため引用する。 MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。

19th June 2021 The new sqlite-utils memory command can import CSV and JSON data directly into an in-memory SQLite database, combine and query it using SQL and output the results as CSV, JSON or various other formats of plain text tables. sqlite-utils memory The new feature is part of sqlite-utils 3.10, which I released this morning. You can install it using brew install sqlite-utils or pip install

「Rails Developers Meetup 2018 で「MySQL/InnoDB の裏側」を発表しました」でちゃんと触れられてないので今更ながら key_len について補足します。発表で触れた内容については言及しないので、storage engine や B+ tree といった用語がよくわからない方は発表内容を参照してください。 なお、MySQL のバージョンは 5.7.38 です。 mysql> SELECT @@version; +-----------+ | @@version | +-----------+ | 5.7.38 | +-----------+ 1 row in set (0.00 sec) 事前準備 sample-data-railsdm-2018 の orders テーブルを少しいじって、キャンセル時刻（canceled_at）、配送予定時刻（deliv

概要 インデックスに対してMongoDBはB Treeを採用し、MySQLのInnoDBはB+ Treeを採用しています。 どうして採用しているアルゴリズムが違うのだろう？と思って調べてみました。 主な違い B+ TreeはほとんどB Treeと同じですが、以下の点が異なります。 リーフノードとリーフノードを結ぶポインタがある データはリーフノードのみに保持する 具体例 言葉だけだと分かりにくいので、Visualizeするツールを使って具体例を表示します。 [1, 2, 3, 4, 5, 6, 8, 10, 15, 18]という数列に対し、Order: 3で作ってみます。 Orderは１ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの

結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:

はじめに CockroachDBはACIDトランザクションをサポートする分散型のSQLデータベースです。 ちなみにCockroachはゴキブリという意味です。 以下の"Get Started"を参考に、実際にCockroachDBをローカル（3ノード～5ノード）で動かしてみます。 なお、"Get Started"では以下の操作を実施することになります。 CockroachDBのインストール ローカルクラスターを起動 SQLの実行 サンプルワークロードの実行 Admin UIへのアクセス ノードをダウンさせてみる クラスターをスケール クラスターを停止 CockroachDBのSQLを学ぶ テーブル一覧を表示 テーブルを作成 レコードを挿入 インデックスを作成 テーブルのインデックスを表示 テーブルを検索 レコードを更新 レコードを削除 テーブルを削除 環境 使用する環境は以下になります。

Opens in a new windowOpens an external siteOpens an external site in a new window Databases are a key scalability bottleneck for many web applications. But what if you could make a small change to your database design that would unlock massively more efficient data access? At Shopify, we dusted off some old database principles and did exactly that with the primary Rails application that powers onl

株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な

参考資料 - https://soudai.hatenablog.com/entry/2021/02/02/200104 - https://soudai.hatenablog.com/entry/2021/12/31/114009 - https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-database-incident/ - https://devblog.thebase.in/entry/bsucon - https://eh-career.com/engineerhub/entry/2018/12/11/110000 - https://speakerdeck.com/soudai/soudai-evolution