fluent-plugin-elasticsearchやKibanaのデフォルトであるlogstash形式では、年月日毎にインデックスを作成されて使われることを想定されています。 これは扱いやすいのですが万能では無く、次のような状況ではパフォーマンス的な観点で、このインデックスの粒度を変更することを検討すると良いケースがあります。 粒度を細かくしたいケース（時間単位） 日毎のインデックス作成では、elasticsearchに割り当てたメモリ量を超えてしまう 粒度を荒くしたいケース（週単位/月単位/年単位） 日毎のインデックス作成では容量が小さく、日常的に検索する範囲が複数のインデックスに渡るとき Kibanaは年月日以外の粒度（時間・日・週・月・年）にも対応していますので、変更することも容易です。これは次の2つの設定変更で適用できます。 ログ収集を行うElasticsearchへ流し込む、

photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった！さあランチタイムだ！ ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO

ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。 しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。 それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは

2013年10月25日にオラクルで開催された「MySQL Casual Talks Vol.5」に参加しました。 そう、前回の発表での約束を果たすために。という訳で今回は2回目の参加＆2度目のトークです。 発表テーマ Tritonn (MySQL5.0.87+Senna)からの mroonga (MySQL5.6) 移行体験記 MySQL5.0から5.6へ移行するにあたり、全文検索機能をTritonnからmroongaへ乗り換えるというプロジェクトの体験記をお届けします。 発表資料 Tritonn (MySQL5.0.87+Senna)からの mroonga (MySQL5.6) 移行体験記 from Kentaro Yoshida http://www.slideshare.net/y-ken/mysql-migrate-mysql50-to-mysql56-with-fulltext

mruby-fluent-logger (別名 fluent-logger-mruby) のv0.0.2をリリースしました。 今回の目玉は、シリアライズエンジンの変更です。 これまでのJSONから、suzukazeさんにより移植されたmruby-msgpackへ切り替えることで、パフォーマンスが向上しています。 https://github.com/y-ken/fluent-logger-mruby https://github.com/y-ken/fluent-logger-mruby/releases/tag/v0.0.2 ログ収集エンジンFluentdをmrubyから利用するためのロガーパッケージ「mruby-fluent-logger」のmsgpack対応版をリリースしました。jsonに比べて著しい性能向上を果たしています。 https://t.co/kzi9YPBRFI #mru

twiccaの一時的な不具合でアップロードできないのかと思いきや、 なんと連携先であるvia.meが閉鎖していることによるトラブルでした。 これは影響が大きいですね。 写真共有サイト「via.me」がサービス終了のお知らせ。Twitter連携していた人もいると思うので、必要に応じて過去写真のダウンロードを行っても良いかもしれません。 http://t.co/lx74f2hWIY— Y.Kentaro (@yoshi_ken) August 4, 2013 何が起きたか？ 簡単にまとめると以下の通りです。 twiccaが利用する写真共有サービス via.me が2013年7月末をもって閉鎖 過去にアップロードした写真は、ダウンロードリクエストをすることでzipファイルで入手可能 2013年9月末までにダウンロードリクエストを送らない限りすべて削除対象 2013年10月18日に全ての画像を完全

MySQLサーバで希に遭遇するディスク残量障害事例と共に紹介します。 こちらは、以下エントリよりネタをパクりましたインスパイアしました。すみません。 Linuxサーバがディスク容量不足になった！何か消さねば！ってなった時にどう対処するか - 元RX-7乗りの適当な日々 Linuxサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか - tagomorisのメモ置き場 今回紹介する対処パターン 今回は4つの方法を紹介します。 不要なデータベース/テーブルを削除 スロークエリログ/クエリログを削除 バイナリログを削除 どれのパターンにも属さないレアなシチュエーション 不要なデータベース/テーブルを削除 あまりそういうケースは無いとは思いますが、 DROP DATABASE foo;やDROP TABLE foo;で削除します。 スロークエリログ/クエリログを削除 du -sc