がるの健忘録 このページをアンテナに追加 RSSフィード

2012-11-19

[][]トランザクション周りの覚書2

http://d.hatena.ne.jp/gallu/20121112/p1 の続き。


これをやれば、後は単純にmemcache_handleのupdateとかinsertとかそっち系の実装で「トランザクションonなら実際のinsertとかupdateとかの代わりにdeleteを走らせる」って処理でいけると思う。

共通化して処理しませう。

の部分で、根本的に勘違い。


ん…まず。

data_clumpには現在、2つのモードがあるざんす。

キャッシュモード

浅いレイヤーキャッシュのように用いることからこのネーミングになった。

「最近使ったものはキャッシュしておきたい」系に適している。

デフォルトのモードはこっち。


・コードマスターモード

コードマスタにおいて比較的よく用いられるためにこのネーミングとなった。

原則「すべてのコードをメモリ上における」みたいな状態のものに適している。

で…

Create

キャッシュモード

すべてのレイヤーに共通して書き込む

・コードマスターモード

もっとも深いレイヤーのみ書き込み、残りのレイヤーに対しては削除を行う

Read:2モード共通

キャッシュモード

・コードマスターモード

浅いレイヤーから順次探していく

また、もっとも浅いレイヤー意外で見つかったら、見つかったレイヤーより浅いところのすべてに書き込んでおく

Update

キャッシュモード

すべてのレイヤーに共通して書き込む

・コードマスターモード

もっとも深いレイヤーのみ書き込み、残りのレイヤーに対しては削除を行う


Delete:2モード共通

キャッシュモード

・コードマスターモード

すべてのレイヤーに対して共通して消しこむ

ん…モード切り分ける意味、そんなにないなぁ。

細かいところまでチューンするとまぁ「CreateやUpdateの時にキャッシュレイヤーに書き込んでおく」と、「CreateやUpdateの時にキャッシュレイヤーの情報を削除、次にReadが発生するタイミングで書き込む」よりも少しコストメリットはあるんだけど、でも誤差レベルな気がする。その辺は、整合性とか安全性とか重視したいし。


で。

モードを全部「コードマスタ」系にすると、当初想定している

これをやれば、後は単純にmemcache_handleのupdateとかinsertとかそっち系の実装で「トランザクションonなら実際のinsertとかupdateとかの代わりにdeleteを走らせる」って処理でいけると思う。

がすでに実装済みなので、無問題

よし、モードを切って「コードマスタモード」のみにしませう。


…うんうんしみじみYAGNIだねぇ結局モード使わなかったねぇ(苦笑

っちゅわけで、その方向で実装を進めませう。

2012-11-12

[][]トランザクション周りの覚書

ものっそ覚書。

というか考えながら書いているに近い状態なので、もしかしたら文頭と文末で矛盾してるかもな場合は文末を信用してちゃぷたい。


さて。

MagicWeaponのデータ系ハンドルは、現状、こんな感じ。


data_handle

├db_handle_base

|├db_handle_plural(内部でdb_handle)

|└db_handle

└kvs_handle

 └memcache_handle

実際にはもうチョイあるんだけどね。今回にかかわるのを中心に書いてみる。


data_handleは「ありとあらゆる、データを扱うシステムのハンドル」を意味する、一番粒度の荒いクラス。

すべての「データを扱うサブシステム」のためのクラスは、この子を継承するのが条件。


db_handle_baseは、実際には「rdb_handle_base」って書いたほうが正しいんだよね。リレーショナルデータベース用のハンドルの基底クラス。なんで基底なのかは、もうチョイしたら説明する。

ちなみに同レベルにあるkvs_handleは「KVSを扱うためのデータハンドル」用クラス。この下にmemcache_handleとかがあるんだね。memcache_handleは、memcachedという「実装そのもの」を扱うクラス。粒度としては一番細かいところで、ここにいろいろ実装が書いてある。


db_handle_baseの直系のクラスはdb_handle。っつか歴史的経緯で話をすると「もともとdata_handle → db_handleって継承図だったんだけど、db_handle_pluralを作る必要が出てきたから、共通部分を持ち上げたのがdb_handle_base」って感じだ。

なので、db_handleはまぁ予想がつくとおり「DB用のハンドル」。この子単体だと、PDOとほぼ同系列。


で、db_handle_plural。

これは「マスター&スレイブの構成」と「テーブル単位のシャーディング(横分割なんて言い方もしますなぁ)」をどうしてもフレームワーク側で解決せざるを得ないシーンがあって、それ用に作ったクラス。

db_handle_pluralは複数の「db_handle インスタンス」を腹に抱えるような実装になってる。

大まかに「このテーブルのwrite用」とか「このテーブルのread用」とかってんでDBハンドルを使い分ける感じ。


んで。

ここ最近…でもないんだけど、いい加減トランザクション対応をいろいろやりたくて、ってのが、今回の改修の目的のひとつでもあり、眼目でもある。


とりあえずざっくりと、トランザクション周りの実装をdb_handleに持ったんだけど。

実際にBEGINを発行するあたりはここに持つべきなんだけど、たとえば「is_tran」みたいな実装は、本質的にはdata_handleに持つべきだったんだよね。

実際にトランザクションが可能かどうかってのはおいといてさ。


なので、とりあえず「トランザクション状態の保持とチェック」周りは持ち上げよう。

と、ここまではOK。


若干気をつけたいのはdb_handle_pluralに対するトランザクションの開始周りとか。具体的にはbegin()メソッド

メソッド引数にテーブル名を受け取って、db_handle_pluralは「担当するdb_handleにBEGINSQLを流しつつ」「トランザクション状態をonにする」ってのをやらないとねぇ。

これもToDo


問題は、実際にdata_handle群を使う、data_clump側。

具体的に問題なのは。data_clumpは「複数のdata_handle(を継承した実装)インスタンスを持っている」ってのがポイント。

ちなみに「複数のdata_handle(を継承した実装)インスタンスを持っている」理由は、端的には「RDBキャッシュとしてmemcachedをもってる」とかってのを簡単に実装するため。

上述の場合「深度1にmemcache_handle、深度2にdb_handle」を持っているざんす。

動きとしては

・insert/update/deleteの場合、深度1と深度2にそれぞれinsert/update/delete

・selectの場合、深度1に存在していればそのデータを、存在していなければ深度2のデータを用いる

ってな感じ。

この辺が、特に最近「MagicWeaponとmemcachedとの相性がいいなぁ」と思う所以。


閑話休題


とりあえず限定条件。

まず「KVSのみ」の場合、そもbeginは使わないと思うから、いったん脳みそからはずす。

なので、想定したいのは

RDBのみ

・KVS→RDB

の2パターン。より厳密には

RDBのみ(mono)

RDBのみ(plural)

・KVS→RDB(mono)

・KVS→RDB(plural)

の4パターン。


理想とする挙動としては

トランザクション中の更新系は、KVSのキャッシュを「削除する」という動きをする

感じ。

そうすると、トランザクションコミットしたときに「キャッシュのデータが削除されてRDBにのみ情報が残る」から、変なキャッシュエラーとか起こさずにすむだろう、って魂胆。


問題。

厳密には、db_handle_pluralにおいては「無関係なテーブルのトランザクション」でトランザクションonになる可能性があるんだけど。

ん…シャーディングしてて、サーバAに「テーブルあ、い、う」、サーバBに「テーブルえ、お」があると仮定。

テーブルえに対するトランは、厳密には「サーバA」には無関係。

でもまぁ面倒なんでその辺は一緒くたにさせてもらおういったん。

…なんとなく、このシャーディング機能、最近のMySQL Spiderエンジン&MySQL Clusterを見てるとそろそろ「いらねぇかなぁ」とか思う瞬間もあるし。あんまりここに血道をあげすぎない。


そうするととりあえず。実際のSQL発行場所はともかくとして

・基底であるdata_handleでトランザクション状態を持つ

・db_handle_plural::begin(テーブル名)は、内部の担当db_handleにSQLBEGINを発行していただきつつ、自分自身に対してtran_on()

・db_handle::begin()は、SQLBEGINを発行しつつ、自分自身に対してtran_on()

ってやると、とりあえずなんとかなる気がする…ここまでは。


後はdata_clumpで「異なる深度のdata_handleたちに情報を渡す」方法だな。

いろいろと面倒が多いなぁ…いったん割り切るか。後でまた改修したほうがいい気がしてるし。

もちろん実装的には変な深度とかもてるけど、実際問題として現状

・KVS

・KVS→RDB

RDB

の3パターンしか許容していないので。こんど、こここれで絞ろう。これ以上深い、3深度以上とかいらないっしょ。


そうすると、以下のロジックが可能なはず。

・深度が1つの場合、そのまま処理する

・深度が2つある場合、深度2のトランザクション状態を深度1のハンドルに反映する


これをやれば、後は単純にmemcache_handleのupdateとかinsertとかそっち系の実装で「トランザクションonなら実際のinsertとかupdateとかの代わりにdeleteを走らせる」って処理でいけると思う。


ふむ…たぶんうまくいく、かなぁ。

突込みが入ったら、理論構築をしなおして実装もやりなおそうw

2011-04-13

[][]マネジメントのベクトル

http://d.hatena.ne.jp/gallu/20110327/p3

http://d.hatena.ne.jp/gallu/20110401/p1

の続き。


んと…とりあえず「マネジメントってなに?」ってあたりから。

対象は複数人。…とはいえ、一人でも「時間が違えば他人」ってのがおいちゃんの原則なので、まぁ一人作業してても「未来の自分へのマネジメント」ってあるんだけどね。


複数人がひとつの仕事を「力を合わせて」やることを前提に。

最悪なのが「お互いがベクトル的にぶつかり合う形で、相手の足を引っ張ることに全力を注ぐ」ケース。一人でやったほうがマシ。

次に「なんの邪魔も入らないけどなんの好影響も与え合わない」。ダメっぽく聞こえるけど、この水準に達していることって珍しいとむしろ思う。っていうか「複数人が完全に摩擦係数0って、ある意味ありえない」ような気もするし。

類似品として「相互作用がマイナスにもプラスにもある」ってところ。プラマイがちょうど0なのが、多分「摩擦係数0」と似たり寄ったり。

で、マイナスが減っていってプラスが増えていくと「まぁべらす」なマネジメントになるのではないか、と。

さらにプラスが増えていくと、いわゆる「シナジー効果」的なものになって。ンなもんが発生した日にゃぁ万々歳、大入り袋が飛びかうってなぁ感じで。


つまり、複数人作業において

・マイナス方向への作用を減らす

・プラス方向への作用を増やす

のがマネジメントなのではなかろうか、っと。


後は「短期的」な見解と「中長期的」な見解を考えてみたい。


[][]マネジメントの範囲

同じく

http://d.hatena.ne.jp/gallu/20110327/p3

http://d.hatena.ne.jp/gallu/20110401/p1

の続き。


んと…「全体最適」は理想なんだけど、現実問題として「森羅万象のすべてを見通した上での最適」なんて、イエッサのパパぢゃないと無理@聖☆おにいさん。

スイカ割りであんな「最適解」が出せるあたりが素晴らしい、ってのは余談w


だとすると。

「局所最適」の局所を、少しでも広くすることが必要なんじゃないか、と。


場当たりで「今の自分最適」は、「未来の自分的最悪」だし。

「自分最適」は「チーム的最悪」だし。

「チーム最適」は「部署的最悪」だし。

で、部署から会社、業界、国、なんていう風にスケールがあがっていくんだと思う。


どこまでいけるかはしらないんだけど、とりあえず「会社最適」ないし「業界最適」くらいまでは持ち込むのが、会社にいる「マネージャ」と呼ばれる人の、マネジメント範囲なのではなかろうか? とか妄想。

2011-04-05

[][][]手を早くするための考察 序章

今度落ち着いて考察したいのですが。

とりあえずひとついえることを、先に。


「後で修正できる」、隙間があって隙のない設計&コーディングしてれば、安心して「すっかすか且つアバウトな実装」が出来るので、早いです。

後修正がしんどい書き方をしているから、色々と懸念して妄想して、余計な実装があったり手が止まったりするです。


安心感って大切だなぁ、と思う今日この頃。

2011-04-01

[][]「出来上がっているチーム」という幻想

http://d.hatena.ne.jp/gallu/20110327/p3

の続き。マネジメント考察にむけての準備。


んと…多分「進むべき前を見据えてまっすぐに進むマネージャ」と「足元を見据えてじっくりと育てるマネージャ」っていう極があって。

…共存不可能ではないんだけど、マネージャの能力的に「キャパシティオーバー」なケースが少なからずあって。

その場合、一般的に「経営層付近に受けのよい、まっすぐ進むマネージャ」系が増える。


で…


その場合「スキル的にも人材配置的にもコミュニケーション的にも雰囲気的にも」仕上がっているチーム、が前提になる。なんでかってぇと「育てている暇も余力もない」のであれば、当然のごとく「成熟した個体+完成したチーム」がないと困るから。

で…現実問題の結果として「スキルが足りない」「なんか配置した場所で能力を発揮してくれない(よく「チームの和を乱す」とか表現される)」「必要な情報をちゃんと報告してくれない(「報告しにくい場」が形成されていることについては言及されない)」「なんか雰囲気が悪かったりやる気がなかったりモチベーションが低かったりする」という理由でメンバーを入れ替えだして。

ただ、その状況で「よいチームが出来上がる」まで入れ替えを続けるのは、果たしてどうなんだろう? とは思う。


チームもまたひとつの「システム(系)」である以上、定期的なメンテナンスが不可欠なんだ。PDCAとか言ってもよいよ?


うん、少しまとまってきた。