「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
CDB.php <?php /* Constant DataBase 読み取り専用ライブラリ http://search.cpan.org/dist/CDB_Perl/ からReadだけ移植 2008/01/20 */ class CDB { var $fh; var $iter_key, $iter_hash ,$iter_tnum ,$iter_pos; function CDB ( $filename ){ $this->fh = fopen($filename, "rb"); } function get_value( $key ){ $this->iter_key = $key; $this->hash($key); return $this->get_next(); } function hash ( $key ) { $h = 5381; $p = unpack("C*",$
Berkeley DBを使って作ったアプリが、なんか調子が悪いということで、ここ数日ハマってました。テストデータを投入しても再現しないので、データベースファイルを疑って調査。 db_verifyコマンドでデータベースファイルを調べてみるとエラーが出る。 $ db_verify data db_verify: Page 0: page 3 encountered a second time on free list db_verify: DB->verify: data: DB_VERIFY_BAD: Database verification failed 復旧させるには、db_dumpでダンプして、db_loadでリストア。 $ mv data data.old $ db_dump data.old | db_load data Berkeley DBと言えばSubversionとかMo
昨日さんざん悩まされたOutOfMemoryは単純なコーディングミスorz べつのソースからコピってきたルーチンがまずかった。 とーいうわけで無事GDBMにハッシュを関連付けて処理を走らせて見る ぉーリソース4kbyteしか使ってない、こりゃいいな。 ・・・・落ちたーっ！アッー！ 突然128000レコードすぎたところでぶっつりコアダンプはきだして死亡。 死に方がもうPerlとかが原因じゃなさそうな落ち方をする。 こっから長い1日がはじまる、まず何回か走らせて見るすると毎回同じレコードで死んでいる。 しばらくするとコアダンプを吐くかわりにlseekがエラーだょっ！って言われる。 これはたぶん根が深い、lseekシステムコールで死んでるのは確定。 もっと注目してみるとファイルサイズが2Gを超えると落ちている、 決め手はこのレスでたぶんFA off_t under Linux use only
ディスク上のテーブルデータのストレージ要件は、複数の要因によって異なります。 別々のストレージエンジンは異なる方法でデータ型を表し、ローデータを格納します。 カラムか行全体のどちらかでテーブルデータを圧縮できますが、テーブルまたはカラムのストレージ要件の計算が複雑になります。 ディスク上のストレージレイアウトが違っていても、テーブル行に関する情報を通信および交換する内部 MySQL API は、すべてのストレージエンジンにわたって適用される一貫したデータ構造を使用します。 このセクションでは、データ型の固定サイズ表現を使用するストレージエンジンの内部形式およびサイズを含め、MySQL がサポートするデータ型ごとのストレージ要件に関するガイドラインおよび情報について説明します。 情報はカテゴリまたはストレージエンジンごとに示します。 テーブルの内部表現の最大行サイズは 65,535 バイトで
MyISAM テーブルが可変長カラムを含んでいる場合 (VARCHAR、VARBINARY、BLOB、または TEXT)、またはテーブルが ROW_FORMAT=DYNAMIC テーブルオプションで作成された場合は、動的ストレージフォーマットが使用されます。 動的フォーマットは、それぞれの行に行の長さを示すヘッダーがあるため、静的フォーマットよりも少し複雑です。 更新の結果として行が長くなった場合、行がフラグメント化される可能性があります (非連続的な断片で格納されます)。 OPTIMIZE TABLE または myisamchk -r を使用して、テーブルをデフラグできます。 可変長カラムも含んだテーブルで、固定長カラムに頻繁にアクセスしたり変更したりする場合、可変長カラムを他のテーブルに移動して、フラグメンテーションを回避する方法が良い場合があります。 動的フォーマットのテーブルには、
http://www.mysql-ucj2007.jp/details/j25.html 木下 靖文 氏 NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ （「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました） InnoDBをなぜ使うか トランザクション コミット、ロールバック、セーブポイント 外部キー 行レベルロック オンラインバックアップ クラッシュリカバリ クラッシュリカバリ MyISAMはデータ量の増大とともに時間がかかる InnoDBはデータ量の増大との相関がない InnoDBチューニングの王道的アプローチ クエリを改善して全体的に処理効率を上げる データサイズをできるだけ小さく メモリをできるだけ多く積む コミット性能（同期書き込み） innodb_flush_log_at_trx_commit=1,0,2
ポイント ・高度なインデックスやジョインを利用し，最短経路でデータにアクセス ・メモリー不足を自律的に解消し，キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し，高速化を図る 目的地に早く到着したいなら，最短の経路を最速で行けばよい。これはデータベース（DB）でも同様だ（図1）。インデックスなどを使ってデータへの最短経路を見つけ，メモリー・アクセスを増やして，最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では，（1）データにたどり着く最短の道を選ぶ仕組みと，（2）アクセスのスピードを上げる仕組みの
Contents 更新:2007/08/31 MySQL内部アーキテクチャとソース解析 モジュールと相関図 主要クラスと構造体 ユーティリティ関数 プリプロセッサマクロ グローバル変数 ストレージエンジンインタフェース MySQL Hacking Tips InnoDB関連のソース解析 InnoDB起動プロセス InnoDBバッファプールに関するソースコメントの和訳 InnoDB Record構造 MySQLの拡張 可変引数を持つNativeなSQL関数の実装方法 WarningとErrorの出力方法 HelloWorldネタ GNU AutotoolsでHello World! その他 サンプルコード集 当サイトと管理者について
XMLデータベース（以下、XMLDB）とはXML形式の情報をXMLのまま保存、検索、出力することができるデータベースのことです。本連載では、オープンソースのXMLDBである「eXist」を題材として、まずはXMLDBそのものを簡単に試せるよう、インストールから簡単なサンプルを実際に作成できるところまでを紹介します。 皆さんも、XMLにはほとんどの方が何らかの形で触れられていると思いますが、ことXMLDBとなると「XMLDB？ うーん、ちょっと敷居が高いんだよね……！」とお考えの方が、まだまだ多いのではないでしょうか。 その「敷居の高さ」とは、何が原因なのでしょうか。そこで、筆者がかつて感じていた「XMLDBに触らなかった理由」を改めて考えてみました。 これまでXMLにそれほど親しんでこなかった筆者は、XMLというツリー構造のデータをみたとき、どのようにして情報を整理してよいのか、その設計の
Jaslabs: High performance phpで紹介された「MySQLのクエリを最適化する10のTips」に対して、反論している人がいる。ブログ「20bits」のJesse氏だ。彼は「10 Tips for Optimizing MySQL Queries (That don’t suck)」というエントリーで、Jaslabs氏の記事は適切でないとしている。 Jesse氏の経験によれば、SQL最適化で最も重要なことはSQLやDBの基本をしっかりと理解することであり、60％がこれで解決するという。残り35％はDBやクエリの特殊な性質に対する対処であり、最後の5％で発想の転換などを求められる。Jaslabs氏はここにばかり力を入れており、それはまったくもって時間の無駄だと述べている（Jesse氏は「SQL_SMALL_RESULTなんて、生まれてこの方使ったことすらない」とまで言
http://martinfowler.com/bliki/Transactionless.html 2007/3/18 (更新：Bill Caputoからも経験談をいただいた) 数年前にeBayで働く友人たちと話していたときのことだ。 大規模サイトで使われる技術の話を聞くのはいつも楽しいが、特に興味深かったのが、eBayでは滅多にデータベーストランザクションを使用しないという話だった。 トランザクションがない環境というのは驚くべきことではないだろうか。 データベースを扱うときにトランザクションを使うのはごくごく一般的なことだ。 多くの人にとって（私もそうだが）トランザクションはデータベースを使う利点のひとつだ。 eBayがトランザクションを使わないのは、あのような規模ではパフォーマンスに影響が出てしまうからだというものだった。 eBayではデータをいくつもの物理的データベースにパーテショ
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
