ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
「ナチュラルキー」と「サロゲートキー」の違い｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
似ているところ どちらもデータベースの主キーです。 違うところ キー自体が項目としての意味を持つかが違います。 ナチュラルキーは項目としての意味を持ちます。 元々あった項目を主キーとして使います。 サロゲートキーは項目としての意味を持ちません。 意味のない連番を主キー用に別途割り振ります。 例えば、以下のデータがあったとしましょう。 [出席番号、名前、性別、血液型] 1番、相川、男、Ｏ型 2番、合田、男、Ｂ型 3番、伊藤、男、Ａ型 4番、宇野、男、Ｏ型 ・ ・ ・ 1番、伊藤、女、Ａ型 2番、井上、女、Ｂ型 ・ ・ このデータは出席番号＋性別で一意に特定できます。 [出席番号、名前、性別、血液型] 1番、相川、男、Ｏ型 2番、合田、男、Ｂ型 3番、伊藤、男、Ａ型 4番、宇野、男、Ｏ型 ・ ・ ・ 1番、伊藤、女、Ａ型 2番、井上、女、Ｂ型 ・ ・ 「よし！じゃあ、出席番号＋性別を主キーって
ゲームを題材に学ぶ 内部構造から理解するMySQL 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
NoSQLとは？リレーショナルデータベース（RDB）との違いを徹底比較
更新日: 2017年3月14日公開日: 2016年7月25日NoSQLとは？リレーショナルデータベース（RDB）との違いを徹底比較 NoSQLという言葉をご存知でしょうか？ ビッグデータ、IoT、SNSなどの流行とともに、データベースの世界でもリレーショナルデータベース（RDB）に代わるこの概念が普及しつつあります。NoSQLは変化する時代に柔軟に対応するデータベースといえるかもしれません。 そうはいってもデータベースは難しい！…と感じるかもしれない皆さんに、RDBMSとNoSQLの違いをとても簡単に解説します。 NoSQLという言葉をご存知でしょうか？ビッグデータ、IoT、SNSなどの流行とともに、データベースの世界でもリレーショナルデータベース（RDB）に代わるこの概念が普及しつつあります。NoSQLは変化する時代に柔軟に対応するデータベースといえるかもしれません。 そうはいってもデー
【誰でも描けるＥＲＤ】-関連の多重度
今回のコラムは、前回コラム「エンティティと関連」で説明した関連に伴う多重度の説明になります。 今回説明する「多重度」とは、下の図に説明する「部署」と「従業員」の「所属する」と言う関連において、「一つの部署が何人の従業員と関連を持つか」、「一人の従業員がいくつの部署と関連を持つか」を表現するものです。 なお、「多重度」は、カーディナリティ(cardinality)と英語で呼ばれる場合もありますが意味は同じです。 先ず、部署側から考えて見ましょう。 総務部とか経理部とかシステム部とか、部署は色々ありますが、任意の一部署を想定すると、普通は何人かの従業員が所属しています。 その状態をビジネスルールで『一つの「部署」にはn人（ｎは１以上の任意の数を表します）の「従業員」が所属している』と表現し、ＥＲ図では以下のように描きます。 「あれ？、部署側の多重度を書き忘れている」と思った方居ませんか。 書き
若手プログラマー必読！５分で理解できるER図の書き方５ステップ
データベース設計の基本中の基本であるER図。ER図を書きたいけど、「記法が分からない」「どういうステップで書けば良いか分からない」という若手エンジニアも多いのではないでしょうか。 ER図は１０種類近くあり、種類によって記法が異なります。このことが難しいイメージを与えていますが、実はそれほど難しいものではありません。覚えれば良いER図は２種類だけです。 しかも、この記事で解説している基礎知識を押えれば、たった５つのステップで作成することができます。 この記事では、ER図の基礎知識からER図の書き方まで、エンジニアが抑えておくべきER図の全知識をどこよりも分かりやすく解説します。 この記事を読み終えたとき、若手エンジニアもER図を書けるようになっているでしょう。 この記事を参考に最適なデータベース設計を進めて下さい。 １．ER図とは ER図とは、「データベース設計（データモデリング）で使う設計
Spanner - Qiita
これまで多くのトランザクションの要素技術を説明してきた。 Googleの公開している論文Spanner: Google's Globally-Distributed Database は公開当初、要求される専門技術の多さからよくわからないと言っている人が多かったが、これまでに説明した要素技術をベースにすると理解しやすい。 Spannerとは 複数のデータセンターに跨ってデータベースの内容を複製し続ける事で高い可用性を実現するという構想は数多くあった。 しかしそれらの分散データベースは実用的な速度を実現しようとすると、データモデルがただのRDBより単純化して使いにくかったりトランザクションをサポートしなかったりと、アプリケーションの一貫性を実現するのが難しい。 現にGoogleの社内でもBigtableなどを用いたアプリケーションは複数あるものの、それぞれでそのデータモデルの上で無理やりトラ
コネクションプールとは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
最初から接続した状態を用意しておくよ 使いたい人には、接続した状態を貸し出すよ 接続にかかる負担を減らすための仕組みだよ 簡単に書くよ コネクションプール（英：connection pool）とは ゲストカード貸出型接続方式のこと。 もう少し具体的に書くと 接続した状態を最初からいくつか用意しておいて、何か用事がある人にはその接続を貸してあげることで、いちいち接続する手間を減らす機能のこと です。 サクッと一言で説明すると あらかじめ接続した状態を用意しておいて、それを貸し出すことで、使うときに接続する手間を減らす機能 が「コネクションプール」です。 ……と、いきなり言われても、分かりませんよね。 そもそも「接続した状態」ってなんだよ！と思う方もいるでしょう。 大丈夫です。 順番に見ていきましょう。 例えば、そうですね。 ここにピヨ太君が所有するピヨピヨビルがありました。 ピヨピヨビルはセ
Railsのデータロック - Qiita
begin ActiveRecord::Base.transaction do . . raise 'ロールバックします' end p 'コミット' # トランザクション処理を確定 rescue => e p 'ロールバック' # トランザクション処理を戻す end transactionブロックの中で登録・更新処理を行う場合は、saveやupdateではなく、save!, update!を使用する。 transactionブロックの中で複数のモデルの更新を行った後に例外を発生させると、全部のモデルがロールバックする。 楽観的ロック 「競合は多分起きないだろう」という前提で、データの取得時には何もせず、更新時に競合をチェックする方法。 レコードのバージョン管理を行うため、テーブルにlock_versionカラムを追加する。その際、デフォルト値を0にする。 lock_versionはレコード
排他制御（楽観ロック・悲観ロック）の基礎 - Qiita
排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用
えっ、まだPostgreSQLでダブルクォーテーション使ってるの？ - Qiita
するとこれ、エラーで返ってきました。 （エラーメッセージはうろ覚えですが「value1なんてカラムは存在しないよ」的なことを言ってました） PostgreSQLでは、ダブルクォーテーション「”」をシングルクォーテーション「'」にしないといけません。なので、以下のように変更します。 「”」と「’」の違い PostgreSQLなどの標準SQLでは、 シングルクォーテーションで囲う：文字列定数として扱う ダブルクォーテーションで囲う：カラム名として扱う という仕様になっている。 'value1'はvalue1という文字列として捉え、"value1"はvalue1というカラムの名前として捉えられます。 テーブルになにか文字列を挿入するときはシングルクォーテーションで囲ってやらないと、SQLが文字列として認識してくれないわけです。 つまり、文字列定数をダブルクォーテーションで囲うな！ということです。
新人にPostgreSQLのシーケンスを理解してもらう - Qiita
1. はじめに 新人向けの研修でPostgreSQLのシーケンスについて説明した内容です。シーケンスを使ったことがない人には役立つかと思います。新人向けに他にも記事を書いていますので興味のある方は参照ください。 新人に悲観ロックによる排他制御を体験してもら PostgreSQLでは以上、以下（=>、=<）が使えない！？ 2. シーケンスとは？ シーケンスとは連番となる一意な整数を生成するデータベースのオブジェクトです。 ちなみに、テーブル、ビュー、インデックス等もデータベースのオブジェクトです。 一般的にシーケンスは、ユーザIDや登録番号等の主キーを生成する際によく利用されます。 シーケンスはトランザクションのコミットやロールバックに関係なく、採番（取得）した時点でインクリメントされます。 3. シーケンスの作り方 シーケンスはCREATE SEQUENCE文で作成します。 ここでは1から
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
データベース用語和英対応表 - Weblog on mebius.tokaichiba.jp
6～7年前に買ったSQLの入門書を、捨てる前に読み返している。この入門書を使って1回SQLを勉強したのだが、実際に使うことが無かったため、全く身に付かず、歳のせいで記憶にも残っていないのだ。実際、MySQLを触りながら復習しようとして、mysqlを起動すると、"select * from （テーブル名）;"以外の文はそらでは全く書けなかった。 従って、SQLの入門書とMySQLのマニュアル(MySQL info)とを見ながらSQLを試しているのだが、SQLの入門書が日本語でMySQLのマニュアルが英語であり、筆者にデータベースの基礎知識がないため、日本語と英語の対応が取れない用語がいくつか発生した。 そこで、出くわしたデータベース用語の日本語と英語の対応表を作ることにした。 日本語英語
ボイスコッド正規化 - Qiita
※補足アンダーライン( _ )に囲まれているのが主キー 各農産物の地方ごとの最多生産権の情報を持っている。この時関数従属性は {農産物,地区} → 最多生産県 {農産物,地区} → 生産高 最多生産県 → 地区 である。 推移従属、部分従属が無いため、第3正規型である。 ボイスコッド正規型であるためには、そのテーブルが第3正規型であることが必要条件である。 ともあれこれで準備は整った。 ボイスコッド正規型の定義 ある関係上に存在する自明でない全ての関数従属性の決定項が候補キーであるとき by Wikipedia つまりテーブル上に存在する関数従属すべてに関して 関数従属が自明であること 決定項が候補キー※となること の2点のどちらかを満たす時、そのテーブルはボイスコッド正規型であるといえる。 ※本によっては候補キーではなくスーパーキーとしているものもある 用語をおさらいしておこう 用語 候
PostgreSQLのExplain analyzeを読みやすくする方法 | なおべりーのブログ
PostgreSQLのExplainを使う機会があったので、メモだけ残しておきます。 explain analyzeの結果を見るのはなかなか大変です。costとactual timeの差をみることで重い処理を把握する必要がありますが結構大変でした。そこで、結果をタブ区切りに置換してExcelで確認する方法を紹介します。 Explainとは SQLの実行計画を確認することができます。 実行計画とは、検索するときのデータの絞り込み方法のことです。先頭から全件検索をするのか、インデックスを使うのかなどを決めていきます。 Explainの実行方法は次の通りです。 explain 確認したいSQL Explainの種類 Explainには2通りの種類があります。 explain explain analyze explainは実行計画のみを見ることができます。 explain analyzeは実行計
Rails: 闇雲にインデックスを付けてはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Don't index the kitchen sink! 原文公開日: 2015/07/09 著者: Jeroen Weeink サイト: Crafting Ruby 最近、使われてないインデックスを外す作業を行ってたのですが、やってみると出るわ出るわ。そのほとんどは、逆関連付けの不要なモデルのJOINの一部でした。次の例で考えてみましょう。 class ShoppingCart < ActiveRecord::Base has_many :shopping_cart_products has_many :products, through: :shopping_cart_products end class ShoppingCartProduct < ActiveRecord::Base belongs_to :shoppin
Railsエンジニアなら知っておきたい！RDBでindex作成を検討するときってどんなとき？ - Qiita
はじめに 前回に引き続き、またまたDBネタです(^o^) 前回：Railsエンジニアなら最低限これだけは知っておきたいSQLのJOINの動き 今回は、インデックスについてです。インデックスにはいくつか種類がありますが、 RDBで一般的に使われるB-treeインデックスについて書いていきます。 いきなりですが、インデックスは深い！かなり深い！バイカル湖くらい深いです。 ある程度の指針的なものはありますが、インデックスをどう設計するかの見極めは状況によって変わってくるようです。クエリの実行頻度、テーブルサイズ、カーディナリティ（カラム内のデータの種類の多さ）などなど。。 なので今回は、こんなときはインデックス作成を検討した方がいいというパターンだけザッとまとめる感じで行きたいと思います。 なお、今回の記事作成にあたっては、以下の本を参考にさせて頂きました。 そもそも的なところから分かりやすく書
Aurora Serverlessが一般利用可能になったので試してみた | DevelopersIO
AWS re:Invent 2017で発表のあったAurora Serverlessがいよいよ一般利用可能になりました。早速Aurora Serverlessに触って確認してみます。 大栗です。 AWS re:Invent 2017で発表されていたAmazon Aurora Serverlessが一般利用可能になったので、早速試してみました。 Aurora Serverless MySQL Generally Available Aurora Serverless 概要 AWS re:Invent 2017で発表されていたAuroraの新しい形態の動作モードです。 【速報】新しいDBサービスAurora Serverlessが発表されました！ #reinvent AuroraはSQL処理を行うDBインスタンス部分と高可用性な分散ストレージ部分が分離している構成をとっています。Aurora
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
シーケンス操作関数