パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
OSSピックアップ - データベースエンジン/サーバー編 | OSDN Magazine
「OSSピックアップ」は、世界最大のオープンソースソフトウェア情報サイト「freashmeat.net」に掲載されているオープンソースソフトウェアから、人気のあるものや最近注目を浴びているものをピックアップして紹介する企画である。今回はデータベースエンジン/サーバーとして分類されているオープンソースソフトウェアから注目のものを紹介する。 定番のデータベースエンジン「PostgreSQL」 PostgreSQLは20年以上の歴史を持ち、すべてのメジャーなOSで動作する、安定したリレーショナルデータベースシステム（RDMS）である。 PostgreSQLはACID（アトミック性/一貫性/独立性/永続性の頭文字を取った頭字語であり、トランザクション処理を行う際に必須の機能）を備えており、外部キー（foreign keys）や表結合（joins）、ビュー、トリガー、ストアドプロシージャといった、機
データベースのスケーラビリティをどうやって向上させるか
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった
Facebookが15日に発表した新しいサービス「Facebook Messages」は、チャットやつぶやき、そして電子メールなど、自分宛のテキストやメッセージをすべて1つのインボックスで管理できると発表されました。 同社が15カ月かけて開発してきたこの新サービスのバックエンドデータベースは、これまで同社が大規模運用してきたMySQLでも、同社が開発したNoSQLデータベースのCassandraでもなく、グーグルのBigTableをモデルとしてオープンソースで開発された分散データベース「HBase」でした。 Facebookのソフトウェアエンジニア、Kannan Muthukkaruppan氏がFacebookにポストした記事「The Underlying Technology of Messages」で、その技術的背景が紹介されています。 MySQLとCassandraが落選した理由 H
ソーシャルゲームのためのデータベース設計 まとめ - お笑いプログラマの技術メモ
ソーシャルゲームを作る時に参考になるデータベースやKVSの選定、設計などの記事やスライドのまとめ 2013-02-03追記 スライド ソーシャルゲームのためのデータベース設計 http://www.slideshare.net/matsunobu/ss-6584540 とあるアプリの開発運用(トラブルシュート) http://www.slideshare.net/takafumionaka/ss-5852561 PHPで大規模ブラウザゲームを開発してわかったこと http://www.slideshare.net/ketaiorg/php-4638298 Lampで作るソーシャルアプリの負荷対策〜アプリとインフラの調和のテクニック〜 (Klabさん) http://www.slideshare.net/klab/4-d6963726f736f667420506f776572506f696e
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」：ITpro
ミクシィの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を作りたいと提案したところ認められたという。同氏が
RDBMSをブラックボックスにしない：ITpro
複数トランザクションの同時実行編 トランザクションが複数同時に実行される時，RDBMSはどのような仕組みで，それぞれのトランザクションの独立性を保つのかを説明します。これを理解することにより，さらに良いトランザクション処理のアプリケーションを開発することができるようになります。 目次 第1回 ほかのトランザクションからの影響 第2回 1番ゆるい分離レベル（リードアンコミッティド） 第3回 2番目にゆるい分離レベル（リードコミッティド） 第4回 3番目にゆるい分離レベル（リピータブルリード） 第5回 1番きつい分離レベル（シリアライザブル） 更新処理とトランザクション編 「RDBMSの更新処理とトランザクションの関係は難しい」――。こう思っている読者の方は少なくないでしょう。アプリケーションを開発するだけなら，更新処理とトランザクションの関係をきちんと理解していなくても，「見よう見まね」の開
SQLの都市伝説。マイケル・ストーンブレイカー御大が斬る！
データベース研究者の大御所、マイケル・ストーンブレイカー氏が、「SQL URBAN MYTHS」（SQL都市伝説）というWebセミナーを、自身が創設した会社VoltDBで公開しています。 一般にリレーショナルデータベースに対して言われている「SQLは遅すぎる、トランザクションのコストは高すぎる」といった評価について、SQLが遅いのではないし、トランザクション以外のコストが高すぎるのだ、と反論する内容。 これらは同氏が以前から主張してきた内容ではありますが、最近流行しているNoSQLデータベースに対する反論にもなっているため、多くのエンジニアに刺激になる内容となっています。 SQLに関する6つの都市伝説 都市伝説1：SQLは遅すぎる。NoSQLのような低レベルなインターフェイスを使うべき 都市伝説2：キーバリュー型が有望で、SQLは問題外 都市伝説3：SQLデータベースはスケーラブルではない
第4回 スキーマレスで柔軟に扱えるMongoDB | gihyo.jp
はじめに 今回はドキュメント指向型データベースの代表としてMongoDBを取り上げます。ドキュメント指向型データベースはRDBMSと違って、スキーマ（テーブル定義）が必要ないことが大きな特徴です。 今回も利用したコードやプログラムはgithubに置いてあるので適宜参照してください。 MongoDBの特徴 前々回、前回と紹介したmemcachedやTokyoTyrantは基本的にRDBMSと組み合わせて、「RDBMSの弱い部分を補う」という使い方でした。しかしMongoDBは少し違っていて、JOINが行えないこととトランザクションをサポートしていないこと以外は、ほぼRDBMSと同じように扱うことができるため、「RDBMSの代替として使う」ことが可能です。 上述したようにMongoDBはRDBMSと違ってJOINはできませんが、代わりに基準となるオブジェクトに別のオブジェクトをあらかじめe
今夜こそわかる安全なSQLの呼び出し方 ～ 高木浩光氏に聞いてみた
「安全なSQLの呼び出し方」というSQLのセキュリティに焦点を当てたドキュメントが、2010年3月にIPA（独立行政法人情報処理推進機構）から公開された。 これは2006年1月から提供されている、Webサイト開発者や運営者向けのセキュアWebサイト構築のための資料「安全なウェブサイトの作り方」の別冊として書かれたものである。「安全なウェブサイトの作り方」が92ページなのに対して、SQLインジェクションについてだけで40ページもの分量がある。なぜこんなに分厚いのだろうか。 このドキュメント作成に協力したという、独立行政法人産業技術総合研究所 情報セキュリティ研究センターの高木浩光氏にお話を伺うことができた。高木氏は個人ブログ「高木浩光＠自宅の日記」で、セキュリティ関連の問題を追求する論客としても知られている。筆者も以前、この連載の「今夜わかるSQLインジェクション対策」の回（2006年11月
HDDをSSDにしたらデータベースはどれだけ速くなるか？ オラクルと富士通が実験
リレーショナルデータベースを利用する際には、高い性能を引き出すために物理設計をし、スキーマを工夫し、パラメータのチューニングを行うことがつねに行われてきました。 性能のボトルネックはたいがいHDDにあり、いかにそのボトルネックを回避するかがチューニングのポイントですが、最近では性能向上のための武器として、HDDよりもずっとアクセス性能の高いSSDが注目されています。SSDはHDDと置き換えるだけで、アプリケーションにまったく手を加えずに性能向上を可能にする手段として非常に魅力的です。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか？ オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました（参考「日本オラクルと富士通 フラッシュ技術活用によるデータベース高速化を共同検証」）。 ホワイトペーパーでは、HDDの代わり
SQL is obsolute. | 独り言v6
キャッチーなタイトルを付けるのは難しいな、と思いつつASTのLinux isキャッチーなタイトルを付けるのは難しいな、と思いつつASTの”Linux is obsolete”をぱくって見る。 もうSQLと出会ってからすでに10年近くが経過している。非常に良くできたもので、知れば知るほど感心したものである。が、同時に業界の変化から取り残されていき、ダメになっているなと思われる部分もいっぱいある。ここに書かれているようなのは、もう昔から言われているようなことばかりだが、L.starなりに実体験をふまえてまとめてみた。 論理構造しか記述できないこと SQLは、論理的に以下にデータを取り出すか、と言うことに着目して記述する言語である。これはデータのやりとりの記述を実にシンプルにした、という利点がある。代わりに、実際の検索に必要な物理的な部分はプランナにより、自動的に最適化されるというのが売りである
京都収納棚：DBMの率直な壱実装 - mixi engineer blog
飲み屋に行くとかなりの確率で荷物を忘れて帰るmikioです。さて、今回はここ2ヶ月ほどで急ピッチで開発した軽量データベースライブラリ「Kyoto Cabinet」について紹介します。 開発の動機 以前から軽量データベースライブラリとしてご好評いただいているTokyo Cabinetですが、DBMとして必要十分な機能と性能を備えていてなかなか良いものだと自負しております。ただ、開発を進める中でいくつか不満な点があったのも事実です。端的に言えば、全てC言語で記述して、標準ライブラリ（とzlib/bzip2）以外の機能は全て自作しているので、最適化がしやすい反面、メンテナンスの難易度が高くなってしまっているというのが不満です。 そこで、多少性能が悪くなってもいいから、私自身としてお気楽に開発およびメンテナンスができて、移植性も高いような実装を作ってみようと思い立ったのが昨年10月頃。様々な検討を
キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると
2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか？ 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ
性能検証！インメモリDB
インメモリDBを知る 「第2回：検証！RACの耐障害性と拡張性（http://www.thinkit.co.jp/article/96/2/）」では、Oracle Real Application Clusters（以下RAC）の耐障害性と拡張性を有効に活用する手法について触れ、最後にパフォーマンス向上のために考慮すべき点をご紹介しました。 しかしそれらを考慮したとしても、オンライン証券など高トランザクションを求められるシステムでは、ディスク型RDBMSで対応することには限界があります。そこで今回は最近注目を集めているインメモリDBを取り上げ、どのように高トランザクションシステムを処理していけるのかを紹介します。 最近インメモリDBという言葉を聞く機会が徐々に増えてきました。大手ベンダだけでもTimesTenを買収したOracle社、solidDBを買収したIBM社、自社製品を開発している
インメモリデータベースがクラウド時代の主流になるという期待
クラウドの伝道師といえるほど熱心にクラウド関係の講演や執筆を行っている早稲田大学 丸山不二夫教授は、クラウドの技術的な発展について次のような見通しを、UNIX magazine 2009 springの37ページに書いています。 筆者は、データのパーシステンシの担い手が、ディスク上のファイルシステムからメモリに移ろうとしていることが、クラウドシステムの技術的な発展方向だと考えている。 僕は今年の1月の丸山氏が登壇したセミナーでこの考えをはじめて聞いたとき、ハッとしました。 クラウドのアーキテクチャでは、クラウドを構成するいずれかのマシンが故障しても大丈夫なように高い冗長性が保証されています。それだけ高い耐障害性を備えているなら、データの永続性を保つためにデータをメモリに置いたままでいいではないか、という斬新かつクラウドのアーキテクチャに沿った考え方に感銘を受けたためです。 実際に長期にわた
第7回 性能改善の鍵、インデックスの特性を知る～B-treeとハッシュ （3）結論 | gihyo.jp
総評 以上、B-treeとハッシュという代表的なパフォーマンスチューニングのアルゴリズムについて見てきました。どちらの技術を採用するかは、業務要件に依存するところが大きいのですが、ここで目安として一般的な結論も述べておきましょう。 結論1：とりあえずB-treeインデックスを使って大敗することはない。 B-treeはバランスのとれたオールラウンダーですので、だいたいどんな要件にもそこそこ対応します。安心して使ってください。 一方、ハッシュについての結論は、こうです。 結論2：等値条件で性能を追求したいならハッシュを使いなさい。ただし大敗も覚悟しなさい。 ハッシュが効果を発揮するのは、等値条件（=）のときだけです。また、ソート処理の助けにもなりません。したがって、使う局面は非常に限られてきます。PostgreSQLのように、マニュアルに「ハッシュインデックスの使用は推奨しない」とはっきり書い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DBスキーマもバージョン管理したい！
JAPAN INNOVATION LEADERS SUMMIT 2011 - Ｔｅｃｈ総研
What is the next to SQL? | 独り言v6