タグ

2015年10月1日のブックマーク (4件)

  • MySQLのINSERT/UPDATE時におこる不整合対策 - LukeSilvia’s diary

    先日、作っているアプリケーションにバグが発生しました。バグの内容は次のようなものでした。 同時に存在してはいけないはずのデータが、DB に存在する 整合性のチェックはアプリケーションレベルで行っている 一意制約のような単純なものではないので、アプリケーションレベルで実装 整合性のチェックロジックは正しい これに対し、バグは次のような状況で発生したと仮説を立てました。 ユーザがレコードを一括登録しようとする 登録ボタンを押したがレスポンスが遅い この間、整合性チェックが走っている ユーザはもう一度登録ボタンを押した 2回目の登録の整合性チェックが走り始める 1回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックの間、DBにはまだ1回目の登録によるINSERTが実行されていないので、チェックを通過した 結

    MySQLのINSERT/UPDATE時におこる不整合対策 - LukeSilvia’s diary
  • ISUCON2015で仕込んでいたネタ(h2o + mruby)の供養をする記事 - rail44 (アメミヤ)

    ISUCON2015予選お疲れさまでした。 予選関連エントリとしてはかなり出遅れてしまいましたが、自分がISUCONに向けて仕込んでいたものの、日の目を見なかったネタの供養をしたいと思います。 燃えろよ燃えろ。 (自宅でBeagleBoneBlackつかって動かしてたブログが消滅してたのでこっちで書くジャバよ。) 参加チーム アルパカ三姉妹 です。パカー。 ISUCONへの参加が初めてなのは自分だけだったので、足を引っぱるまいと気負いが凄かったと反省。 仕込んでいたもの 以前からmatsumoto-rさんのブログエントリ(その1, その2)によって、試したい気分が高まっていたh2oのmruby拡張をネタに一発逆転を目論み、sinatraアプリの一部ルーティングをmrubyで書けるような何かを作ろうとしました。 結果、 github.com github.com の2つのmrbgemsと、こ

    ISUCON2015で仕込んでいたネタ(h2o + mruby)の供養をする記事 - rail44 (アメミヤ)
  • MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録

    トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス

    MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
  • カーディナリティについてまとめてみた - Qiita

    カーディナリティとは テーブルにカラムがあるとして、カラムに格納されているデータの種類がどのくらいあるのか(カラムの値の種類の絶対値)を、カーディナリティという。 具体例 カーディナリティが低い場合 例えば性別なら、男と女の二種類である。 カラムのデータの種類が、テーブルのレコード数に比べて二種類と少ない。このことを カーディナリティが低い という。 カーディナリティが高い場合 一方顧客番号ならたくさんの種類(番号)が存在することになる。 カラムのデータの種類が、テーブルのレコード数に比べて多い場合、 カーディナリティが高い という。 カーディナリティを踏まえたインデックスの張り方 基的に、 カーディナリティの高い列に作成する 必要がある。 はじめに、カーディナリティは カラムの値の種類の絶対値と書いたが、先程の例で言うと性別のカーディナリティは2になる。他にも例えば1年間の日付なら1〜

    カーディナリティについてまとめてみた - Qiita