ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、オークション事業部のWangです。 データウェアハウス（以下DWH）という言葉になじみのない方は検索していただいたほうがよいかもしれません。 検索するのがめんどい、という方は、かみ砕いた表現ができなくて恐縮ですが、 基幹系システムから抽出したデータを目的をもって再構成し、 使用可能な状態に保管されたデータの集合体、とお考えください。 オークションでは、具体的には出品、入札、落札などのトランザクションデータや、 それをいろいろな単位で集計したデータなどが該当します。 ここでいう単位というのはたとえば、日ごと、週ごと、月ごとや、以前の記事でも紹介されている カテゴリといったものになります。 こういったデータは、運用、運営、
See related links to what you are looking for.
useServerPrepStmtsのここの説明ではデフォルトがtrueになっているが、これは上述の通り嘘である。 (中略) そしてなぜfalseにされたかということの背景を察すると、trueにすることの弊害もありそうで、手放しでこれをtrueにすることを勧めることが少しはばかられる。 http://www.geminium.com/chiba_blog/2008/12/23/33/ 自分は Java 使ってないですが、MySQL の中の人が使うなって言ってます *1。その理由はメモリリークのような症状が出る可能性があるから。 So why are prepared statements a problem? Because users do not clean up/close unused prepared statements. Multiply the number of prep
とりあえず、Pathtraq の開発用テストデータの URL テーブルの圧縮率テスト。 形式 バイト数 圧縮率 無圧縮 717,225,984 100% 独自*1 406,847,488 57% InnoDB 圧縮*2 360,710,144 50% 独自 & InnoDB圧縮 239,075,328 33% 現時点での感想。 カスタマイズされた圧縮アルゴリズムは依然有効 インデックスも圧縮できるという意味で InnoDB による圧縮は効果が高い 速度がどうなるかは、実際のワークセット＆メモリ搭載量で見ないとどうしようもないし、Pathtraq はそもそもオンメモリDBなので InnoDB 圧縮は使わない可能性が高いけど。 *1:URLカラムを独自方式で圧縮 *2:ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8
Section Navigation [Toggle] 5.1 The MySQL Server5.1.1 Option and Variable Reference 5.1.2 Command Options 5.1.3 System Variables 5.1.4 Session System Variables 5.1.5 Using System Variables 5.1.6 Status Variables 5.1.7 SQL Modes 5.1.8 Server-Side Help 5.1.9 Server Response to Signals 5.1.10 The Shutdown Process The following table provides a list of all the command line options, server and sta
ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」 YAPC::Asia 2006 Tokyo 東京都大田区で開催されているPerl技術者向けカンファレンス「YAPC::Asia 2006 Tokyo」で2006年3月29日，日本最大のソーシャル・ネットワーキング・サイト（SNS）である「mixi」を運営するミクシィのBatara Kesuma（バタラ・ケスマ）取締役最高技術責任者（CTO）が，増え続ける膨大なトラフィックにどのように対処してきたのかについて講演した。カギとなるのは「データベース分割」である。 mixiのシステムはもともとBatara氏が1人で作り上げたものだ。2003年当時，米国でFriendsterなどのSNSがはやっており，同氏が会社（現在のミクシィ，当時はイー・マーキュリー）にSNSを作りたいと提案したところ認められたという。同氏が
Senna+MySQLをより超高速にするパッチ 当者比50～100倍程のスピードアップ（クエリ/テーブル構造による）のパッチです。 MySQL(特にFullText boolean mode)のlimitの実装はある意味効率の悪い実装になっている。 例えば、limit 100000,100といったクエリを投げると100100行分のデータをディスクから読み込むのである。 まぁ、whereなどの条件に一致する100000件のレコードを先に確定させなければいけない訳で当然といえば当然である。 order byとか使ってたらなおさら。 無論SQL_CALC_FOUND_ROWSなんか使ってると全件確定させなきゃいけないから大変。 当然これらはindexを使用していない時の挙動だと思う。 indexのみが使われたクエリの挙動は未確認だけど。 さて、ここから本題。 では、Senna+MySQLの挙動は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
