Page Not Found We are sorry but the page you are looking for does not exist. You might have mistyped the address or the page may have moved. Take me back to the homepage.
Error | Navicat
Page Not Found We are sorry but the page you are looking for does not exist. You might have mistyped the address or the page may have moved. Take me back to the homepage.
Nagios/プラグイン/check_pgsql - cubic9.com
と仮定。 対象 ローカル or リモート アーカイブ内での位置 plugins/check_pgsql 必要なもの postgresql など。 コンパイル時に下記オプションを指定する必要がある。 --with-pgsql=/usr/local/pgsql 準備 チェック用のDBを作る。 /usr/local/pgsql/bin/createuser -A -d nagios /usr/local/pgsql/bin/createdb -U nagios checkDB /usr/local/pgsql/bin/psql checkDB 実行 DBに2秒で接続できないと WARNING、8秒で接続できないと CRITICAL。 /usr/local/nagios/libexec/check_pgsql -H 192.168.0.2 -d checkDB -l nagios -p 'abcd
ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
NoSQLデータベースを試してみる 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第1回 memcachedの基本 | gihyo.jp
株式会社ミクシィ 開発部 システム運用グループの長野です。普段はミクシィのアプリケーション運用を担当しております。今回から数回にわたり、最近Webアプリケーションのスケーラビリティの分野で話題になっているmemcachedについて、弊社開発部 研究開発グループの前坂とともに、使い方や内部構造、運用について解説させて頂きます。 memcachedとは memcachedは、LiveJournalを運営していたDanga Interactive社で、Brad Fitzpatrick氏が中心となって開発されたソフトウェアです。現在ではmixiやはてな、Facebook、Vox、LiveJournalなど、さまざまなサービスでWebアプリケーションのスケーラビリティを向上させる重要な要素になっています。 多くのWebアプリケーションは、RDBMSにデータを格納し、アプリケーションサーバでそのデータ
MySQLに纏わる10の都市伝説
誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。（特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ！！）しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られ
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
MySQLクイック・リファレンス
この文書は、osCommerceで使用しているデータベースMySQLの基本的な使い方について解説しています。おもにデータベースの管理者よりも、ユーザに向けて書かれています。 はじめに ここでは、MySQLサーバは起動しているものとして説明します。 MySQLの文字について MySQLでは、データベース名やテーブル名の大文字と小文字を区別しています。それ以外は区別しません。 MySQLのフィールド名やテーブル名に使える文字は、英数字と_（アンダーバー）、$、サーバのキャラクタセットにある文字です。 知っておきたいコマンド mysqladmin（データベースの作成・削除や、MySQLサーバの情報を得る） mysqlshow（データベース、テーブルの情報を表示する） mysql（MySQLクライアントの起動） mysqldump（データベース、テーブルをダンプする） myisamchk（テーブル
ウノウラボ Unoh Labs: RDBで階層構造を扱うには？
yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには？」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBはMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま
DB設計時のサイズ見積もり - よねのはてな
ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ
データベース設計はいつ、何をポイントに行うか
データベース設計はいつ、何をポイントに行うか：ゼロからのデータモデリング入門（4）（1/3 ページ） 前回までは、データベース設計の歴史的背景からデータベース設計の有効性までを解説しました。今回は、システム開発ライフサイクルと照らし合わせ、それぞれのフェイズで必要となるデータベース設計について、お話をします。 どの段階でどう設計すればいいのか 前回、データベース設計は自社のビジネス活動を理解している自社内の人間がやるべきであり、情報システム部門の存在意義を高めるために必要な技法であるとお伝えしました。しかし、システムの外部委託が多いというのもまた事実です。 筆者の職場では、お客様からデータモデリングに関するご相談をいただく際、最初に「貴社のデータモデルを拝見させてください」というお願いをします。システム開発を外部委託しているケースでは多くの場合、形として残っているのは「物理データモデル」で
システムの寿命はコードで決まる！
データベースをコードに依存しないように設計する さて、コードはできました。次はデータベースを設計します。コードがずっと同じ体系であれば何も考えずに設計できるのですが、残念ながらこの世は無常です。コードがパンクしなくても、業務・システム統合のためにコードを統一するという前向きな事情によりコード体系を変えることもあります。 そこで本稿では、「データベースをコードに依存しないように設計するためにはどうすればよいか」に重点を置いて、注意すべきポイントを解説します。また、解説の際にケーススタディとして、図1のように書店の販売システムとクライアント企業の購買システムが連携する場面を利用します。 （1）業務で利用するコードを主キーとして利用することは避ける 業務で利用するコードをテーブルの主キーとして利用することは、コード体系とデータベース設計を独立させるという観点からできるだけ避けるべきです。図1のケ
(旧館)サウスポーなエンジニアの独り言
今回のバレーW杯の女子。 結果、過去最低の7位とのことでした。 選手やチーム力を考えれば正直「こんなものかな？」と思いました(もちろん良いプレーでしたが)。 全部の試合を見たわけではないですが、素人目から見ても選手選考から始まって選手交代について？と思いました。 なによりメンバー構成を眺めた時に「1：センタープレイヤー多すぎ」「2：セッターの控えが高校生？」「3：故障明け(というか故障中？)の大山がいる？」て色々思いました。 [1]「センタープレイヤー多すぎ」 吉原や大友が抜けた後のセンターがいないのは分かりますが、オープンに比べ(WS＝ウィングスパイカーって呼び名を最近はするんですね)、セッターとのコンビネーションがより大事になるのでセンターをあんなに入れて有効に使えるのかどうか…。 と思って見ていれば、ほとんどワンポイントブロッカー以外ではほぼ出場せずでした。 [2]「セッターの控えが
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
[データベース編]ビュー，トリガーを多用してはいけない
開発フェーズで，データベース設計とアプリケーション設計との間で仕様の認識が異なっていることがよくある。そのようなとき，データベースもしくはアプリケーションのどちらかで仕様変更を吸収する必要に迫られ，ビューやトリガーといったデータベースとアプリケーションの中間に位置するグレーな部分で回避する場面をよく見かける。 これは，構築したデータベースへの変更とアプリケーションへの変更を最小限に抑えるテクニックの一つである。しかし，このグレーな部分での回避策を多用すると，今後のデータベース，アプリケーション双方のメンテナンス性に対して大きな禍根を残すことが多い（図1）。 カラムを一つ削除するのも大変 確かに，ビューやトリガーは，使い方によってはアプリケーションで考慮しなくてはならないことをデータベース側で吸収できる優れた機能である。しかし，データベースから見ればビューやトリガーは通常のオブジェクトとは異
![[データベース編]ビュー，トリガーを多用してはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
[ThinkIT] 第1回：ソフトウェア産業に産業革命を起こすデータモデリング (1/3)
日進月歩で技術革新するハードウェア産業や、ドッグイヤーで進化するITビジネスに比べ、ソフトウェア開発の現場はいまだに20〜30年前のやり方と大差がありません。徒弟制度での教育、開発ドキュメントの標準化の遅れ、精神主義がまかり通るプロジェクト管理、そして開発手段も相変わらず昔ながらの家内制手工業です。このような労働集約的なやり方を続けた結果、日本のソフトウェア産業の国際競争力は地をはっています。 「生産性向上」「コスト削減」「品質向上」、これらは製造業における共通課題です。日本のメーカ各社は、この目標を実現するために"カイゼン活動"や"最新設備導入"などの絶え間ない努力を行い、その結果、世界に冠する強さを持つまでにいたっています。 一方、ソフトウェア産業はどうでしょうか。派遣主体の会社には課題認識すら希薄です。また多くの企業にとってこれらの言葉は単なるスローガンであり、具体策が現場に根付いて
制約の使い方、Unicode使用可否、明細テーブルの設計 (1/3)
前回は、データベース設計で誰もがぶつかる問題である「列名に日本語を使うか?」「どのデータ型を使うか?」ということをテーマに取り上げました。今回も引き続き、データベース設計で迷いやす点をいくつか取り上げ、筆者の考え方を参考にしていただこうと思います。 前回、説明したデータベースの標準規格SQL99では「制約」という機能が定義されており、OracleやSQL Serverなどの通常のRDBMSにも実装されています。 制約とはデータベースに格納されるデータに制約条件を付けるものです。例えば、NOT NULL制約が設定されている項目はNULLを許容しませんので、必ず値がセットされなければなりません。制約を設定した列に、値を指定せずにデータを格納しようとしても、RDBMSが制約違反ということでエラーを返します。 RDBMSで実装している制約には、表1のようなものがあります。
LVS+ldirectorを使ってMySQLをロードバランスをしてみる - sanonosa システム管理コラム集
今回はLVSを使ってMySQLのslaveサーバをロードバランシングする方法を記してみます。LVSは単に振り分けしかやってくれませんので、リアルサーバの生存確認やLVSの作動管理のためにldirectorも導入しています。 LVSだけだとLVSの設定を入れ込まなければなりませんが、ldirectorを使うとldirectorの設定ファイルに書いておくことでLVSの設定をldirectorが自動生成して反映してくれるので楽ちんです。 ※世の中にはLVS+keepalivedの組み合わせが多いようですが、検証してみたところldirectorのほうが導入も運用も簡単なのでこちらを採用しました。 前提条件 VIP: 10.0.2.10 DB1: 10.0.0.101 DB2: 10.0.0.102 ロードバランサーとなるサーバへのインストール方法 【インストール】 # yum install ip
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
kndb.jp
Amazon.co.jp: Linux-DBシステム構築/運用入門: 松信嘉範: 本
