|エンジニアが作る最新ITブログ　トップ |新着画像 |新着記事 |サイトのRSS |

エンジニアが発信する【その他DBMS】の記事を集めました

エンジニアが作る最新ITブログ トップ>エンジニアの発信する【その他DBMS】

   前のページへ   次のページへ

2011年06月11日

SQLインジェクション対応を見直す時期かな

Sonyグループの情報流出事件が頻発していますね。Sony Picturesも流出を認めたそうです。
先日攻撃者側から出てきた情報や今回のニュースをみるとだいたい狙われているのはSQLインジェクションの脆弱性。Sony全体で同じような脆弱性があるのか、それとも新たな抜け道があるのか・・・。Sony関連企業がこれだけ狙われると特定の問題ではないかと推測したいところですが・・・。
（SQLだけではなく実際には、クロスサイトスクリプティングやiframeインジェクションとシステム攻撃の王道がターゲットにされているようですね）

皆さんも今一度SQLインジェクションやXSSなど脆弱性対策を見直したほうがよいと思いますよ・・。

Sony Picturesが個人情報の流出認める、ポルトガルでも攻撃発生 - ITmedia ニュース




SQL Injection Attacks and Defense

SQL Injection Attacks and Defense






XSS Attacks: Cross Site scripting Exploits and Defense

XSS Attacks: Cross Site scripting Exploits and Defense

  • 作者: Seth Fogie
  • 出版社/メーカー: Syngress
  • 発売日: 2007/05/23
  • メディア: ペーパーバック



Seven Deadliest Web Application Attacks (Syngrass Seven Deadlest Attacks)

Seven Deadliest Web Application Attacks (Syngrass Seven Deadlest Attacks)

  • 作者: Mike Shema
  • 出版社/メーカー: Syngress
  • 発売日: 2010/03/31
  • メディア: ペーパーバック


編集者: たーとる | このブログのURL |この記事のURL

2011年05月09日

「ビッグデータを征す クラウドの技術 Hadoop&NoSQL」

ネットで検索してもらえばわかりますが、ここ数か月でHadoop関連のビジネス情報って増えましたよね。
そして非構造化データの取り扱いやデータ分散化に対応するためのNoSQLサーバも増えてきました。なかなかNoSQLを適用しなければならないケースには出会わないけれど、今後のシステムでNoSQLはRDBMSと同じくらいに重要性が増すものと考えています。そんなとき、NoSQLとはどんな特性のものか、数あるNoSQLサーバはどんな点が違うのか、そういった基礎情報は常時認識していたい。そんな欲求を満たすのがこの書籍です。
Cassandraはかなりの紙面をさいて説明しているのでそちらに興味のある方はうれしい内容です。

また今までバッチ処理していた業務システムのいくつか、特に大量データを扱う部分はもしかするとHadoopやそれに類するシステムに置き換わっていくかもしれない。いくつかのベンダーがHadoopソリューションの提供を開始しているのは業務システムのリプレースという側面があるだろう、と個人的には理解しています。
なのでこれも逃せない内容ですよ。


ビッグデータを征す クラウドの技術 Hadoop&NoSQL

ビッグデータを征す クラウドの技術 Hadoop&NoSQL




こんな本も出ていますので、注目！！


NoSQLデータベースファーストガイド

NoSQLデータベースファーストガイド

  • 作者: 佐々木 達也
  • 出版社/メーカー: 秀和システム
  • 発売日: 2011/04
  • メディア: 大型本



Hadoop徹底入門

Hadoop徹底入門

  • 作者: 太田 一樹
  • 出版社/メーカー: 翔泳社
  • 発売日: 2011/01/28
  • メディア: 大型本


編集者: たーとる | このブログのURL |この記事のURL

2011年04月28日

MySQL 5.6 と NewSQL

「MySQL 5.6」 の開発版がリリースされました（Dev Milestone Release）。memcached 互換のプロトコルによって InnoDB にアクセスすることも可能になるとのことです。面白いですね。このように NoSQL の機能を取り込むなどして進化した RDB に対して、“NewSQL” という呼称が使われることもあるようです。 関連情報・MySQL 5.6開発版マイルストーンリリース、NoSQL機能も提供 | マイコミジャーナル・漢(オトコ)のコンピュータ道: MySQL 5.6登場！！新機能速攻レビュー・MySQLの次期バージョンはMemcached APIを備える！ MySQL Conference & Expo 2011基調講演 － Publickey ・リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想 － Publickey・InfoQ: NoSQL、NewSQL、そしてその先 ・Jungle Java - 『WEB+DB PRESS Vol.50』・Jungle Java - 『みてわかるクラウドマガジンvol.1』・Jungle Java - VoltDB 関連情報メモ・Jungle Java - Drizzle は MySQL からフォークしたクラウド志向の DBMS

編集者: baraki | このブログのURL |この記事のURL

2011年04月23日

処理高速化対応！

さて、勇者を育てろですが、、、
このプログラムは仕事の合間に作っている為にリファクタリング等をいっさい行ってませんでした。
フィーリングで作っていつつ、Railsがカバーしてくれているためそこそこ動くという状況でした。

しかし、先週あたりにリリースしたパーティー機能によって戦闘の計算ロジックが大幅に変更されてフィーリングプログラムでは駄目になってしまいました・・・。
どうなったかというと・・・

ロードアベレージが１を超える

という事が発生してしまいました。
ピーク時は絶えず１～２を保つようになってしまい、これはそろそろプログラムにてこを入れる必要がありました。

で、ロードアベレージって何かというと実行待ちのプロセス数を表す単位になります。
単純に考えると１より低ければそのサーバーは自分の仕事をしている状態になります。しかし、１を超えると一つのCPUでは処理が出来ない状況になります。
瞬発的に１を超える事はほとんど問題になりませんが定期的に１を超えるという事は、どんどん仕事がたまって行く事を意味します。（実際はそんなに単純ではないのですが・・・。）

なので、フィーリングプログラムをリファクタリングしました。
調べてくると出て来たのが以下。

・SQLの重複を押さえる
同じSQLが幾つも流れてる箇所がとても多い。Railsでは同じSelect文が流れている場合はキャッシュを返してくれる。しかし、Update文となると別。
僕のプログラムでは個々のモジュール毎に処理をさせていて、そのモジュール内で処理を完結させるため同じモデルを扱う場合にはあちらこちらでUpdate文が走ってしまっていたのです。

・SQLの発行回数を押さえる
一つ一つのデータを取るパターン。例えば勇者のデータを３つ取得するときは、３回SQLを発行させるのではなくIN句を使って一度のSQLで取得する。こんなの基本的な事だけど、コントローラーをビューにロジックが散らばってしまうと意外と起こる。
また、あまり変動しない値（例えば掲示板のカウント）とかは５分毎に全データを取得してキャッシュに格納させるという事を行った。
今回はMysqlを使用しているためマルチプルINSERT（バルクインサート）が使えるため、Insert文の発行回数も極力抑えた。（ここで難しかったのはhas_manyとバルクインサートを両方使う時だ。※詳細については需要がありそうだったら書きます。）
これによって、SQLの発行回数を大幅に下げました。

・エラー処理を適切なものにする。
勇者を育てろでは、とにかく手を抜いているため・・・（苦笑
エラー時の処理はサーバー内部でエラーを発生させて、クライアントには何もデータを返さなかった。しかし、エラーが発生するたびにExceptionを発生させるのは非常にコストがもったいなかったのでエラー処理を適切に行うようにしました。



僕の場合はロードアベレージは高くてもCPU使用率はそこまで高くなかったので、とにかくSQLを減らしてIOを減らせば良いためこのような対応をしました。
・・・が、ここに書いている以上に大変な作業でした。

で、これによって

ロードアベレージは0.3前後

に落ち着きました。
何にしても、今のユーザー数でこの状態はまずかったので僕としては必死に直しました。

そんな勇者を育てろはこちら です。
是非、効果のほどを感じてください・・・って分からないだろうな。。。


P.S.
あと、どさくさにまぎれてパーティメンバーを自分のいる場所に呼び寄せる召還魔法を実装しました。
手に入れるのはかなりきついですが、是非とってください！
（ちなみに、僕は「ジョウ」という名前で冒険していますのでであったら声をかけてください。）
  • なうで紹介
  • mixiチェック
  • ツイートする

編集者: 傲慢SE | このブログのURL |この記事のURL

2011年04月21日

2011年04月20日のツイート

@nobusue: リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想 ? Publickey URL 2011-04-20 16:49:00 via Hatena @nobusue: 放射能防護服や通信機器が足りない URL 2011-04-20 14:54:55 via web @nobusue: そして「核融合」は実験炉を着々建設中 URL 実用化に向けて着々と進んでるんですね 2011-04-20 14: ...

編集者: nobusue | このブログのURL |この記事のURL

2011年04月13日

バックアップの種類

データベースには通常バックアップ機能が備えられている。DBMSによって若干異なるが、コマンドラインで行うもの、対話的にできるツールがあるもの、など。

SQL Server ではバックアップの方式や対象が異なる３種類のバックアップがある。バックアップは、テーブル単位ではなくデータベース単位で行われる。

・完全バックアップ
データベースの状態をそのまますべて確保するバックアップである。フルバックアップともいう。以下に挙げる２つのバックアップ方式を実行する場合であってもこのバックアップが一度は実施されていることが前提となる。つまりは、データベースが壊れたとき、これがないことには復旧できない、ということになる。

・差分バックアップ
直前の完全バックアップ時点からの差分のみを確保するバックアップである。差分のみなので全てを確保するより実行時間が短くて済む。
完全バックアップ後に差分バックアップを複数回実行したときはどうなるか？前述の通り「直前の完全バックアップ時点からの差分のみ」を確保するので、最新の状態を確保しておくためには完全バックアップと、最新の差分バックアップがあればよい、ということになる。

・トランザクションバックアップ
データベースのデータではなく、そのログファイルを確保するバックアップである。ログファイルとは「実行された更新系のSQL文が確保されているもの」である。直前の完全バックアップまたはトランザクションバックアップ時点からの差分のみを確保する。差分のみではあるが、更新量が多いデータベースの場合はかなり時間が掛かるケースがある。


さて、使い方である。これは「どのくらいの履歴まで再現が必要か」「どのくらいの重要度があるのか」に依存する。
どの時点まで戻す、というようなこともなく、日中は稼働させるが夜間はほぼ動かすことがないような場合
　・週に一度　or　月に一度　完全バックアップ
　・上記以外の毎日　　　　　差分バックアップ
くらいで十分だろう。更新されるテーブルを含むデータベースであれば最低限このくらいの対応はしたいものだ。これ以外ばケースバイケースである。


参考まで。ごく当たり前の話として「バックアップを確保する先は、バックアップ元と同じ物理ドライブには置かない」ということを理解しておく必要がある。
データが壊れる最大の要因はHDDなどのメディアの故障である。おなじドライブ上に入れていては「バックアップもろとも消滅」となる。
USB接続のHDD等でもよいから、バックアップは必ず別の物理メディアに格納しよう。

なお、ワークグループではなくドメインを構築している場合、LAN上のドライブに直接バックアップを確保するのは少々知識や設定が要るので注意が必要だ。
簡単に言えば
・SQL Server を実行しているIDがワークグループ上で、該当するLANのドライブに読み書き権限があること。
だそうだ。サーバーであれば「そのサーバー独自の管理」とし、ドメイン参加させないケースも多いと聞く。このあたりはハマるポイントらしい。
同じテーマの最新記事
  • なうで紹介
  • mixiチェック
  • ツイートする

編集者: ぽせい丼 | このブログのURL |この記事のURL

2011年02月18日

復旧モデル

データベースといえばデータ命である。DBMSによって若干異なるが、データを保全する仕組みがあることが多い。

SQL Server ではその保全レベルに応じ、トランザクションログの扱いが異なる３種類の復旧モデルがある。この復旧モデルは、テーブル単位ではなくデータベース単位で設定する。

・単純復旧モデル
トランザクションログは確保されない、と考えて頂いてよいだろう。
用途としては読み取り専用のデータベース。更新が行われるデータベースではこれであればいいだろう。

・完全復旧モデル
トランザクションログファイルにトランザクションとデータの更新履歴を書き込む、真面目な方法である。
一般的に更新が行われるデータベースはこれを用いている。

・一括ログ復旧モデル
通常は完全復旧モデルとそう変わらない。異なるのは一括処理のときのトランザクションログの記録方法で、この復旧モデルの場合では簡単なログしか取得しない。
通常は完全復旧モデルとしているデータベースに、膨大なデータを一括で書き込むときに切り替えて使うのが一般的らしい。一括処理の時のパフォーマンスの向上とログの肥大化を防ぐためのモデルと言える。


これから読み取れることは、読み取り専用データベースは更新の入るデータベースとは分離した方がバックアップの効率という面ではよい、といえるだろう。



同じテーマの最新記事
  • なうで紹介
  • mixiチェック
  • ツイートする

編集者: ぽせい丼 | このブログのURL |この記事のURL

2011年02月09日

SQL Server 備忘録開始

SQL Server は意外と奥が深いらしい。DBMSとして管理機能は充実している。細やかな設定ができる分、使いこなすのに知識が要るようだ。

マイクロソフトでは情報を積極的に開示している。しかし、意外と情報を見つけにくいようである。そこで、このブログの記事で概要を、詳細はリンクを張って理解に役立つようにしてみようと思う。

週に１本程度かな？
同じテーマの最新記事
  • なうで紹介
  • mixiチェック
  • ツイートする

編集者: ぽせい丼 | このブログのURL |この記事のURL

2011年01月21日

第二回　Get The Face セミナー

今、仕事でデータベースはSQL Server を使っている。周囲にSQL Serverのエキスパートが居ないので折角だからと知識を強化しているところだ。SQL Serverの細部までカバーすれば、他のデータベースで「できる／できない」の比較がより詳細なレベルでできるようになり、DBMSの選択基準がよりしっかりしたものになるだろうと考えている。

ということで、 2011/1/20（木）19:00 よりマイクロソフト主催のセミナーがあったので受講させて頂いた。場所はマイクロソフトの新宿オフィス。
http://www.microsoft.com/japan/sqlserver/2008/r2/fact/seminar.mspx


税制関係の話だけかな、それだとこの時間もひっぱるのは難しいのでは？ということはそれだけ税制がらみで深い話でもあるのかな？と思っていた。
しかし、税制の話はほんのちょっと。どちらかというとSQL Server 2008ならではの機能などで特に協調したい点や、移行についての実践経験の話であった。正直、裏切られた。いい意味で、だけれど。

2000から2005への移行ではコードをスクラップ＆ビルドくらいに変えたらしいが、2008は2005ベースで改善を加えていったそうだ。ということで、2005のSP1のバグフィックスと、2008のSP1のバグフィックスでは雲泥の差がある、とのことであった。確かに、2005のときは「サービスパックで機能を追加するってナニゴトですか？」と思ったものだった。システムが安定するのは運用にも携わる者としては有り難いことである。
パフォーマンスもどんどんよくなっているそうである。圧縮の機能は知っていたが、パフォーマンスに影響がそこまであるとは・・。仕事場に持ち帰って試してみたい。


最後にレポートの機能を紹介していた。レポーティングが簡単にできるというウリであったが、これはこれでいい。概念説明５分、デモ５分で十分に伝わった。
ただ、私はそのときに例として挙げられていた監査の機能の方が興味深かった。

次回も時間が許せばだが、参加したいなと思う。


ちなみに、今回の話を聞いた後、猛烈にSQL Server 2008R2 のDeveloper Edition が欲しくなった。



SQL Server 2008 R2 Developer 日本語版/マイクロソフト

￥9,240
Amazon.co.jp

  • なうで紹介
  • mixiチェック
  • ツイートする

編集者: ぽせい丼 | このブログのURL |この記事のURL

2011年01月13日

libpqxx で parameterized query

db1=> select * from northwind_product ;
 id  |  prod_name   | unit_price |    memo
-----+--------------+------------+------------
 502 | 乾燥ナシ     |       2930 |
 101 | 長粒米       |        690 | あいうえお
 501 | シロップ     |        980 | あいうえお
 503 | 唐辛子ソース |       2060 | あいうえお
(4 rows)

$ cat pg3.cpp
#include 
#include 

using namespace std;
using namespace pqxx;

int main() {
    connection conn("host=192.168.24.53 dbname=db1 user=suzuki");
    transaction<> tran(conn, "my tran");
    const string sql = "SELECT * FROM public.northwind_product WHERE id > $1 AND memo = $2";
    conn.prepare("my sql", sql)
        ("integer", prepare::treat_direct)
        ("varchar", prepare::treat_string);
    result rs  = tran.prepared("my sql")(500)("あいうえお").exec();
    for (result::const_iterator i = rs.begin(); i != rs.end(); i++) {
        cout << i["id"] << ", " << i["prod_name"] << ", " << i["unit_price"] << ", " << i["memo"] << endl;
    }
    return 0;
}

$ g++44 pg3.cpp -o pg3 -Wall -lpqxx
$ ./pg3
501, シロップ, 980, あいうえお
503, 唐辛子ソース, 2060, あいうえお

transaction<> の代わりに nontransaction を使うと BEGIN と ROLLBACK が発行されない。

こういうの試すと、ADO.NET と SQL Server が恋しくなる。


編集者: aspplus | このブログのURL |この記事のURL
   前のページへ   次のページへ

エンジニアが作る最新ITブログ トップ>エンジニアの発信する【その他DBMS】

カテゴリー

メンバー紹介

【 メンバー 】
・okazspider
・こんぶ
・ぽせい丼
・ZARU
・gaseidou2
・もじらa-chan
・松
・鯖缶
・遊楽庵
・玖白　(Kuhaku)
メンバー全てを見る

アーカイブ

リンク

タグパネル

ランキング

最新の情報をお届け！


rss
Asp・PHP・Vb・Javascript・oracle・ mysqlなど、エンジニア必須技術の最新情報や、あなたの技術をより磨くためのお役立ち情報が満載です。
Copyright (c) 2007 INTELLIGENCE, Ltd. All Rights Reserved.
エンジニアが作る最新ITブログ DODA