タグ

2013年11月5日のブックマーク (7件)

  • Cassandraクラスタと、DataStax OpsCenterの構築 | さぶみっと!JAPAN

    Cassandraのクラスタ環境を構築して、DataStax OpsCenterでデータの管理ができるようにします。 Cassandraの設定方法のサンプルを載せているblogなどは沢山あるのですが、旧バージョンのCassandraを試している記事が多くて、頻繁にバージョンアップするCassandraに情報が追いついていません。 ここでは、新しくCassandraを試してみたい方に参考になればと考えて記事を書きました。 また、DataStax OpsCenterというツールを利用して、データの可視化にも挑戦しています。 Cassandraとは 公式ページ:http://cassandra.apache.org 正式名称はApache Cassandraです。 Wikiより引用 『Cassandraは、非常に高いスケーラビリティーを持ち、イベンチュアルコンシステントな分散システム構造のKVS

    Cassandraクラスタと、DataStax OpsCenterの構築 | さぶみっと!JAPAN
  • NAMAKESUGI | Cassandra

    FlexやRuby on Railsなどで使い方とかを自分が後でわかるようにメモしておくブログ。最近はFlex系に飽きてます。 RailsでCassandra0.7系を試してみる - Cassandra-cliを利用する Windows7での環境構築編 RailsからCassandraを操作する前にCassandra-cli(Cassandraのクライアント)を利用してどんなことができそうか試してみます ヘルプ見るのだるいので簡易リファレンスになるようにメモります Cassandraサーバの起動 フロントエンドモードで起動させます cassandra -f Cassandra-cliの起動 cassandra-cli -host localhost Cassandra Keyspace KeyspaceとはRDBにおけるデータベーススキーマのことです Keyspaceの作成 create

  • プログラマと漫画家〜「何を作る」のか考えたいプログラマと「どう作る」を追求するプログラマ | Social Change!

    プログラマには「何を作る」のか考えられるプログラマと「どう作る」を追求するプログラマの2種類いる。どっちが優劣ではなく違いがある。漫画家で言うと、独りで全て出来る人と、原作と作画が分かれて作画を追求する人。そう考えてプログラマは漫画家に似てると思った。 http://twitter.com/#!/kuranuki/status/107815093332492289 プログラマという職業は何に似ているか。プログラミングという作業が、ただの単純労働のように思われてる一面があることに、私はとても憤りを覚えます。 私はプログラミングがとても大好きで、プログラミングはクリエイティブな活動だし、高いスキルが必要なものだとも考えていて、それが出来るプログラマは、もっと希少な職業であっても良いはずだと考えています。 では、プログラマという職業はいったい何に似ているか。あるとき「漫画家」が近いのではないか、

    プログラマと漫画家〜「何を作る」のか考えたいプログラマと「どう作る」を追求するプログラマ | Social Change!
  • gitの勉強会「はじめようgit」を行いました | TECHSCORE BLOG | TECHSCORE BLOG

    スライドを作成するにあたって、色々なサイトを閲覧しましたので、まとめてみました。 基的なこと Git - Book まずはこれを読んどいた方が良いと思います DVCSとGitの基礎 サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ わかりやすいです git - 簡単ガイド 天下一gitconfig大会 参考になるけど、ちょっと古い。 こわくない Gitランチのこと良くわかる。必読。 コミットメッセージの書き方 - ククログ(2012-02-21) コマンドの使い方とか gitとsubversionのコマンド対応表 « cyclogy 一覧で見やすい Git - SVN Crash Course(in Japanese) SVNとのコマンド比較が充実している Subversion ユーザーが Git を使ってみた (基操作編) - ま

    WK6
    WK6 2013/11/05
  • 仕事の分担が下手な組織、多すぎませんか - 脱社畜ブログ

    前回(「生産性の概念の欠如」はなぜ起こるのか)に引き続き、今日も組織の生産性について少し考えてみたい。 前回は、日型の組織ではそもそも個人レベルで生産性を上げるインセンティブがないという点について言及したが、組織の生産性が上がらない理由は他にもある。一言で言ってしまうと、生産性が低い組織は、多くの場合仕事の分担が下手だ。特に、組織が大きくなればなるほど、ヘンテコな仕事の分担が目立つようになる。組織全体で適切な仕事の分担がされないと、どんなに個人が生産性を意識するようになっても、組織の生産性が低いという状況はなかなか改善されない。 ある程度のサイズの組織を眺めていると、「タスクの偏在」を実感することがよくある。組織の構成員全体に均等に仕事が割り振られている、という状態は基的にはあんまりない。これは公務員になった知り合いに聞いた話なのだけど、その人は毎日自分のする仕事がなくて途方にくれてい

    仕事の分担が下手な組織、多すぎませんか - 脱社畜ブログ
    WK6
    WK6 2013/11/05
  • Operations_JP - Cassandra Wiki

    ハードウェア CassandraHardwareを参照して下さい。 チューニング PerformanceTuningを参照して下さい。 スキーマ管理 ノードのクロックをntpなどで同期して下さい。クロックが同期していない場合、更新時刻のずれによってスキーマ変更が無効と見なされる可能性があります。 LiveSchemaUpdatesを参照して下さい。[0.7で導入された機能] リング管理 それぞれのCassandraサーバ(ノード)には、そのホストを最初のレプリカ先として使用するキーを決定するためのトークンが割り当てられます。ノードのトークンでソートした場合、あるノードが担当するキー範囲は(前のノードのトークン、自ノードのトークン]です。即ち、「前の」トークン(その値は含まない)から自分のトークン(値を含む)までの間隔です。リングの中で最も小さいトークンを持つノードはそのトークン値以下のキー

  • EBSインスタンスのrootデバイスを不揮発性にする | sandbox

    EBSインスタンスはStopさせてもデータを保持することができるが、Terminateさせると、さすがにEBSボリュームは削除されてしまう。 必要に迫られているわけではないが、TerminateさせてもEBSボリュームが保持されるようにしてみる。 起動中のインスタンスに適用する方法 起動中のインスタンスの情報をManagement Consoleから参照し、Root Device、またはBlock Devicesのsda1の情報を取得すると、次のようにDelete on terminationがTrueになっていることがわかる。 これによって、Terminate時にEBSボリュームが削除されるのであろう。 ec2-api-toolsを利用して、このオプションを変更してみる。 次のように該当するインスタンスに対して、/dev/sda1の設定を変更してみる。 # ec2-modify-inst

    WK6
    WK6 2013/11/05