SQLパフォーマンス詳解: 開発者のためのデータベースチューニング解説書
前書き インデックスの 内部構造 インデックス リーフノード 検索 ツリー(Bツリー) 遅いインデックス パートI where 句 等価 演算子 プライマリキー 複合インデックス 遅いインデックス パートII 関数 - where 大文字・小文字を区別する 検索 ユーザ定義 関数 インデックスの作り過ぎ パラメータ化 クエリ 範囲 検索 大なり、小なり、 BETWEEN LIKEフィルタに 対するインデックス インデックスの結合 部分インデックス OracleにおけるNULL NULLに対する インデックス NOT NULL 制約 部分インデックスを エミュレートする 処理しにくい条件 日付型 数値文字列 列の連結 スマートなロジック 数式 パフォーマンスと スケーラビリティ データ 量 システム 負荷 レスポンス タイムとスループット 結合 処理 入れ子 ループ ハッシュ 結合 ソートマ
モバイルゲームインフラあるある物語 ～システム障害と技術的対策の例～
近年、ハイスペックなスマートフォン、高品質なネットワークが普及し、それによりモバイルゲームの制作手法やそれを取り巻く環境も変化してきました。スクウェア・エニックスでは、そのような環境の変化に対して、日々新たなチャレンジをし続けています。そして、このようなスピード感溢れる業界の流れには、会社の枠を超えた技術情報の共有、交流が欠かせないと感じております。 そこでこの夏、社内のエンジニア・テクニカルディレクターによる最新のモバイル開発の技術情報や社内モバイルエンジン、開発秘話によるセッションをメインに、スクウェア・エニックス モバイル オープンカンファレンスを開催する運びとなりました。また、セッションの後は登壇する弊社スタッフと直接ディスカッションやフリートークができる場を設けております。この機会にスクウェア・エニックスという会社についても、より詳しく知って頂ければ幸いです。 マネージャー・テク
LevelDB入門 (基本編) - from scratch
さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDB は Google のBigTableをベースにしたアーキテクチャを持
Mackerelを支える時系列データベース技術 - ゆううきブログ
【追記 2018/01/06】現在Mackerelは、時系列データベースという概念をクラウドの技で再構築する - ゆううきブログの時系列データベース実装へ移行しています。 サーバモニタリングサービス Mackerel で採用している時系列データベース Graphite を用いたシステムの構築と運用事情を紹介します。Graphiteについては、プロビジョニングやアプリケーションからの使い方、Graphite自体のモニタリングなど様々なトピックがありますが、特に大規模ならではのトピックとして、Graphiteの内部アーキテクチャ、パフォーマンスチューニングおよびクラスタ構成についての知見を書きます。 背景 Graphiteシステム概観 データ構造とアーキテクチャ whisperのデータ構造 carbon-cacheのアーキテクチャ パフォーマンス特性 パフォーマンスチューニング ミドルウェアレ
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
MySQL Index勉強会外部公開用
12. © CROOZ,Inc. 12 １．INDEXとはなにか 何枚目がなにかを事前にメモっておけば良い！ スート ランク 位置 ハート Q 1 スペード 9 2 : : : ダイヤ 1 40 : : : スペード 6 45 なぜなら、要求は「カードを引く回数を最も少なく してスペード6を探すこと」 セコいとかおもうヒトはいるか もしれませんが何もセコいこ はしていないです。 前提条件など一切ないから このメモさえあれば位置を指定して1回引けば済む
MySQLでインデックスを使って高速化するならCovering Indexが使えそう - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者：松信 嘉範 販売元：翔泳社 発売日：2009-09-17 おすすめ度： クチコミを見る 最近、この本を読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス
Adminer - Database management in a single PHP file
Adminer (formerly phpMinAdmin) is a full-featured database management tool written in PHP. Conversely to phpMyAdmin, it consist of a single file ready to deploy to the target server. Adminer is available for MySQL, MariaDB, PostgreSQL, SQLite, MS SQL, Oracle, Elasticsearch, MongoDB and others via plugin. Features, Requirements, Skins, References Why is Adminer better than phpMyAdmin? Replace phpMy
- データベースの進化的設計
データベースの進化的設計 Martin Fowler Pramod Sadalage 原文(Evolutionaly Database Design) ここ何年かで私たちはアプリケーションの開発に即してデータベースの設計を進化させることを可能にする技法を編み出した。このことはアジャイルメソッドにとって非常に重要である。この技法は継続的インテグレーション及び自動化されたリファクタリングをデータベースの開発に適用し、かつDBAとアプリケーション開発者が密接に協力することによって成り立つ。この技法は開発中のシステムや既に開発されたシステムに対しても機能する。 変化に対応する 制限事項 プラクティス集 DBAは開発者と密接に協力し合う 全員が自分のデータベースインスタンスを保有する 開発者は共有マスターに頻繁に結合する スキーマとテストデータから成るデータベース すべての変更でデータベースのリファ
分散システムの一貫性に関する動向について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog システム統括本部アーキテクト室 今野です。 昨年は、Twitter,Facebookを始めとするクラウド各社で新規の分散システム開発のプロジェクトが相次いで発表された年でした。これらの新しい分散システムを開発する理由や、その背景にあるものは何なのでしょうか？ 今回は、昨年末に開催された高信頼性分散システム系の国際学会であるSRDS 2014[1]の発表内容に関連する論文の話題も踏まえて、昨今のクラウド各社の分散システムの動向について整理してみます。 分散システムにおけるクラウド各社の動向 近年の分散データベースの世界では、AmazonのDynamo[2]やFacebookのCassandra[3]などを代表とする結果整合性（Eve
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
SQLのUPDATE文と履歴系テーブル - mike-neckのブログ
大したことは書いてありません。 気付いたことのメモ程度です。 『理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 』を少し本屋で立ち読みしました。(ノットワーキングプアにあえいでいるので立ち読みしかできない(´・ω・｀)) この本の中で履歴系テーブルの扱い方というのに丸々一章が割り当てられていました。 だいたいこんなことが書かれてたと思う。 「時間軸と直交していない」という点は、履歴テーブルは過去の事実の集合で、データを取得する条件が変われば結果が異なるのは当たり前だと思うんだけども。— enum (@enum) 2015, 3月 16 たしかに、RDBMSでは履歴データというのは相性が悪い。 僕は陸上競技を見るのが好きなので、これのデータモデルをたまに考えたりしています。で、選手の氏名が変わることあるよなーと考えると、こ
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
法務省 戸籍統一文字情報 トップ
ここでは，戸籍のオンライン手続に使用することを目的として整理した文字の情報を検索することができます。 また，子の名に使用することができる文字（人名用漢字等）についても検索することができます。
主キーのナチュラル⇔サロゲート問題 - b6note
についてひとこといっておくか、みたいな。 複合主キーを避けるべき理由 http://d.hatena.ne.jp/torazuka/20110713/pk 今回これを書きながら、色々考える機会になりました。 ありがとうございました＞id:torazuka さん 自分のぶこめ http://b.hatena.ne.jp/akitsukada/20110715#bookmark-50842882 複合主キー、ここでいう「ナチュラルキー」は論理設計とか分析モデルのときにデータの意味をはっきりさせるために抽出し、物理設計/実装段階で物理的制約や要件に応じてサロゲートキーをつければいいと思うと書いたんだけど、何しろ100文字ではちょっと足りないので もうちょっと自分の考えを補足 わたしの考え まず自分の立場は、上記のブコメを展開して データモデリング、分析、論理設計の段階ではID（サロゲートキー）を
ナチュラルキーを主キーにしてはいけない - 設計者の発言
定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー（一次識別子）に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、．．． いっぽうユーザの目に触れる項目は、「二次識別子」とされて
SQL Fiddle - Online SQL Compiler for learning & practice
During Phase 1, only users who are logged in can access the AI chat feature. SQL Fiddle is free to use and ad-free! Want to help us? It takes 10 seconds Step 1: Like & Share our EFE Bulk Extensions videos Step 2: Like & Share our EFE Bulk Insert videos Thank During Phase 1, only users who are logged in can access the AI Editor feature. SQL Fiddle is free to use and ad-free! Want to help us? It tak
SQLのlike演算子でエスケープが必要な文字 - teracc’s blog
まとめると以下のようになると思います。 Oracle % _ ％(全角）＿(全角) DB2 % _ ％(全角）＿(全角) MS SQL Server % _ [ MySQL % _ PostgreSQL % _ 注意点は以下のとおり。 DB2、Oracleは、「％」「＿」（全角）もワイルドカードとして解釈する SQL Serverは、[a-z]のような正規表現的な記述を解釈する 当然、ワイルドカード的な機能を持たせたい「%」や「_」等はエスケープしない 全データベース共通の話として、エスケープ文字自体もエスケープする必要がある（MySQL、Postgresでは「\」がデフォルトのエスケープ文字） likeのエスケープをした後に、Prepared Statementで値をSQLにバインドする （関連）2008-07-10 - T.Teradaの日記
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
