プロセスの基礎再確認シリーズもこれで3つめ。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき ここまで見てきた間でも、ターミナルから irb を起動したり、Ruby コードから system メソッドを呼び出したりすることで子プロセスを扱ってきた（結果的に）けれど、自らの手で意図して子プロセスを作り出す、ということはしてこなかった。 今回は、子プロセスのメリットやその作り方、扱い方を中心に再確認したもののメモ、という形になる。項目的には以下。 fork で子プロセスを作る fork が高速なワケ fork で作った子プロセスを待つ 子プロセスの面倒を見る fork で子プロセスを作る fork(2) システムコールを使うことで、実行中のプロセスから新しいプロセスを生成することができる。 生成されたプロセスは
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
[MySQL]原文 Tuning InnoDB Primary Keys - Percona Database Performance Blog (English) 原文著者 Yves Trudeau 原文公開日 2018-07-26 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 2547日前 原文へのコメントで報告済み 編集 良いInnoDBプライマリキーを選ぶことは、パフォーマンスチューニングの方向性にとても重要です。この記事では、あなたのワークロードに応じた最適なプライマリキーを選ぶための方法を紹介したいと思います。 Percona社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
RDBMSのテーブルにINDEX（セカンダリINDEX）を作成する場合、よく「カーディナリティが低いカラムには作るな」と言われます。 どんな場合でも当てはまるのか、少し実験して確かめてみます。 カーディナリティとは 今さら解説するまでもないかもしれませんが、「あるカラムにおける、取りうる値の種類」のことです。 ER図など、DBに絡む場面で別の意味で使われることもありますが、ここではこの意味で使います。 例えば、性別を表すカラムがあり、必須で値を入れなければならない場合は、「男性」「女性」の2種類、です。 「カーディナリティが低いカラムにINDEXを張るな」の意味 先に挙げた「性別」の場合、もし対象となる全レコードで男女の比率がほぼ１：１であれば、INDEXで絞り込める範囲は1/2程度です。絞り込みの効果があまりありません。 このような場合は、わざわざセカンダリINDEXを使うのではなく、テ
MySQLのインデックスを効果的に使うにはどうしたらいいのかについての分かりやすい解説。そもそもインデックスの役割はとは何か、そしてどうすればその役割を果たしてくれるのかを説明する。 たとえ1つのテーブルだけに対して実行されるクエリでも、パフォーマンスが悪いというのはよくあることです。その理由は簡単で、インデックスの作り方がまずいため、実行計画がおかしくなってしまうのです。ここでは、1つのテーブルのみに対する色々なクエリを最適化するためのガイドラインを挙げてみたいと思います。 おことわり : あらゆる状況をカバーしようとはせず、一般的なガイドラインを提示するに留めるつもりです。ここで挙げたものがうまく適用できない例を簡単に見つけることができるのは間違いないでしょうが、ほとんどの場合はここに書いたことが十分なのも事実です。また、MySQL 5.6以上にあるIndex Condition Pu
概要 大規模なデータを管理するためのMYSQL-INDEXについて必要な情報をまとめてみます PRIMARYKEY / UNIQKEY / INDEXについて PRIMARYKEYとはそのテーブル内において重複が許されないもので、自動的にINDEXが張られる。 UNIQKEYとはそのテーブル内に置いて重複を許さない。ただし、NOT NULLにしなければNULLの重複は認める。 INDEXとは特定の値を持つレコードを高速に検索するための木構造データ。INDEXを張らないとテーブル全体のデータを検索してしまう。最適化されたINDEXを利用するとテーブルデータを全く参照せずにデータを返却できる。 まとめるとPRIMARYKEY = UNIQKEY + INDEX 複合INDEXについて 複数のカラムに対してのINDEXを作成する事。単一のINDEXより高速な検索ができる。 複合INDEXを利用す
{{toc_here}} InnoDB パフォーマンスチューニング MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.11 InnoDB パフォーマンス チューニング ヒント MySQL :: MySQL 5.1 Reference Manual :: 13.6.13.1 InnoDB Performance Tuning Tips 長過ぎる PRIMARY KEY を避けてディスク領域の無駄遣いを避ける セカンダリインデックス用に余計な領域を使わないよう、長い主キーを避ける 主キーが長い場合、代わりに AUTO_INCREMENT なカラムを主キーとして作成するとよい 補足 MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.13 InnoDB テーブルとインデックス構造 MySQL :: MySQL 5.1 Reference Ma
複合インデクスとは、テーブルの複数のカラムを組み合わせて１つのインデクスとするものです。 たとえば、以下のようなカラムを持つ「従業員マスタ」というテーブルに「姓」と「名」で１つのインデクスを作成することを指します。 従業員マスタ 従業員番号 姓 名 性別 住所 生年月日 入社年月日 会社 所属部門 職位 レコード作成日時
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く