SQLとElasticsearchのクエリがそれぞれどう対応しているのか、よく使われると思うものについて大体まとめました。 環境 Elasticsearch 6.2.4 〜 7.5 前提条件 記載する内容は以下の条件を前提とします。 Elasticsearchで検索する際のURLの記載は省略 Elasticsearchでは検索を行う際に以下のようなURLへリクエストします。 {ElasticsearchのURL}/{index名}/_search 例えばSQLでproductというテーブルに対して索引を行っている場合、Elasticsearchでは以下のURLへリクエストを行っています。 http://localhost:9200/product/_search 以降Elasticsearchのリクエスト先URLは記載しませんが、上述のようなURLへリクエストしている前提です。 文字列のデ
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
概要 全般 推奨 非推奨 命名規則 通則 表 列 別名、相関名 ストアド・プロシージャ 統一的接尾辞 問合せ文 予約語 空白類 インデント 望ましい形式 Create文 データ型の選択 デフォルト値の指定 制約とキー 非推奨設計 付録 予約語リファレンス SQLスタイルガイド（日本語訳） 日本語訳について 日本語訳は誤訳や原文の最新版に追随していない恐れがあります。誤訳や改善点があれば、GitHubのissueまたはpull requestを使用するか、Twitterでお知らせください。 翻訳: 久利史之 @nkuritw 概要 このガイドラインは利用の他、forkしたり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubのissueまたはpull requestを使用してください。 このガイドライン
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
comments | Column | Type | |------------|-----------------------------+ | id | bigint | | user_id | bigint | | content | text | | privacy | boolean | | created_at | timestamp without time zone | | updated_at | timestamp without time zone | likes | Column | Type | |------------|-----------------------------+ | id | bigint | | user_id | bigint | | comment_id | bigint | | created_at | timestamp witho
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
ぬいぐるみが好きな方のDBAです。 弊社ではMySQLのリソースモニタリングにCactiを利用していますが、こんな形の “InnoDB Row Operations” のグラフを見たことはないでしょうか。月初には低い値を示していたRows Read（水色のエリア）が月末に向かってだんだんだんだん伸びていくグラフです。 そして、月初になるとス㌧と落ちて月末に向かって大きくなっていって…を繰り返します。 よく訓練されたMySQLerのみなさまにはこのグラフを見ただけで原因の想像がつきそうなものだと思いますが、Innodb_rows_readがこのようなグラフの形を描く場合、ほとんどの原因はログテーブルのテーブルスキャン です。 月初はTRUNCATEや新しいテーブル（テーブル名_201705 とかでローテーションしたりするのに心当たりはありませんか？）への切り替え直後なので、テーブルスキャンで
エンジニアの南直 @south37 です。 速習会の内容 2015年12月10日に、 Wantedly のオフィスにてRailsエンジニアのためのSQLチューニング速習会を開催しました！ RailsはRDBをたたく際に、Active Recordが最適化をよしなにやってくれるので複雑な処理やサービスの規模が小さい段階ではRDBに向き合う場面はすくないかと思います。しかし、サービス規模が大きくなってきたり、複雑な処理を行ったり、高速化に本気で向き合うときは、Active Recordの仮面をはぎとりSQLと向き合って細かなチューニングをおこなっていく必要があります。 今回の速習会では、SQLのチューニングの基礎として、SQLが実行されるときRDBの中ではなにがおきているか、Explainの読み方、Indexの張り方などをまとめています。 発表スライドはこちら Wantedly速習会 Want
1 Active Recordクエリインターフェイスとは？ 生のSQLを使ってデータベースのレコードを検索することに慣れた人がRailsに出会うと、Railsでは同じ操作をずっと洗練された方法で実現できることに気付くでしょう。Active Recordを使うことで、SQLを直に実行する必要はほぼなくなります。 Active Recordは、ユーザーに代わってデータベースにクエリを発行します。発行されるクエリは多くのデータベースシステム（MySQL、MariaDB、PostgreSQL、SQLiteなど）と互換性があります。Active Recordを使えば、利用しているデータベースシステムの種類にかかわらず同じ記法を使えます。 本ガイドのコード例では以下のモデルを使います。 class Book < ApplicationRecord belongs_to :supplier belong
isucon予選中に、SQLを出力したくなったのだけど、ふとgithub.com/shogo82148/go-sql-proxyを使ってみようとしてとりあえず簡単に使う方法が書いてなくて少し使い方を調べるのに苦労したので、isuconで時間のロスなく使えるようにそのwrapperを書きました。 package main import ( database/sql "github.com/go-sql-driver/mysql" # load driver before load go-sql-tracer _ "github.com/walf443/go-sql-tracer" ) func main() { db, err := sql.Open('mysql:trace', dsn) } ポイントは、 元々使っていたドライバ名に":trace"とつけること go-sql-driver/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
