DigitalOcean上にMemSQLのクラスタを組んでみた – OpenGroove
しばらく前から分散RDBをいじってみたいと思っていたが、きっかけがつかめずズルズルときた。そんな中、先日Tumblr blogの方にチラッと書いたのだが Pinterestがリアルタイム分析用にSpark & MemSQLの評価中と聞きつけてウズウズしてきたので、重い腰を上げてMemSQLをうっすら触ってみた。 簡単な説明 MemSQLはMySQL互換でスケーラブルな分散RDB。現在のところ、コマーシャルライセンス製品（自分的にはこの点は残念だが、現状オープンソースでまともに動作する分散RDBは存在しない、という認識である）。MemSQLクラスタはaggregatorとleaf nodeにより構成される。aggregatorは管理系で、leaf nodeがコンピュートノードに相当。データはleaf node間で分散される。それぞれ任意の数にスケール可能。 実施環境 いつもならAmazon
時系列データベース周辺を調査してみた – OpenGroove
追記（2014/07/25） KairosDBに関して、HBaseは現在サポートしていないことが判明したので一部修正し、リンク先も現状のアドレスに変更しました。nobusueさん、情報ありがとうございます！ わりと最近時系列データベースという単語を聞くようになったが、告白すると寝耳に水状態でちょっとあせったので軽く調べてみた（きっかけはこの過去記事）。 時系列データベースとやらは国内だとサーバー監視・モニタリングの分野から広まり始めてる印象だが、元々はセンサーデータ、M2M、IoTといったキーワードと相性がいいものらしい。 （ところで IoT: Internet of Things って日本では直訳調で「モノのインターネット」と言われるが、これだと何のことだかわからん。この言い方じゃ普及しないと思うぞ…） 「時系列データベース」と書いたが、プロダクトによってはデータベースという定義ではなく
Postfixで未配信メールの確認 – OpenGroove
メールが停滞している、なんか様子が変、って時はMTAに関らず/var/log/maillogの確認。（追記：Postfixだったら # postqueue -p の方が話が早いかも） その中でbonce、deferredなどのステータスに注目。これらは配送されていないメールのステータスとなる。 status=sent 配送OK status=bounce 配送NG status=deferred 一時的に配送できなかったがリトライ deferredステータスのメールはキューの保持期間において配送をリトライし続けるが、内部に配送不可能な原因がある場合は当然何度やっても送信されない。 /var/spool/postfix/deferred/ディレクトリ配下を見てみると、数字やアルファベット大文字一文字のディレクトリがある。この名ディレクトリ内にdeferredメールが格納されている。（キューI
ほぼやけくそHive Hacks – OpenGroove
Hive Hacksあれこれ。内容はほぼO’REILLY Hadoop Hacksからの引用そのまんま。ただの個人メモなのだが、ずうずうしく公開させてもらいます。いろんなところに記録しておいてもすぐに「あれ、あのメモどこやったっけ」となるのでここに書くのが一番なんだよね。書いたからって理解できるわけでもないんだが… （初めに書いておくと、この投稿長いです） 基本原則的なこと。 ●UPDATEは回避する 処理速度が遅延するため、UPDATEを多数含むようなSQLをHiveSQLに変換することは避けるべき ●MapReduceタスクのオーバーヘッド Hiveは「高スループットを目指す処理には向いているが、低レンテンシを目指す処理には向いていない」というMapReduce処理の特徴を引き継いでいる。MapReduceタスクのオーバーヘッドが付きまとうことを念頭におく。 ●並列分散ができない処理
いつか役立つfuserコマンド – OpenGroove
個人的に普段あまり利用することがないのだが、覚えておきたいfuserコマンドの使い方。 様々な場面で利用する物だと思うが、特にumountでアンマウントできない、 ファイルやディレクトリを削除できない、などという時には、特に。 例えば以下のような状況でイラッとくることがあるので、対処法を書いておこう。 # umount /mnt umount: /mnt: device is busy 上記のように”device is busy”（デバイスは使用中です）メッセージが出てしまった時に umount -lで強制的にアンマウントしてしまったことがあるが、本来であれば対象の ファイルシステムを掴んでいるプロセスを割り出してkillするのが正しい手順なのだろう。 （ちなみに-l は”lazy”のことで、「強制的に」とは少し意味合いが違う。ひと言でいうと ファイルシステムから切り離してからアンマウント
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
