補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年6月2日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日のエントリ(徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考)は思いがけず多くの方に読んでいただいた。ありがとうございます。その中で高木浩光氏からブクマコメントを頂戴した。 \がescape用文字のDBで\のescapeが必須になる理由が明確に書かれてない。\'が与えられたとき'だけescapeすると…。自作escapeは危うい。「安全な…作り方」3版で追加の「3.失敗例」ではDBで用意されたescape機能しか推奨していない このうち、まず「\」のエスケープが必
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1~5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
2006年9月21日,待望のPostgreSQL 8.2のベータ版がリリースされ,PostgreSQL8.2の全容が明らかとなった。全体的にはそれほど目だった新機能はないが,細かな改善や,性能向上がなされているようだ。 本連載でも25回と30回で8.2の新機能や改良点を取り上げてきたが,それを簡単に復習してみよう。 25回では,CE(Constraint Exclususion)という,継承を使ったテーブルパーティショニング機能の改良,pg_freespacemapの追加を紹介した。また,ソート処理とディスク上のビットマップを使ったVACUMMの高速化への試みについても紹介した。残念ながらVACUUMの高速化は盛り込まれなかったが,ソート処理の高速化は8.2に取り込まれた。 30回では,GINという新しいインデックスタイプの追加,COPYやINSERTの改良について紹介した。 本稿ではこれ
ポイント ・高度なインデックスやジョインを利用し,最短経路でデータにアクセス ・メモリー不足を自律的に解消し,キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し,高速化を図る 目的地に早く到着したいなら,最短の経路を最速で行けばよい。これはデータベース(DB)でも同様だ(図1)。インデックスなどを使ってデータへの最短経路を見つけ,メモリー・アクセスを増やして,最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では,(1)データにたどり着く最短の道を選ぶ仕組みと,(2)アクセスのスピードを上げる仕組みの
最新文章 2018-12-26 20:02▪ 上思一KTV安全出口数量不足被消防部门依法查封 2018-12-26 20:02▪ 乌向俄放狠话:捍卫刻赤海峡“主权”是我们的责任 2018-12-26 20:02▪ 中餐的魅力有多大?看这些外国人的痴迷程度就知道 2018-12-26 20:02▪ 大冶发生一起3人死亡的冒顶事故公司所属矿山连续7年发生... 2018-12-26 20:02▪ 印度油罐车与客车相撞至少11人死亡 2018-12-26 20:02▪ 视频|两江新区邢家桥社区旁天然气管道泄漏消防队员已成功... 2018-12-26 20:02▪ 日本农相拟就重启商业捕鲸寻求国际社会理解 2018-12-26 20:02▪ 上海到青岛高铁建设又进一步!青盐铁路12月26日开通 2018-12-26 20:02▪ “深圳虐童事件”女童身体指标正常克服心理阴影或还需时间 2018-
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
PostgreSQLのチューニング PostgreSQLは最適なパフォーマンスが出るように自動的に調整されるため、特別なチューニングテクニックは必須ではありませんが、最大限にパフォーマンスを引き出したい場合にはpostgresql.confで指定している値を調整することによりチューニングが可能です。また、PostgreSQLのパフォーマンス向上のためには定期的にVACUUMコマンドを実行することをお奨めします。 ■VACUUMコマンドを実行する VACUUMコマンドはPostgreSQLデータベースの掃除と解析をおこなうコマンドです。 定期的にVACUUMコマンドを実行するとデータベースの問い合わせのパフォーマンスが向上します。 VACUUMコマンドによる処理はテーブルが大きい場合は時間がかかりますので、あまりアクセスのない時間帯におこなうとよいでしょう。 ●VACUUMコマンドの文法 v
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ -空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ - postgresqlグループ.の元エントリを読んで思うところがあったのだが、 PostgreSQLを高速化する16のポイント だからそんなせまっくるしいところでトンチンカンにdisる暇あるんだったら自分のブログでお好みの議論を書くかさもなきゃ/dev/nullにでも吐けとやんわりと言ってるんだよハゲ。 というわけでw。 だよねw。 まあ正直、上記元ネタのほうには色々突っ込みどころ満載なのだが、それは置いておくとしてL.starなりの高速化ポイントを一度書いておかないと、と思ったので記す。ただ、L.starはもうPostgreSQL界隈から離れて久しいので、必ずしも最新の内容を網羅していないことに注意されたし。また、出来るだけPos
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Free Credit Report music videos Migraine Pain Relief Best Mortgage Rates Credit Card Application Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
出力内容を追いかけろ 実際に実行してみてどれだけの時間がかかったかは「actual time=」で表示される数値を追いかけることで確認可能です。例えば、前ページのリストの1行目に出力されている「actual time」だけを取り出すと、次のようになります。 ↓最初の1件目を取得するまでにかかった時間 (actual time=9006.586..9011.968 rows=16842 loops=1) ↑最終的に結果行全体を取得するのにかかった時間 特に、右側の数値である「最終的に結果行全体を取得するのにかかった時間」では、そのSQLの処理開始からの累積時間で表示されます。このため、当該行の処理が完了するまでにどれだけの時間がかかったかを確認できます。 これを基に、SQLの中でどの処理に最も時間がかかっていたのかを確認していきましょう。 Total runtimeが9022.840msであ
by 柴田 淳 — posted at 2005-10-26 23:48 last modified 2006-12-04 12:41 アプリケーションも何も無いのに、単に「デキの悪いSQLを作って、それをチューニングする」というのは非常に難しい。。 というわけで、とりあえず適当なサンプルデータを取ってくることにしました。ちょうど、IPAのOSS推進フォーラムでOSDLのDBT-1というベンチマークを浸かってPostgreSQLの評価をするとかの資料があったので、これをちょいと利用させてもらって、DBT-1のデータを作成することにしました。 がさごそ。がさごそ。 というわけで、ちょっと手間がかかったのですが、テーブル10コから構成されるサンプルデータベースが作成されました。もちろんサンプルデータもあります。 testdb=# \d List of relations Schema |
UMLでデータベース設計 Posted in UML & MindMap (RSS), データベース (RSS), 書籍 (RSS) UMLモデリングツールでも、ER図によく似たダイアグラムを作成する機能を持ったものもあります。 例えば、僕が普段使用している「Enterprise Architect」では、データモデリングプロファイルを利用して、クラス図をベースとした "データモデル図" を 作成することができます。 また、DB2、MySQL、Oracle、PostgreSQL、MsSQL等のデータベースから "データモデル図" へリバースしたり、 "データモデル図" からDDLスクリプトを生成することもできます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く