【初級】新人SEのためのSQLの基礎 最終回（前半） DBアプリケーション開発のポイント1〜2：ITpro
図3●アンケート結果を様々な切り口で集計するSQL文の例<BR>「1.回答者人数を年齢範囲で集計する」，「2.ある質問の回答数を年齢範囲で集計する」――という2つのSQL文の例を示した。このような集計は，SQL文でデータをまとめて取り出した後でJavaやVisual Basicのプログラムで集計することもできる。だが，大量データから集計する場合，できるだけSQL文で処理した方が実行性能が良い ロック待ちを回避したい場合，SELECT～FOR UPDATE文ではNOWAITオプションを付ければよい。実行性能を向上させるポイントは，(1)データ集計などはできるだけRDBMS上で処理し，(2)省略可能な処理はできるだけ実施しないことである。(3)省略可能な処理には，SQL文の解析処理とデータベースへの接続処理がある。そのほか，ミドルウエアの仕様を確認しておくこと，本番データを使ってテストしておく
postgreSQL Lock確認方法 - rinn@wiki
[iplocks@del-vm146 iplocks]$ ps -aef | grep post | grep -v grep iplocks 18556 1 0 17:14 pts/2 00:00:00 /usr/bin/postmaster -i iplocks 18558 18556 0 17:14 pts/2 00:00:00 postgres: stats buffer process iplocks 18559 18558 0 17:14 pts/2 00:00:00 postgres: stats collector process iplocks 21209 18556 67 18:11 pts/2 00:01:27 postgres: iplocks iplocksdb [local] DELETE [iplocks@del-vm146 iplocks]$ psql ip
主キーのナチュラル⇔サロゲート問題 - b6note
についてひとこといっておくか、みたいな。 複合主キーを避けるべき理由 http://d.hatena.ne.jp/torazuka/20110713/pk 今回これを書きながら、色々考える機会になりました。 ありがとうございました＞id:torazuka さん 自分のぶこめ http://b.hatena.ne.jp/akitsukada/20110715#bookmark-50842882 複合主キー、ここでいう「ナチュラルキー」は論理設計とか分析モデルのときにデータの意味をはっきりさせるために抽出し、物理設計/実装段階で物理的制約や要件に応じてサロゲートキーをつければいいと思うと書いたんだけど、何しろ100文字ではちょっと足りないので もうちょっと自分の考えを補足 わたしの考え まず自分の立場は、上記のブコメを展開して データモデリング、分析、論理設計の段階ではID（サロゲートキー）を
[ThinkIT] 第3回：トランザクションの比較 (4/4)
それぞれのトランザクション機能を使用する上で注意しなければならない点があります。 まず1つ目は、それぞれのトランザクション分離レベルのデフォルト設定が異なる点です。PostgreSQLのデフォルト設定はリードコミッティドであり、InnoDBエンジンのデフォルト設定はリピータブルリードです。 2つ目は、それぞれのトランザクションの分離レベルをシリアライザブルにした時の動作の違いです。 InnoDBエンジンのシリアライザブル状態は、図1のようにトランザクション1のSELECT文によって、テーブル「TEST」をロックしてしまうため、トランザクション2のDELETE文が実行できずロックの開放待ちになってしまいます。
JavaとDBのデータモデルはナゼすれ違う？
JavaとDBのデータモデルはナゼすれ違う？：JavaのDBアクセスを極める（1）（2/2 ページ） 開発手法の違いによるインピーダンスミスマッチ （1）ビジネス要件の複雑化に伴うさまざまな開発手法の出現 昨今、目まぐるしく変化する顧客やマーケットのニーズに伴い、システムに対するビジネス要件も、その変化は激しさを増しています。そのため、ビジネス要件を満たすのはもちろんのこと、プログラムの機能面での拡張性やメンテナンス性も強く要求されるケースが増加し、それに伴い開発手法もオブジェクト指向開発に代表されるように、拡張性を担保することを意識したさまざまな方法論が生み出されてきました。 しかし、これらの新しい開発手法だけで、すべてのシステムの実装を、拡張性を持って行えるかというと、そう簡単にはいきません。筆者の私見では、古くからある構造化手法（POA）やDOAなどの開発手法と新しく生み出されたオブ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ SSDがHDDに代わるストレージとして普及しようとしていることを背景に、SSDに特化したまったく新しいアーキテクチャを備えたリレーショナルデータベースを開発しようとしている企業があります。「ReThinkDB」です。 昨年7月に、PublickeyではReThinkDBの概要を記事「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現」で伝えました。 その記事の中では、ReThinkDBがロックを使わずにトランザクションを実現し、データベース利用中でもスナップショットがとれ、また異常終了しても容易に復帰できる機能を備えている、といったことを紹介しました。 4月に米サンタクララでに行われた「MySQL Conference & Ex
データベース負荷テストツールまとめ(4) - SH2の日記
データベース負荷テストツールまとめの第4回です。 データベース負荷テストツールまとめ(1) TPC-B、TPC-Wベースのツールを6つ紹介 データベース負荷テストツールまとめ(2) TPC-Cベースのツールを6つ紹介 データベース負荷テストツールまとめ(3) TPC-Hベースのツールを2つ紹介 今回はTPC-Eベースのツールを見ていきたいと思います。 TPC-Eとは TPC-EはRDBMSベンチマーク仕様の一つで、オンライントランザクション(OLTP)の性能を測定するものです。証券会社の業務をモデルとして取引や市場の監視、メンテナンス処理を行い、1秒あたりに行った取引件数を性能の指標値とします。 OLTPのベンチマークとしてはこれまでTPC-Cがよく用いられてきました。しかしTPC-Cは1992年の策定から実に18年が経過しており、その間コンピュータのCPU性能はムーアの法則にしたがって伸
［Web 2.0 Expo］「これからのWebを支えるデータベースは“NoSQL”」---米10genのMerriman CEO
「今後12カ月以内にWebインフラを新しく立ち上げるプロジェクトの大多数は，プライマリ・データストアとしてRDB以外のデータベースを選ぶだろう」。オープンソースのデータベース開発プロジェクト「MongoDB」を支援する米10genのCEOであるDwight Merriman氏（写真1）は，「Web 2.0 Expo New York 2009」でこう予測した。 Merriman氏は，「表と表の関係でデータを処理するリレーショナル・データベース（RDB）は，現在のWebアプリケーションの実態にそぐわない。リレーショナル・モデルに向かないデータ処理や分析処理が急増しつつある」と指摘。Webでは，写真や動画といった巨大データを多数のユーザーがやり取りし，クレジットカード情報もあればTwitterのつぶやきまでと価値の異なるデータと混在している。このため最近Web技術者の間で「NoSQL」と呼ばれ
分散データベース2 - WebLab.ota
分散データベース - WebLab.otaの続き Distribution,autonomy,heterogeneity FDBS (A1,D0,H1)：異種混合 (A1,D1,H1)：異種混合＋分散 MDBS (A2,D1,H1) (A2,D2,H1)：各DBSコンポーネントがほかのDBSの存在を知らない． 必要なときに自律的につながる PDBS MDBSのanother instanceに見える しかし，２つは違うデータアクセス方法をサポートしてるよね MDBSはマルチデータベースレイヤ上で問い合わせのインタフェースをサポートしている（下図参照） PDBSは図のようにクエリが転送されていく このとき，クエリはオリジナルから変更されて転送されるかもしれない．（中継ピアが変更する可能性があるよね） さらにforwardingはマッピンググラフによって行われ，全ピアに転送されるとは限らない
大規模SNSのボトルネックとソリューション
SNSは比較的データアクセスが多いアプリケーションであり、負荷対策が難しい部類に入る。本稿では、グリーCTOの藤本真樹氏が、GREEというSNSでの経験を基に、SNSの具体的な負荷軽減ソリューションを紹介する。 はじめに 昨今では、地方自治体や企業内でもSNSを導入する動きが活発化しているようです。しかし、SNSは比較的データアクセスが多いアプリケーションであり、負荷対策が難しい部類に入ります。そこで本稿では、前回お届けした「大規模SNS実現のためのGREEのアプローチ」の内容からもう一歩踏み込んで、GREEというSNSでの経験を基に、SNSの具体的な負荷軽減ソリューションを紹介します。 SNSのボトルネック 一定以上のユーザー数、データ量、そして機能を持つSNSでは、普通に構築していくと非常に悩ましいボトルネックが2つ顕在化してきます。1つは、「友達の新着」系の情報取得です。もう1つはア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT & ワークフォース ソリューション | Dell Technologies Japan
サービス終了のお知らせ