データベースのドキュメント管理を自動化した話 - estie inside blog
こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie（オフィス探しサービス）とestie pro（不動産事業者向けデータプラットフォーム）の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
MySQL入門 バックアップ編 - Qiita
#経緯 とある勉強会の内容の復習＆整理 #タイトル インストール・アーキテクチャ基礎編 レプリケーション編 バックアップ編 ←今回はこちら チューニング基礎編 #バックアップ編アジェンダ バックアップ手法の概要 バックアップ運用設計時の主な考慮事項 バックアップ対象のファイル バックアップリストア例 #1. バックアップ手法の概要 ##1.1. バックアップ手法の違い ホットバックアップ or コールドバックアップ 物理バックアップ or 論理バックアップ フルバックアップ or 差分/増分バックアップ スタンバイサイトを利用 － ホットスワップとしての利用 － バックアップ取得先としての利用 ##1.2. ホットバックアップ or コールドバックアップ ###1.2.1. ホットバックアップ（オンラインバックアップ）の例 トランザクションの仕組みを利用してバックアップをする mysqld
MySQLを１〜２時間でスケールアウトする - クックパッド開発者ブログ
最近、Elastic BeanstalkやECSと戦っているSREチームの菅原です。 P5をやりたいのにPS3もPS4も持っていないので指をくわえて羨ましがっている毎日です。 この記事では、突然のアクセス増に備えるために、MySQLのスレーブを１〜２時間でスケールアウトできるようにした話を書きます。 MySQL on EC2 クックパッドは周知の通りAWSを利用していますが、主要なデーターベースについてはAmazon RDSではなくMySQL on EC2を使っています。 これは以下のような理由によるものです。 歴史的な経緯: AWS移行当時、RDSが無かった。また、移行後もしばらくはTritonnを使っていたため、RDSを使うことができなかった オンラインメンテナンスの実現: VPCルートテーブルを使った仮想IPとMHA for MySQLを使ってダウンタイムゼロのマスタDBの切り替えを
このRDBについて私は驚くべき闇を見つけたがそこを発表するにはネットは怖すぎる
YAP(achimon)C::Asia Hachioji 2016midの資料です。
MySQLのメモリー使用量を最適化する設定のベストプラクティス | Yakst
Percona Data Performance Blogの翻訳。Percona CEOのPeter Zaitevによる、MySQLのメモリー使用量をどのように決めるべきか、またそれを決める時に気にするべきことは何かについてのまとめ。 この記事では、最適なMySQLのメモリー使用量を設定するためのベストプラクティスを扱おうと思います。 使用できるメモリーのリソースをどのように使うか正しく設定するのは、MySQLを最適なパフォーマンスでかつ安定して使うために最も重要なことのひとつです。MySQL 5.7では、デフォルトの設定では非常に少ない量のメモリしか使いません。デフォルトのままにしておくのは、最も良くないことのひとつでしょう。しかし、不適切に設定してしまうと、パフォーマンスを更に悪くする(あるいはクラッシュする)ことにもなりかねません。 MySQLのメモリ使用量を設定するにあたっての最初
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
CentOS6.5にmysql5.6をインストールする手順 - Qiita
環境 OS : CentOS release 6.5 (64bit) 既にmysqlの何かあるか確認する $ sudo yum list installed | grep mysql あった場合、けす $ sudo yum erase mysql-libs rpm 入手 http://downloads.mysql.com/archives/community/ から $ wget http://downloads.mysql.com/archives/get/file/MySQL-client-5.6.20-1.linux_glibc2.5.x86_64.rpm $ wget http://downloads.mysql.com/archives/get/file/MySQL-server-5.6.20-1.linux_glibc2.5.x86_64.rpm $ wget http://
MySQL Clusterにおけるレプリケーション環境構築例
本連載では、実際に「MySQL Cluster」を利用するためのチュートリアルとなるように、その特徴と基本的なアーキテクチャからインストール方法、基本的な操作などをコマンド付きで解説していきます。第8回の今回は、MySQL Clusterにおけるレプリケーション環境構築の具体例について解説します。 前提となる環境 記事中のコマンド例は、第2回でインストールした環境に第5回で紹介したサンプルデータベース（worldデータベース）を作成した状態を前提としています（追加設定としてmysqlユーザーの環境変数"PATH"に"/home/mysql/mysqlc/bin"も追加した状態を前提）。 レプリケーション環境構築の流れ レプリケーション環境の構築は、以下の手順で行います。大まかな流れは通常のMySQL Serverでレプリケーション環境を構築する手順と同様ですが、手順6、7はMySQL Cl
BLOB型とTEXT型
BLOB型とTEXT型について BLOG 型及び TEXT 型はそれぞれ巨大なバイナリデータとテキストデータを格納する時に利用されます。 BLOB 型はバイナリデータを扱うデータ型で格納できるデータのサイズを指定しません。画像ファイルなどを格納する場合などにも使われます。ただ最大長は決まっており、最大長の種類によって次の 4 つが用意されています。 TINYBLOB 最大長が 255 (28 ? 1) バイト。 BLOB[(M)] 最大長が 65,535 (216 ? 1) バイト。 オプションの長さ M を指定できる。 MEDIUMBLOB 最大長が 16,777,215 (224 ? 1) バイト。 LONGBLOB 最大長が 4,294,967,295 または 4G バイト (232 ? 1) バイト。 BLOB 型は VARBINARY 型で格納できるバイト数を指定しなかったものと
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
嵐のコンサートがあるとダブルブッキングしてしまうホテル予約システムを作ってみた
今年の5月1日に、仙台市内のホテルで多重予約のトラブルが発生したと報道されています。 部屋数２０３室の仙台市のビジネスホテルで、９月１８～２３日の宿泊予約を数千件受け付けるトラブルがあった。アイドルグループ「嵐」のライブが宮城県内で開催される期間だった。インターネットでの申し込みが殺到し、システム障害が起きたとみられるという。 トラブルがあったのは、仙台市泉区の「ホテルルートイン仙台泉インター」。ホテルなどによると、９月１９、２０、２２、２３日に宮城スタジアム（宮城県利府町）で嵐がライブを開くことが明らかになった後の５月１日午前５時ごろ、ネットを使った予約申し込みが殺到していることに気づいたという。 ２０３室のホテルなのに「予約」数千件 嵐公演で殺到か：朝日新聞デジタル より引用 5月1日の朝に何があったのか調べてみると、この日の早朝にテレビや新聞でコンサートの情報が流れたようですね。 お
MySQL の lower_case_table_names について，テーブル名とデータベース名の中の大文字小文字について - その手の平は尻もつかめるさ
MySQL には lower_case_table_names という変数があって，これはテーブル名の大文字小文字を区別するかどうかというのを設定するパラメータなわけですが，その詳細は以下のようになっています (参照: MySQL :: MySQL 5.6 Reference Manual :: 9.2.2 Identifier Case Sensitivity)． Value 説明 0 大文字・小文字を区別してデータベース名やテーブル名をストアする．これらの名前の比較についても大文字・小文字を区別する．MySQL のサーバが動作する OS のファイルシステムが大文字と小文字を区別しない場合 (例えば OS X や Windows)，この値に設定すべきではない．そうしたファイルシステム上でこの値を0にして，なおかつ MyISAM のテーブル名に対して大文字小文字を混ぜてアクセスするとインデ
MySQLのmy.cnfファイルサンプル
MySQLのバージョン インストールされたMySQLのバージョンは以下のようになります。 名前 バージョン ダウンロード元 my.cnfサンプル 以下のサンプルを参照して、my.cnfファイルを作成してください。 # このファイルは MySQL 5.6を基準として作られてあります。 # http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html を参照しました。 [mysqld] ##-------------------------------------------------------------------- # mysqldの基本設定 ##-------------------------------------------------------------------- # id は 1 から 2^
MYSQL で IF（CASE)文が便利 ← Neo Inspiration
これはめちゃくちゃ便利なので、メモメモ。 例えば tableA に 性別カラム (clmA) (1=男,2=女,3=その他)があって 男のレコードの数 女のレコードの数 その他のレコードの数 を1発のSQLで出すことができます。 SELECT count( CASE WHEN clmA=1 THEN 1 ELSE null END ) as “Men” count( CASE WHEN clmA=2 THEN 1 ELSE null END ) as “Women” count( CASE WHEN clmA=3 THEN 1 ELSE null END ) as “Others” FROM tableA ほかにも CASE WHEN 1>0 THEN “true” ELSE “false” みたいな書き方も可能だし、 もちろんネストも可能。 しかも意外と処理も早いので、 わりとヘビーなD
MySQL で INSERT と UPDATE を1文で実現する ～ ON DUPLICATE KEY UPDATE 編～ | UB Lab.
データベースにデータを登録する際に、INSERT と UPDATE か判断して実行しなければならないことがある。たとえば、カテゴリーの追加と更新を行うページで、ID が付与されている場合は ID をキーにして UPDATE、されていなければ INSERT を行うようなケースだ。前回は REPLACE 構文を使う方法を説明したが、REPLACE 構文は INSERT と DELETE を組み合わせて実行するため不便な点も多い。今回は、INSERT 構文で ON DUPLICATE KEY UPDATE を利用する方法を紹介する。 使い方 INSERT 構文で ON DUPLICATE KEY UPDATE を使う場合、INSERT 文と UPDATE 文を組み合わせたような SQL になる。 INSERT INTO table ( id, category_name, update_coun
クックパッドの検索の裏側 - クックパッド開発者ブログ
初めまして、インフラストラクチャー部の加藤 (@EugeneK) です。 クックパッドでは現在178万ものレシピが公開されていますが、目的のレシピを探すために検索機能を提供しています。 今回は検索機能の裏側の仕組みについて、インフラストラクチャーの観点からお話ししようと思います。 全ての検索機能を支えるSolrと周辺のアーキテクチャ クックパッドにはレシピの検索だけでなく様々な検索機能がありますが、その全てはSolrを活用して実装されています。 以前はMySQL Tritonnによる全文検索機能を使用していましたが、2011年頃からSolrに切り替わりました。 クックパッドではSolrをマスタ - スレーブ構成にすることで冗長性と負荷分散を実現しています。以下の構成図をご覧ください。 マスタとスレーブの間には、リピータと呼ばれる検索インデックスを中継するためだけの役割のサーバがいます。この
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLアンチパターン
MySQLテーブル設計入門
MySQLのバックアップ運用について色々
