[B! DB] sobataroのブックマーク

片手間MySQLチューニング戦略

2017/10/08 phpcon 2017 https://joind.in/event/japan-php-conference-2017/session05-mysqlRead less

sobataro 2017/10/10

DB
MySQL

リンク

O/Rマッパーによるトラブルを未然に防ぐ

「ORMがトラブル起こすから嫌い」なんじゃなくて、「ORMが起こすトラブルが解決できないから嫌い」ってのがほんとのところじゃない？だったら解決方法を知ればいいんじゃね？というお話。「N+1問題」もろくに知らずにORMを批判せんでほしい。Read less

sobataro 2014/12/23

DB
ORM

リンク

はじめにこれはドリコムAdventCalendar の1日目ですはじめに 1日目：ドリコムを支える中間ポイントシステム一応自己紹介プリキュアおじさん嫁はキュアピース開発の背景ソーシャルゲームの歴史中間ポイントについて前受金と資金決済法について有償ポイントと無償ポイント複雑な売上計算ドリコムの中間ポイントシステム(dpoint)について自分の役割重要なこと dpointが導入されているアプリ課金フロー iTunesでの中間ポイント購入 GooglePlayでの中間ポイント購入ポイント消費 dpointのリリースノート gemのボリューム date_discreterというgemを作りましたどういうgem？月の歯抜けを調べる日の歯抜けを調べる時間の歯抜けを調べる dpoint改修時のつらみ DBのスキーマ変更する場合は導入してるアプリ全部での影響を調べ

sobataro 2014/12/01

リンク

ソーシャルゲームでDB水平分散 #mdb_casual

2014/11/10に開催されたRails複数DB Casual Talksでの発表資料になります。

sobataro 2014/11/13

リンク

分割と整合性と戦う

え、まって。その並列分散処理、Kafkaのしくみでもできるの？ Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理NTT DATA Techno logy & Innovation

sobataro 2014/09/05

リンク

Facebook, Twitter, Instagram等がどうやってIDを生成しているのかまとめ - Qiita

まえがきデータにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。データベースのauto incrementを使う場合利点: 特別な実装が必要ない欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない世界の大企業がどうしてるか調べてみると多くの企業がブログなど