正しいデータは正しい設計に宿る - そーだいなるらくがき帳
って話をbuilderscon 2018でします。 builderscon.io 当日利用する資料はこちら。 speakerdeck.com 私のセッションはbuildersconの最終セッション。 皆さん素晴らしいセッションが並ぶ中で選択肢に迷ってる方も居ると思います。 だから先に公開しておきますのでこれをご覧になって、他のセッションに行くというのも有りだと思います。 あと事前に去年のトークを見てくれると当日はより理解が深まると思います。 同じ話を2回しても皆さんにとって勿体無いのでリファクタリングの細かい前提の話は当日はしません。 soudai.hatenablog.com 動画はこちら。 www.youtube.com これを見て、面白そうだなって思ったらぜひ、遊びに来てください。 僕が知ってるRDB設計、そしてRDBの歩み方を全てお伝えします。 あなたの新しい道の一歩目をご用意しま
GitLab.com Database Incident - 2017/01/31
This incident affected the database (including issues and merge requests) but not the git repo's (repositories and wikis). Timeline (all times UTC): 2017/01/31 16:00/17:00 - 21:00 YP is working on setting up pgpool and replication in staging, creates an LVM snapshot to get up to date production data to staging, hoping he can re-use this for bootstrapping other replicas. This was done roughly 6 hou
Redisアプリケーションパターン | おそらくはそれさえも平凡な日々
この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい
MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ
もう寒の入りを過ぎましたね。DBAのたなかです。 GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました（と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです） 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残 念 な が ら 腐 っ て お り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス ロ ー ク エ リ ー が 1 0 倍 く ら い に な っ た ん だ け ど … と訴え、彼はその
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
外部キー制約に伴うロックの小話
4. ロックおさらい（簡易） • 共有ロック（LOCK_S） 共有ロック同士は互いにブロックしない 例：SELECT LOCK IN SHARE MODE • 排他ロック（LOCK_X） 何も受け付けないぞ、排他 例：INSERT(成功), UPDATE, DELETE, SELECT FOR UPDATE X S X Conflict Conflict S Conflict Compatible 4 大きく分けてロックは2種類 5. 5 > BEGIN; > SELECT * FROM player WHERE id = 100 LOCK IN SHARE MODE; > BEGIN; トランザクションA トランザクションB 共有と排他順によるデッドロック例 6. 6 > BEGIN; > SELECT * FROM player WHERE id = 100 LOCK IN SHARE MO
Mackerelを支える時系列データベース技術 - ゆううきブログ
【追記 2018/01/06】現在Mackerelは、時系列データベースという概念をクラウドの技で再構築する - ゆううきブログの時系列データベース実装へ移行しています。 サーバモニタリングサービス Mackerel で採用している時系列データベース Graphite を用いたシステムの構築と運用事情を紹介します。Graphiteについては、プロビジョニングやアプリケーションからの使い方、Graphite自体のモニタリングなど様々なトピックがありますが、特に大規模ならではのトピックとして、Graphiteの内部アーキテクチャ、パフォーマンスチューニングおよびクラスタ構成についての知見を書きます。 背景 Graphiteシステム概観 データ構造とアーキテクチャ whisperのデータ構造 carbon-cacheのアーキテクチャ パフォーマンス特性 パフォーマンスチューニング ミドルウェアレ
Rrdtool基礎から応用
8. ■RRDの作成 ● rrdtool create を使います ● コマンドはこんな感じ rrdtool create ファイル名 オプション スキーマ定義 ● オプションには --start 初期時刻 --step 更新間隔 (先ほどの輪の小さい丸の間隔) などがあります 9. ■スキーマ定義 ● DS (Data Source) ● MySQLでいう所のカラム定義 DS:DS名:DSタイプ:ハートビート:最小値:最大値 で定義 ● DSタイプはGAUGE,COUNTER,DERIVE,ABSOLUTEのどれか ● ハートビートは有効更新間隔 RRA (Round Robin Archives) ● ● ● ● ● ● ● ● データサイズを決めるようなもの RRA:RRAタイプ:xff:ステップ数:行数 で定義 データ保存期間は ステップ秒数*ステップ数*行数 RRAタイプはAVE
SQLチューニング原論（仮） - ablog
もわっとしたイメージ重視のテキトーメモ。正確性、網羅性は重視していない。 チューニングの三原則 仕事量（計算量）を減らす 仕事量は CPUコスト + I/Oコスト とも言える 行単位でデータが必要な場合は行指向、列方向でデータが必要な場合は列指向など 圧縮でI/Oコストを減らす 並列化する アムダールの法則を考慮した上で、効果が望める場合は並列化する SIMD(SQLではなくハードウェアレイヤーでの並列化) 仕事を速くする 処理自体を速くする ディスク→SSD→メモリ→L1-3キャッシュ→レジスタ Software on Silicon とか 式で表すとこうなります。 仕事量（計算量）を減らすのが一番大切 データ（オブジェクト）構造が最も大切 表、索引、パーティショニングなど - SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus) P.292 「賢い
SSD-to-GPU Peer-to-Peer DMAとバッファ管理（その１） - KaiGaiの俺メモ
昨年の暮れ、JPUGカンファレンスのLTで『SQL+GPU+SSD=∞』と題したスピーチを行った。 SQL+GPU+SSD=∞ (Japanese) from Kohei KaiGai www.slideshare.net これはかいつまんで言えば、ストレージからデータをCPU+RAMへとロードするより前に一旦GPUへとデータを転送し、そこで不要なデータを削ぎ落してからCPU+RAMへと渡してやる事で、CPU負荷の軽減とRAMの有効活用が計れるというアイデアである。 実装としては、PCI-Eデバイス間でのP2P DMA機能を利用する事によってNVMe SSDの特定ブロックからGPU RAM上の特定の領域へDMAを実行するというものなので、ここは別に新しくも何ともない。 以下の図は、従来の仕組みにおけるデータの流れを示したもの。 SSDから読み出されたデータは先ずCPU+RAMにバッファされ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
