タグ

dbに関するtanarkyのブックマーク (20)

  • ウェブリブログ:サービスは終了しました。

    「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧

    ウェブリブログ:サービスは終了しました。
  • cdbを読み込むライブラリ - ぐでの日記

    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*",$

    cdbを読み込むライブラリ - ぐでの日記
  • Berkeley DB壊れた→復旧 - BitArts Blog

    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

    Berkeley DB壊れた→復旧 - BitArts Blog
  • ガメオベラ 怪傑熟男

    昨日さんざん悩まされたOutOfMemoryは単純なコーディングミスorz べつのソースからコピってきたルーチンがまずかった。 とーいうわけで無事GDBMにハッシュを関連付けて処理を走らせて見る ぉーリソース4kbyteしか使ってない、こりゃいいな。 ・・・・落ちたーっ!アッー! 突然128000レコードすぎたところでぶっつりコアダンプはきだして死亡。 死に方がもうPerlとかが原因じゃなさそうな落ち方をする。 こっから長い1日がはじまる、まず何回か走らせて見るすると毎回同じレコードで死んでいる。 しばらくするとコアダンプを吐くかわりにlseekがエラーだょっ!って言われる。 これはたぶん根が深い、lseekシステムコールで死んでるのは確定。 もっと注目してみるとファイルサイズが2Gを超えると落ちている、 決め手はこのレスでたぶんFA off_t under Linux use only

  • 株式会社ロックオン社員ブログ | 大阪市北区に本社を置く、ベンチャー企業株式会社ロックオン!「アドエビス」「EC-CUBE」「THREe」など、多くのNo.1製品を輩出する会社の裏側をお見せします。

    大阪市北区に社を置く、ベンチャー企業株式会社ロックオン!「アドエビス」「EC-CUBE」「THREe」など、多くのNo.1製品を輩出する会社の裏側をお見せします。

    株式会社ロックオン社員ブログ | 大阪市北区に本社を置く、ベンチャー企業株式会社ロックオン!「アドエビス」「EC-CUBE」「THREe」など、多くのNo.1製品を輩出する会社の裏側をお見せします。
    tanarky
    tanarky 2008/03/19
  • 株式会社スタイルズ

    AWSアドバンスドコンサルティングパートナーの一員として活動する株式会社スタイルズが、AWS導入、移行、開発、セキュリティ、運用保守など、すべてのご相談に乗らせていただきます。 AWSを導入したいが何から始めたらいいかわからない 既存のベンダーが新技術に弱く、良い提案がもらえない クラウドの導入にセキュリティの不安がある AWSをとりあえず導入したが、さらに活用していきたい 社内にAWSの知見を持っている人がいない AWSならではのシステム開発を詳しく知りたい

    株式会社スタイルズ
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.7 データ型のストレージ要件

    ディスク上のテーブルデータのストレージ要件は、複数の要因によって異なります。 別々のストレージエンジンは異なる方法でデータ型を表し、ローデータを格納します。 カラムか行全体のどちらかでテーブルデータを圧縮できますが、テーブルまたはカラムのストレージ要件の計算が複雑になります。 ディスク上のストレージレイアウトが違っていても、テーブル行に関する情報を通信および交換する内部 MySQL API は、すべてのストレージエンジンにわたって適用される一貫したデータ構造を使用します。 このセクションでは、データ型の固定サイズ表現を使用するストレージエンジンの内部形式およびサイズを含め、MySQL がサポートするデータ型ごとのストレージ要件に関するガイドラインおよび情報について説明します。 情報はカテゴリまたはストレージエンジンごとに示します。 テーブルの内部表現の最大行サイズは 65,535 バイトで

  • MySQL :: MySQL 4.1 リファレンスマニュアル :: 5.2.13 その他の最適化のヒント

    This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.

  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 16.2.3.2 動的テーブルの特徴

    MyISAM テーブルが可変長カラムを含んでいる場合 (VARCHAR、VARBINARY、BLOB、または TEXT)、またはテーブルが ROW_FORMAT=DYNAMIC テーブルオプションで作成された場合は、動的ストレージフォーマットが使用されます。 動的フォーマットは、それぞれの行に行の長さを示すヘッダーがあるため、静的フォーマットよりも少し複雑です。 更新の結果として行が長くなった場合、行がフラグメント化される可能性があります (非連続的な断片で格納されます)。 OPTIMIZE TABLE または myisamchk -r を使用して、テーブルをデフラグできます。 可変長カラムも含んだテーブルで、固定長カラムに頻繁にアクセスしたり変更したりする場合、可変長カラムを他のテーブルに移動して、フラグメンテーションを回避する方法が良い場合があります。 動的フォーマットのテーブルには、

  • Kazuho@Cybozu Labs: Perl から MySQL に非同期アクセスする方法

    « サーバシグニチャは隠さないのが当たり前 | メイン | swifty-0.02 と Perl バインディング » 2007年09月10日 Perl から MySQL に非同期アクセスする方法 mod_perl のプロセス内でやるのに POE でイベントループ回せ、ということ? もうちょいkwsk! > b:id:kazuhooku naoyaグループ - naoyaの日記 - 非同期SQLサーバ エントリ全体の趣旨はさておき、ソケット通信を非同期化するためにまた別のソケット通信を行うという使用例に違和感を覚えたのですが、回避策としてブクマコメントで提示した POE::Component::EasyDBI も内部で fork (&プロセス間通信) してるんですね。変なコメントしてごめんなさい忘れてください。って、それだけではなんなので... ここから題。 私はそういうケースに遭遇したこ

  • InnoDB のパフォーマンスチューニング - MySQLカンファレンス2007 - akiyan.com 管理人メモ

    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

    InnoDB のパフォーマンスチューニング - MySQLカンファレンス2007 - akiyan.com 管理人メモ
  • 現場指向のレプリケーション詳説

    この文書は、技術評論社刊『WEB+DB PRESS Vol.22』に執筆した記事を技術評論社の 許可を得てWWWで公開しているものです。 このWWW版は校正前の原稿を元にしている点、WWW公開後に必要があれば修正する点で、雑誌版の文章とは異なる部分があります。また、図表も雑誌版とは異なります。 予めご了承ください。 また、この文章が対象しているのはMySQL 4.0系なので、最新のリリース版と比べると説明不足な点などが多々あると思います。 レプリケーションの基をおさえるには、この文書はまだ有益だと思いますが、設定レベルの説明は最新のドキュメントを参照するようにしてください。

  • 最短かつ最速にアクセスする「DB高速化技術」(前編):ITpro

    ポイント ・高度なインデックスやジョインを利用し,最短経路でデータにアクセス ・メモリー不足を自律的に解消し,キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し,高速化を図る 目的地に早く到着したいなら,最短の経路を最速で行けばよい。これはデータベース(DB)でも同様だ(図1)。インデックスなどを使ってデータへの最短経路を見つけ,メモリー・アクセスを増やして,最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では,(1)データにたどり着く最短の道を選ぶ仕組みと,(2)アクセスのスピードを上げる仕組みの

    最短かつ最速にアクセスする「DB高速化技術」(前編):ITpro
  • SQLで木と階層構造のデータを扱う――入れ子集合モデル

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • mir the archive

    Contents 更新:2007/08/31 MySQL内部アーキテクチャとソース解析 モジュールと相関図 主要クラスと構造体 ユーティリティ関数 プリプロセッサマクロ グローバル変数 ストレージエンジンインタフェース MySQL Hacking Tips InnoDB関連のソース解析 InnoDB起動プロセス InnoDBバッファプールに関するソースコメントの和訳 InnoDB Record構造 MySQLの拡張 可変引数を持つNativeなSQL関数の実装方法 WarningとErrorの出力方法 HelloWorldネタ GNU AutotoolsでHello World! その他 サンプルコード集 当サイトと管理者について

  • [ThinkIT] 第1回:今、XMLデータベースを始める理由 (1/3)

    XMLデータベース(以下、XMLDB)とはXML形式の情報をXMLのまま保存、検索、出力することができるデータベースのことです。連載では、オープンソースのXMLDBである「eXist」を題材として、まずはXMLDBそのものを簡単に試せるよう、インストールから簡単なサンプルを実際に作成できるところまでを紹介します。 皆さんも、XMLにはほとんどの方が何らかの形で触れられていると思いますが、ことXMLDBとなると「XMLDB? うーん、ちょっと敷居が高いんだよね……!」とお考えの方が、まだまだ多いのではないでしょうか。 その「敷居の高さ」とは、何が原因なのでしょうか。そこで、筆者がかつて感じていた「XMLDBに触らなかった理由」を改めて考えてみました。 これまでXMLにそれほど親しんでこなかった筆者は、XMLというツリー構造のデータをみたとき、どのようにして情報を整理してよいのか、その設計の

  • 「ちょっと待て」 真・MySQLのクエリを最適化する10のTips:CodeZine

    Jaslabs: High performance phpで紹介された「MySQLのクエリを最適化する10のTips」に対して、反論している人がいる。ブログ「20bits」のJesse氏だ。彼は「10 Tips for Optimizing MySQL Queries (That don’t suck)」というエントリーで、Jaslabs氏の記事は適切でないとしている。 Jesse氏の経験によれば、SQL最適化で最も重要なことはSQLDBの基をしっかりと理解することであり、60%がこれで解決するという。残り35%はDBやクエリの特殊な性質に対する対処であり、最後の5%で発想の転換などを求められる。Jaslabs氏はここにばかり力を入れており、それはまったくもって時間の無駄だと述べている(Jesse氏は「SQL_SMALL_RESULTなんて、生まれてこの方使ったことすらない」とまで言

  • Martin Fowler's Bliki in Japanese - トランザクションレス

    http://martinfowler.com/bliki/Transactionless.html 2007/3/18 (更新:Bill Caputoからも経験談をいただいた) 数年前にeBayで働く友人たちと話していたときのことだ。 大規模サイトで使われる技術の話を聞くのはいつも楽しいが、特に興味深かったのが、eBayでは滅多にデータベーストランザクションを使用しないという話だった。 トランザクションがない環境というのは驚くべきことではないだろうか。 データベースを扱うときにトランザクションを使うのはごくごく一般的なことだ。 多くの人にとって(私もそうだが)トランザクションはデータベースを使う利点のひとつだ。 eBayがトランザクションを使わないのは、あのような規模ではパフォーマンスに影響が出てしまうからだというものだった。 eBayではデータをいくつもの物理的データベースにパーテショ

    tanarky
    tanarky 2007/03/23
  • るびま

    『るびま』は、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 直

  • XML DB/XMLデータベース総合サイト「XMLDB.JP」

    「XMLDB.JP」は、XMLデータベース(XML DB)ユーザのための総合情報サイトです。 サイトは、XMLの入門記事ニュースからXML DB製品プログラミング解説や事例研究まで、幅広い記事を収録して、XML初心者からエキスパートまで、 あらゆるレベルのXMLデータベースユーザのお役に立つ情報を提供します。 XMLデータベースの啓蒙を目的としたコンテンツです。ホワイトペーパーなど製品や技術について幅広く解説します。またRDBとXMLデータベースの違いなど誰もが知りたい基的な情報を掲載しています。 詳しくはこちら

  • 1