タグ

databaseに関するdeeekiのブックマーク (59)

  • MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLの DATETIME型は本当に遅いのか検証してみた - 2010-04-30 - 小野マトペの業務日誌(アニメ制作してない篇)

    バグの話 近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。 バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。 以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。 select date from STATUS force index(date) where date='2010-01-19' limit 10; この現象は、5.5.3,5

    MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLの DATETIME型は本当に遅いのか検証してみた - 2010-04-30 - 小野マトペの業務日誌(アニメ制作してない篇)
  • なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − @IT

    ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1~5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture

  • Loading...

  • @IT:Amazon RDSの使い方(1/3)

    オープンソースのRDBMySQL」をクラウド上で利用し、ニーズに応じて簡単にインスタンスを増やせる「Amazon RDS」(Amazon Relational Database Service)。その特徴と使い方をご紹介します。(編集部) TIS株式会社 SonicGarden 並河 祐貴 2010/4/12 Amazon Web Servicesのニューフェイス 大手パブリッククラウドサービスの1つであるAmazon Web Servicesは、2009年以降も続々と新しいサービスや機能を発表し、日でもますます注目を集める存在となっています。 Amazon Web Servicesは、仮想サーバを1時間単位の従量制で利用できるAmazon EC2や、1GB単位からの従量制ながら、高信頼性のオンラインストレージが利用できるAmazon S3などを中心とした、IaaS(Infrastru

  • Song of Cloud: 送金のトランザクション処理パターン

    App Engineで現実的な送金処理について考え中です。 ドラフト版なので、怪しい点があればご指摘いただければ幸いです。 コメントで情報いただきました。 Distributed Transactions on App Engineで紹介されてる方法と基的に同じなので、おそらく問題なく動きそうです。ありがとうございました。 今回はこんな図を使います。 この図の読み方は、矢印の方向にユースケースの一連の処理(またはリクエストの処理)が流れていて、右に行くほど時間が経過しています。そして、矢印がくし刺しにしている四角形は、そのユースケース中で操作するエンティティを表しています。 また、左右の位置が同じ矢印は、基的には同じ時刻に発生したイベントを表しています。上記の図では、A, B, Cがそれぞれの口座エンティティを同時に操作している感じです。 並行性制御(おさらい) 最初の図のように、それ

  • 正しいベンチマークをするための10のポイント

    世の中ではたくさんの人が独自にベンチマークを行ない、独自に情報発信がされています。そのベンチマークの中には、非常に参考になるものもあれば、現実性に大きく欠けるものもあります。競合他社が、ライバル社の製品にとって不利な条件でベンチマークを行い、それを発信することも日常的に行われています。ベンチマークの結果を鵜呑みにすることは危険で、結果の意味を判断するスキルを持つことが重要です。これはプロジェクトにおいて負荷テストを行う場合にも重要です。負荷テストの条件設定が正しいかどうかを判断できるようになるためです。 ここでは、私がDBサーバのベンチマーク/負荷テストを行ったり結果を読んだりする上で、心がけているポイントを10個ほど紹介したいと思います。 ■ハードウェアに関する4つのポイント 1. ハードウェアのスペックと設定を注視する ハードウェア構成によってベンチマーク結果は劇的に変わるので、言わず

  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

    InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い(テーブルの行数を保持してる)のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ

    漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
  • macminiosx.com

    This domain was recently registered at Namecheap.com. Please check back later! macminiosx.com 2021 著作権. 不許複製 The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois

    macminiosx.com
  • これだけは覚えておきたい!!MySQL の6つの自動変換 - sakaikの日々雑感~(T)編

    MySQLはとても気ぃつかい屋さんである。我々が投げる多少あいまいな指示も頑張って解釈し、なんとか文句を言わずに実行してみようと挑戦してみてくれる。 今日はそんなMySQLがケナゲに解釈してくれる自動変換について紹介しようと思う。この自動変換、ケナゲなMySQLの奥ゆかしさ故、出した指示と異なる動作をされたことに気がつかないことがある。ここで紹介する6つの自動変換をしっかり脳ミソにたたき込んでおけば、無用なトラブルにハマる時間も減るかもしれない。 1.[数値] 範囲外の数値は頭を押さえつけられる intやsmallint、bigintなどの数値型には、扱える範囲が決まっている。例えばint型なら最大21億ちょっとだ(unsignedの場合は43億弱)。これより大きい数字を登録するよう指示を出すとMySQLはどうするか。そう、頑張って入れられるところまで入れてくれるのである。「入れられるとこ

    これだけは覚えておきたい!!MySQL の6つの自動変換 - sakaikの日々雑感~(T)編
  • MySQL管理者最速マスター

    巷ではプログラミング言語の最速マスターが流行ってるので、MySQLも参戦。ただし管理者向け。 まずはダウンロードとインストールダウンロードサイト http://dev.mysql.com/downloads/ バイナリにはインストールパッケージ(Windows=MSI、Mac=DMG、Linux=RPMとか)とアーカイブ(*NIX=tar.gz/Windows=zip)があるけど、初心者は黙ってパッケージをチョイス。インストールはウィザードに従うだけ。英語だけどそこはガマン! パッケージリポジトリがあるOSを使ってるなら、リポジトリからインストールするのもありだ。例えば、 shell> sudo yum install mysqlとか shell$gt; sudo apt-get install mysqlとか。これは楽チンだけどMySQLのバージョンがちょっと古くなるので注意。 もちろん

    MySQL管理者最速マスター
  • SQLインジェクションとは何か?その正体とクラッキング対策。

    世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクションの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されているにも係わらず、その質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。 というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。 SQLイン

    SQLインジェクションとは何か?その正体とクラッキング対策。
  • ハイウォータマーク - オラクル・Oracleをマスターするための基本と仕組み

    ハイウォータマークとは ハイウォータマークとは、テーブルスペースやセグメント (テーブルなどのスキーマ・オブジェクト) ごとに設置される指標である。 HWM と略して書かれることもある。 .. High-Water Mark ⇔ (川などにある目盛りのある白い棒)高水位標 特徴 現在までに最高で、どこまで使用済になったことがあるかをあらわす。 「使用済」の最終ブロックの位置を指す。 HWM が表の獲得している領域の最大値を超えると新しいエクステントを調達する。 SQL の DELETE では HWM は下降しない。 TRUNCATE TABLE(DDL) は HWM をリセットする。 データの削除をともなわない HWM の縮退操作は ALTER TABLE にて行なう。 ⇒ ハイウォータマークの操作方法

  • MySQLerのTwitterアカウントまとめ。

    松信氏の、 MyISAMとInnoDBのどちらを使うべきか Twitterで話題になってたので簡単にまとめました。 というエントリが人気を博しているが、松信氏が言うように最近はTwitterMySQL関連の話題も結構増えてきているように思う。Twitterの流行の勢いは凄まじく、今は右を向いても左を向いてもTwitter、寝ても覚めてもTwitterも杓子もTwitterという雰囲気である。従ってMySQLTwitterで盛り上がるのは当然の成り行きというもであるし、Twitterを活用しない手はない。 しかしMySQL関連の話で盛り上がると言っても「じゃあ誰をフォローすれば話に入れるんだよ?!」と多くの皆さんは疑問に思われることだろう。そこで、今日はMySQL関連のTwitterアカウントを独断と偏見と愛と勇気と努力をもって紹介する。MySQLの情報が欲しい人、もしくは話題の輪に

    MySQLerのTwitterアカウントまとめ。
  • MyISAMとInnoDBのどちらを使うべきか

    Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL

  • なんちゃって個人情報

    なんちゃって個人情報は「Generator of the Year」にて【便利賞】を受賞いたしました!! 投票して下さったみなさま、当にありがとうございました。 今後もどんどん使ってやって下さい。 プログラム等に使えるかもしれない個人情報のテスト用データを作成できます。特に説明が必要なものでもないので、とりあえずやってみていただければわかると思います。 念の為書いておきますが、生成した偽個人情報により発生したいかなる損害も当方は一切関知しません。たまたま名前が実在の人物と同姓同名になってしまうかもしれませんし、特に電話番号や携帯については実際に使われている番号と重なることがありますから、扱いには十分注意して下さい。 何かご要望とかありましたらお気軽にブログまでコメント下さい。 HTML シンプルなHTMLのテーブルで出力します。 XML ルートを<records>、各レコードを<reco

  • 【CakePHP】お手軽便利なCakeSchema | ECWorks Blog

    DBのテーブル設定は非常に面倒な作業の一つです。 特に、開発時は仕様変更などでテーブル内のフィールドが頻繁に増減することもあるかもしれません。 テーブルを作成したり、更新したりするのに、皆さんはどのような手順を踏まれるでしょうか?まずSQLを書いて、アップロードして、mysqlやpsqlのコンソールを使って実行していますでしょうか?それとも、mysqladminとかのguiツールを使っていますでしょうか? CakePHPには、schemaシェルが付属されていて、これを用いることで簡単にテーブルを初期化することができます。コマンドラインからコマンド一発で(実際には確認メッセージがあるのでy/n選択がありますが)、書き換わるので大変に便利です。 ただ、ドキュメントや情報が公開されているブログなどが少ないため、どのように記述して良いか分からない方も多いかと思います。そこで、簡単に使い方を解説し、

  • データベース負荷テストツールまとめ(1) - SH2の日記

    Webシステム開発において性能試験を行う場合、hp LoadRunnerやApache JMeterといったウェブブラウザをエミュレーションしてくれる負荷テストツールを用いるのが定番だと思います。そんななか、たまにデータベース単体での性能を測ってほしいと頼まれることがあるので、そうした便利なツールはあるのかなと思って調べてみました。 データベースに対する負荷テストツールは探すとたくさん出てくるのですが、案件で使用しているRDBMSに対応していなかったり、トランザクション仕様が希望と異なっていたり、微妙に作りが悪かったりと、ニーズに合致したツールはすぐには見つかりません。そんなときにこのエントリがツール探しの参考になればと思います。 pgbench 対応RDBMS:PostgreSQL 対応OS:Linuxなど 言語:C 作者:石井達夫氏 ライセンス:独自(BSDライセンスに近い) トランザ

    データベース負荷テストツールまとめ(1) - SH2の日記
  • EC-CUBE工房

    EC-CUBE工房はEC-CUBEと共に歴史を歩んできたEC-CUBE改造専門店です。ショップオーナー様がかかえる様々なお悩みをその豊富な経験と知識で解決に導きます。

    EC-CUBE工房
  • ウノウラボ Unoh Labs: RDBで階層構造を扱うには?

    yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには?」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま

  • データベースを用いたセッションデータ管理について - LukeSilvia’s diary

    Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ

    データベースを用いたセッションデータ管理について - LukeSilvia’s diary