2017/10/08 phpcon 2017 https://joind.in/event/japan-php-conference-2017/session05-mysqlRead less
![片手間MySQLチューニング戦略](https://cdn-ak-scissors.b.st-hatena.com/image/square/538d6b3d421ff7a6f2bde1a53b583ca9bcf751fd/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fsparsetimemysqltuning-171008065714-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
はじめに これは ドリコムAdventCalendar の1日目です はじめに 1日目:ドリコムを支える中間ポイントシステム 一応自己紹介 プリキュアおじさん 嫁はキュアピース 開発の背景 ソーシャルゲームの歴史 中間ポイントについて 前受金と資金決済法について 有償ポイントと無償ポイント 複雑な売上計算 ドリコムの中間ポイントシステム(dpoint)について 自分の役割 重要なこと dpointが導入されているアプリ 課金フロー iTunesでの中間ポイント購入 GooglePlayでの中間ポイント購入 ポイント消費 dpointのリリースノート gemのボリューム date_discreterというgemを作りました どういうgem? 月の歯抜けを調べる 日の歯抜けを調べる 時間の歯抜けを調べる dpoint改修時のつらみ DBのスキーマ変更する場合は導入してるアプリ全部での影響を調べ
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く