タグ

ブックマーク / nippondanji.blogspot.com (19)

  • サポートエンジニアが経験から語る、論理的文章によるコミュニケーションのススメ

    俺はこれまで一貫してIT業界エンジニアとしてのキャリアを進んできたのだが、これまでのキャリアでもう一つ一貫していることがある。それは、ずっとサポートエンジニアであるということだ。実はサポート職というのはかなり論理的なコミュニケーションを必要とする職種であり、如何に論理的な文章を上手に書くかということが、如何に良い仕事をするか(短い時間で成果=顧客満足度を得られるか)ということに繋がるという側面がある。(もちろん高い技術力が必要なのは言うまでもないが。)サポートエンジニアはメールや報告書という形で日々論理的な文章を書かなければならないので、サポートの経験を重ねることによって論理的にコミュニケーションをする能力というのは徐々に磨かれよう。しかし、論理的にコミュニケーションをするというのは意外と皆出来ているようで出来ていないし、筋が悪いといつまで経っても身につかないこともあり、上手にお客さんを

    サポートエンジニアが経験から語る、論理的文章によるコミュニケーションのススメ
  • MySQL 8.0.0 Development Milestone Release登場!!

    先月、詳解MySQL 5.7を発刊したばかりであるが、MySQL 5.7自体は去年の10月にリリースされたバージョンである。それから約1年弱、MySQLは開発の手を緩めること無く日々改良を重ねている。 そう、MySQL 8.0の登場である。 現在はDevelopment Milestone Release(通称DMR)という状態なので、まだ正式版における機能が固まっている段階ではないという点には注意して欲しい。MySQLの開発プロセスでは、DMRをリリースするごとにその段階で成熟した機能をマージする。DMRを何度かリリースした後に、キリの良いところでリリース候補版となって正式版で追加される機能が一応確定し、その後バグ修正を経て正式版(GA版)がリリースされる予定となっている。詳しくはMySQLのマニュアルを参照して欲しい。 バージョン8.0!!5.7の次は誰もが5.8だと思っていただろう・

    MySQL 8.0.0 Development Milestone Release登場!!
  • InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる!

    MySQL 5.1.38からMySQL体にInnoDB Pluginバンドルされている。一部の先駆的なユーザー以外に、「InnoDB使ってますよ!」もしくは「検証してるよ!」という話をあまり聞かない。そもそもであるが、InnoDB Pluginってなんぞ?!という人が多いんではないかと思うのだが、実際はどうなのだろう?現在はRC版(リリース候補版)という位置づけのInnoDB Pluginであるが、一部影響度の高いバグが残っていたりしてGA版ほどの安定性は求められないものの、ほとんど実用に耐えうる品質になっているといえる。そんなわけで、今日は改めてInnoDB Pluginの使い方・使いどころについて説明するので、ぜひ皆さんの手でInnoDB Pluginを評価してみて頂きたい。 なお、以下の解説は現在の最新バージョンである、InnoDB Plugin 1.0.6を前提にしているので、将

    InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる!
  • MySQL 5.6登場!!新機能速攻レビュー

    現在、米国で行われているMySQL Conference & Expoにあわせて、新しい開発版であるMySQL 5.6が発表された。MySQL 5.5における新機能もかなりのものだったが、MySQL 5.6の進化は質・量ともに勝とも劣らない内容となっている。そこで、今日は簡単に、MySQL 5.6で追加された新機能の概要について見てみよう。開発版なので利用にあたっては十分な注意が必要(予期なく予定が変更される可能性あり)だが、次期正式版のリリースに向けて是非試してみて欲しい。 InnoDB関連MySQL 5.5で大幅な進化を遂げたInnoDBだが、その勢いはまったく衰えることを知らない。性能の強化だけでなく、痒いところに手が届く便利な機能が追加されている。 ダーティページのフラッシュをするスレッドが独立した。以前はマスタースレッド内でフラッシュが行われていたが、スレッドが独立したことによっ

    MySQL 5.6登場!!新機能速攻レビュー
  • パーティショニングの使用例 - http session情報

    今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする(たぶん昨日の例よりも)もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDBMySQL Cluster)ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン

    パーティショニングの使用例 - http session情報
  • まだMySQL 5.5で消耗してるの?MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法

    MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン!!と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり(つまりクラッシュ)しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。(REDOやUNDOするアレのことだ。稿では面倒臭い・・・ではなかった、題ではないた

    まだMySQL 5.5で消耗してるの?MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
  • MySQLレプリケーションの運用が劇的変化!!GTIDについて仕組みから理解する

    メリークリスマス!!やあ、良い子のみんな!!サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ!! というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID(Global Transaction ID)である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ

    MySQLレプリケーションの運用が劇的変化!!GTIDについて仕組みから理解する
  • ナチュラルキーとサロゲートキーについての議論

    とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー(代理キー)」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル(≒行)の値を一意に決定することができる属性(≒カラム)の集合」の

    ナチュラルキーとサロゲートキーについての議論
  • パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合

    MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日語に訳すと濃度とか訳されるが、要は値の種類(分散具合)のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を

    パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
    gologo13
    gologo13 2014/10/09
    カーディナリティが低いカラムを検索条件に指定しなくてはいけない場合、パーティションがパフォーマンス向上に貢献する
  • OSC広島と中国地方DB勉強会に参加しました。

    かねてから予告していた通り、OSC広島と中国地方DB勉強会(第5回)に参加させて頂いた。両方のイベントがこの土日で連続して行われたので、いずれのイベントにも遠方からの参加者がたくさんいて盛況だったように思う。OSC広島ではデモマシンの展示を、中国地方DB勉強会ではスライド(MySQLのトラブルシューティングについて)の発表をそれぞれやらせて頂いたので、今日はその報告をさせて頂こう。 OSC広島に持っていったデモマシン既にツイッターやFacebookで目にされた方もいらっしゃるかも知れないが、今回展示したマシンのコンセプトは「持ち運べるMySQL Clusterのデモ環境」というものだ。MySQL Clusterを動作させるためのBeagle Bone Black 6台と、コンソール用のRaspberryPi、100Mbpsのネットワークスイッチ、薄型のモバイルモニター、トラックポイントつき

    OSC広島と中国地方DB勉強会に参加しました。
  • もしもデータベースサーバがクラッシュしたら

    人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ!!人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから

    もしもデータベースサーバがクラッシュしたら
    gologo13
    gologo13 2014/09/22
    より高い可用性、整合性を保つ手段。
  • 漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法

    ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基中の基であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_

    漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

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

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

    今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx

    オトコのソートテクニック2008
    gologo13
    gologo13 2012/12/23
    相変わらずわかりやすい。where句+OrderByでインデックスを用いるには、複合インデックス。※カラムの順序大事。しかしインデックスのディスクサイズが半端ないので、使う状況をよく考えワウ
  • 開発スピードアクセル全開ぶっちぎり!日本よ、これがMySQL 5.6だッ!!

    米国で行われているMySQL Connectというイベントで、ついにMySQL 5.6 RC(リリース候補版)が発表された。リリース候補版ということは、これが次の正式版になるということだ。MySQL 5.5は5.1から凄まじい進化を遂げたバージョンであった。だが、MySQL 5.6はさらにそれを上回る進化を遂げている!正直ここまでの進化を誰が予想しただろうか、いや誰も出来なかったであろう。これまで、α版が出たときから何度か新機能について紹介してきたが、今回改めてMySQL 5.6の新機能を振り返ってみようと思う。すべてまとめるともの凄い内容だ。興奮して夜も眠れなくなること請け合いだ。MySQLの進化が止まるのでは?などという心配は吹き飛び、もはやもうちょっと小出しにしなくて良かったのか?と心配してしまうレベルである。 それではMySQL 5.6の新機能について紹介していこう。 InnoDB

    開発スピードアクセル全開ぶっちぎり!日本よ、これがMySQL 5.6だッ!!
  • 爆速SSD Fusion-io ioDrive Duo現る。ただしインターフェイスはPCI Expiress

    PC Watchの記事で Fusion-io、読み取り1.5GB/secの世界最速SSDPCI Express接続で最大容量1.2TB というニュースを見かけたのだが、この製品がなんとも凄い。 シーケンシャルリードは1.5GB/sec、シーケンシャルライトは1.4GB/secというからまさに爆速!!最近人気のインテル製SSDでもシーケンシャルリードが250MB/sec、シーケンシャルライトは170M/secぐらいだからまさに桁が違う。ただしこの製品、インターフェイスはPCI Expressであり、残念ながらノートPCでは利用出来ない。MacBook Proでウハウハ快適生活!!は出来ないわけである・・・残念。 製造元のFusion-ioはサーバー向けだと謳っているのて爆速SSDでウハウハ快適データベース生活!!なら可能だ。サーバー用途で使う場合、PCI Express接続だと共有スト

    爆速SSD Fusion-io ioDrive Duo現る。ただしインターフェイスはPCI Expiress
    gologo13
    gologo13 2012/09/23
    全然わからん 漢(オトコ)のコンピュータ道: 爆速SSD Fusion-io ioDrive Duo現る。ただしインターフェイスはPCI Expiress (via Instapaper)
  • さらにMySQLを高速化する7つの方法

    MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗(?)でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう!!と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢(オトコ)のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負!!というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ

    さらにMySQLを高速化する7つの方法
    gologo13
    gologo13 2012/09/23
    (オトコ)のコンピュータ道: さらにMySQLを高速化する7つの方法 (via Instapaper)
  • MySQLのEXPLAINを徹底解説!!

    以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ

    MySQLのEXPLAINを徹底解説!!
  • ついカッとなってQuine生成ツールをこしらえた

    心のこもったメッセージを伝えたい。そんなとき、少し趣向をこらしてみようと思うのが人情というものだろう。ギークらしさを演出しつつ、ちょっと凝ったメッセージ。ならQuine(クワイン)がいいんじゃね!?と思い立って急遽ツールを作成した。作成方法などはRubyでうどんげQuine(とAA型Quineの作り方講座)を参照させて頂いたので特にロジックを考える必要はなかったのだが、せっかくなのでQuineの生成を自動化すると面白いかなと思ったのであった。 ダウンロードはこちらから。 Quine Tools @ GitHub(仮) 興味があれば遊んでみて欲しい。言語はRuby。入力にはUTF-8を想定しているので、ロケールがUTF-8じゃない人は適宜ソースをいじって頂きたい。 Quine Toolsには次の2つのプログラムが含まれている。 jbanner.rb ... 日語のbannerを表示するプロ

    ついカッとなってQuine生成ツールをこしらえた
  • 1