PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った - そーだいなるらくがき帳中国地方DB勉強会 in 岡山の登壇資料です。 そのうちここで登壇動画が公開されることでしょう。 肝心なチートシートは以下のとおり。 PostgreSQL gist.github.com MySQL gist.github.com チートシートだけじゃわからない！困ってる！ Have Fun Techがバージョンアップのサポートしますのでお気軽にご相談ください。 have-fun.tech まとめ やっぱ中国地方DB勉強会は最高だぜ！
Percona Toolkit を読む - id:onk のはてなブログ
このエントリは はてなエンジニア Advent Calendar 2019 の 18 日目のエントリです。 qiita.com 前日は id:ikesyo さんによる 2019年のSwiftモック事情 でした。 ikesyo.hatenablog.com SQL を分析したい 今日の話。DB 負荷を継続的に計測していきたいのです。 そんなときに Percona Toolkit って良いライブラリがあるので、これを使っていきましょう。 SQL を分析するときは以下のようなことを考えます。 本番環境でログを採取 normalize グルーピング EXPLAIN マズいクエリを見つけたらアラート発報 それぞれ見ていきましょう。 ログの採取 色々眺めたいので一旦 tcpdump を使います。 流れるクエリだけじゃなくて response も全部採取しているので、秒で GB 単位のデータが溜まってい
How SQLite Scales Read Concurrency
How SQLite Scales Read Concurrency Author Name Ben Johnson @benbjohnson @benbjohnson Image by Annie Ruygt Fly.io runs apps close to users around the world, by taking containers and upgrading them to full-fledged virtual machines running on our own hardware around the world. Sometimes those containers run SQLite and we make that easy too. Give us a whirl and get up and running quickly. If you scour
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） こんにちは、インフラ担当新人の nob です。 サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか？その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。 これだけ見れば大丈夫！ クエリ編 ３つのつぼと５つのグラフ （その１）監視ツールが何を見ているのか知る （その２）監視のキモ、グラフ３点セット (Questions, Lock Waits と Transaction Handler) （その３）グラフでチェックする SQL チューニング ( Select Type と Handler) シンプルでお勧め、サーバー監視グラフ化ツール
InnoDBロック競合の確認(MySQL 5.1+InnoDB Plugin, 5.5以降) | キムラデービーブログ
オープンソースデータベースを加速する「キムラデービー」のブログです。カレー日記を兼ねてます。なお著者は2010-06-01より日本オラクルに在籍していますが、本サイト（ブログ、またはウェブサイト）において示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。 MySQL 5.1+InnoDB Plugin, 5.5以降でサポートされた以下の三つの情報スキーマテーブルを使うとトランザクションとロックに関わる情報をInnoDBロックモニタよりも簡単でわかりやすく取得することが可能です。 | INNODB_LOCK_WAITS |独自: ロック待ち情報 | INNODB_LOCKS |独自: ロック競合情報 | INNODB_TRX |独自: トランザクション情報 通常一つの接続ではトランザクションのBEGIN; COMMIT;を何度か行います。つまり一つ
MongoDB の BSON - Backnumbers: Steps to Phantasien
ペーパードライバーにはヒマなエリアへ出張中. 各種中毒メディア群も数周して飽きたため, 前から読みたかった MongoDB でも調べよう...としたけれど, 思ったよりコードサイズがあるなあ. ちょっとだけ眺めて気を済まそう... ウェブっ子でない同士諸兄に説明しておくと, MongoDB は JSON のようなオブジェクトに 適当な ID を割り振り, その ID をキーに JSON (のようなもの)を検索できるようにした データベースのこと. ID 以外の JSON のフィールドにもインデクスをつけて 検索できるぶん便利な子だとされている. (教科書情報.) 今日は手始めに MongoDB 内の JSON 表現たる "BSON" を眺めた. MongoDB は, 自身が内部で使っている JSON 相当のデータ表現を BSON (Binary JSON) と呼び, あわよくば広く使っても
クラッシュリカバリとInnoDBログ – OpenGroove
InnoDBの重要な機能であるクラッシュリカバリと、それに深い関係があるInnoDBログについて。この辺の仕様がなかなか脳内に定着しないので、書いておく。 InnoDBログは、ロールフォワードリカバリには使用されない。では、InnoDBログの存在意義とは。ひと言でいうと、クラッシュリカバリである。クラッシュリカバリは、電源断など突然の障害が発生した際に、障害直前にコミットされた時点まで回復させる処理をする。MySQLはインスタンス起動時に、InnoDBデータファイルとInnoDBログファイル間に不整合があるかどうかを検出し、不整合があった場合にクラッシュリカバリを自動で行う。（MyISAMテーブルにはこの機能がない）MySQLではロールフォワードリカバリはバイナリログ、クラッシュリカバリではInnoDBログという役割分担がなされているわけだ。このため、もしバイナリログを消失するアクシデント
Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase comparison :: Software architect Kristof Kovacs
Hello, I’m Kristof, a human being like you, and an easy to work with, friendly guy. I've been a programmer, a consultant, CIO in startups, head of software development in government, and built two software companies. Some days I’m coding Golang in the guts of a system and other days I'm wearing a suit to help clients with their DevOps practices. While SQL databases are insanely useful tools, their
実践Teng — Teng-Doc 0.01 documentation
Navigation index next | Teng-Doc 0.01 documentation » 実践Teng¶ Contents: この文書について この文書は何ではないか? この文書で説明すること 表記について Tengの特徴 Tengとは クイックスタート はじめに 環境の準備 DBの作成 テーブルの作成 データの挿入 クエリの確認 データの検索 データの削除 データの変更 まとめ やってみよう 逆引きレシピ 逆引きレシピについて 一般編 Rowオブジェクト編 SQL編 Indices and tables¶ Index Module Index Search Page Table Of Contents 実践Teng Indices and tables Next topic この文書について This Page Show Source Quick search Ente
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
第一の大罪（1） ～ データベースアプリケーションのパフォーマンスにおける七つの大罪
第一の大罪は''データベースの物理設計''に関するもので、たとえばスキーマ設計の問題、テーブルの列の順序、インデックス付け、データベースページサイズの選択など、パフォーマンスに悪影響を及ぼしかねない重要な要因はいくつも考えられます。今回の記事では、SQL Anywhereのデータベース設計にまつわる具体的な問題と、ドメイン（定義域）の概念に関する内容を取り上げていきます。 ドメイン（定義域）とは ドメインの概念は、E. F. Coddが発案した最初のリレーショナルデータモデルに含まれています。Chris Dateは、彼の重要な著書 [1, pp. 81] の中でドメインを次のように定義しています。 次に、ドメインという言葉を、すべて同じ型の、スカラー値の名前付きの集合と定めることにする。たとえば、サプライヤー番号のドメインは、サプライヤー番号として取り得るすべての番号の集合になり、出荷数量
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門 広く浅くを担当してます、ota です。 技術ブログ第一回から早速流用スライドで申し訳ありませんが、社内勉強会資料として作成した「MySQL INDEX + EXPLAIN入門」です。 当社でもソーシャルゲームの開発を行っていますが、このような大量のデータを使用する・クエリの速度が求められる場合にインデックスは大変重要です。 インデックスの有効な利用にはDB設計者だけではなくプログラマにもある程度の知識が最低限必要となりますが、インデックスについての初心者向け資料があまりないようです。 このスライドではプログラマに知っておいて欲しい以下の基本的な点をまとめました。 INDEXを使用する時に気をつけること WHERE句 !=、<>はインデックスが使用できない WHERE句の全てのANDにかかっていないイン
NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
スワップサイズをゼロにしてはいけない
先月発売された書籍「Linux-DBシステム構築/運用入門」は、なかなか上々の売れ行きとなっているようです。Amazonではしばらく「1-2ヶ月待ち」の状態が続いてしまっていたのですが、最近になってようやく解消され、容易に入手できるようになっているようです。Amazonの在庫切れ問題がひと段落したところで、これからは書籍のサポート的な情報を書いていくことにします。 まず、本書を購入された皆さまありがとうございました。結構な数の方がBlogやTwitter等で、この本をほめてくださっていることに大変感謝しています。まだ本自体の認知度が低い(存在自体を知らない顧客も多い)ので、普及活動をしつつ、これからも読者の期待に応えられる記事を書いていきたいと思っています。 最初は、よく見かけることの多い「メモリ管理」の話題を取り上げようと思います。第12章では、メモリ管理とスワップ領域に関する解説をして
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Free Credit Report music videos Migraine Pain Relief Best Mortgage Rates Credit Card Application Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLの観点から「Oracle Database」「PostgreSQL」 「MySQL」の特徴を整理しよう！
ソーシャルゲームのためのデータベース設計
