問題タブ [kiokudb]

かなり大規模なレガシー プロジェクトで、いくつかの毛むくじゃらのモジュールを Moose クラスにリファクタリングしました。これらの各モジュールは、その属性を (遅延) フェッチするためにデータベース アクセスを必要とします。これらのオブジェクトはかなり頻繁に使用されるため、たとえば変更されていないデータに対する冗長なリクエストの数を減らしたいと考えています。

さて、どうすればそれを適切に行うことができますか？いくつかの選択肢があります：

1. 5〜10分の有効期限でそれらを保存するロールを介してMooseクラスにキャッシュを実装しますmemcached（おそらくそれほど難しくはありませんが、遅延属性では注意が必要です）更新：KiokuDBはおそらくここで役立つ可能性があり、属性について読む必要があります
2. (いずれにせよ実行する必要があります) に移行しDBIx::Class、このレベルでキャッシュを実装します (DBIC はおそらくそれだけでほとんどの苦痛を取り除きます)
3. どういうわけか、オブジェクトを mod_perl プロセス内に永続化します (これを行う方法の手がかりはありません :()

あなたはこれをどのように行いますか？オブジェクトまたは ORM レベルでデータのキャッシュが優先されますか?

KiokuDB チュートリアルで言及されている弱参照とは正確には何 ですか?

それらは「通常の」参照とどう違うのですか?

scopeKiokuDB のコンセプトを正しく理解していることを確認したいと思います。

オブジェクトを db1 からロードして db2 に格納したいとします。両方のスコープを同時に「開く」必要がありますか?

私はKiokuDB、いくつかのMooseオブジェクトといくつかの単純な配列構造（ハッシュと配列）を格納するために使用します。

凝った検索やトランザクションなどは必要ありませんlookup。オブジェクトをフェッチ（）するだけの機能が必要です。また、DBの作成が完了するとすぐに、読み取り専用に設定できます。変更は行われません。

KiokuDBを使用する主な（唯一の？）理由は、オブジェクトグラフを保持するためです。

DBの合計サイズを支配する最大のオブジェクトは、比較的大きな配列を持つMooseオブジェクトです（このオブジェクトと呼びましょうlarge_obj）。以前は、large_objStorable+PerlIO::gzipまたはJSON+を使用して（単独で）保存していましPerlIO::gzipた。それはうまく機能し、結果に非常に満足しました（gzipを使用すると、ストアファイルが元のサイズの約5％に圧縮されました）。

もう1つの小さなMooseオブジェクトがあります。これは、基本的に20〜30kの小さなMooseオブジェクトの配列です。

ここで、KiokuDBに移行した後、最初に単純なハッシュバックエンドを使用し、次にそれを（Cmdを使用して）ファイルにPerlIO::gzip再度ダンプしました。large_objこれは、比較的小さい場合には非常にうまく機能しましたが、大きくなると、メモリエラーが発生しました。ハッシュバックは大きなオブジェクトには適していないと思います。

次に、推奨されるBerkeleyバックエンドを試しましたが、やり過ぎのように見えます（前述のように、すべての凝ったDB機能は本当に必要ではありません）。元のStorable+PerlIO::gzipソリューションよりも動作がはるかに遅く、はるかに多くのスペースが必要であり、大きなオブジェクトのメモリも不足します。（私は3GBのRAMubuntuを使用しています）。

Filesバックエンドも試しましたが、次のように失敗します。

スペース効率が高く、オブジェクトグラフを維持する方法でオブジェクトを保存する方法について何か提案はありますか？

シリアル化したいいくつかのMooseオブジェクトと他のいくつかの単純なハッシュオブジェクト（ハッシュ、配列）があります。

最初はシンプルなものを使いました

と

これはうまくいきました。

後で、私はとについて見つけましMooseX::StorageたKiokuDB。私はそれらを使ってそれらが持ついくつかの利点を楽しんでみましたが：

• MooseX::Storage複数回参照されるオブジェクトを再作成したようです。たとえば、シリアル化されたオブジェクトの1つにいくつかの属性が含まれており、それぞれが別のオブジェクトの同じインスタンスを参照しています。シリアル化する前は、これらの参照はすべて明らかに同じです。つまり、すべて同じオブジェクトを指しています。を使用したシリアル化/逆シリアル化の後MooseX::Storage、この1つのオブジェクトが複製され、各参照がオブジェクトの別のインスタンスを指します。MooseX::Storageオブジェクトグラフを表現するのは適切ではなく、試してみたいと言われましたKiokuDB。
• KiokuDB私はそうしましたが、自分のニーズにはやり過ぎだと感じました。DBが提供できるすべての凝ったものは必要ありません。残念ながら、私のオブジェクトの1つは非常に大きく、デフォルトを使用してシリアル化するとメモリが詰まるため、カスタムシリアライザーを作成するか、その「データ」部分を個別に保存してからコスチュームを作成する必要があるようKiokuX::Moduleです...これもかなりやり過ぎです。

だから、私は昔ながらのStorableまたはYAMLに戻ります。KiokuDB私の質問は単純です。はい、 （特にオブジェクトグラフを維持するという事実）とおそらくMooseX::Storage（後者については実際には何も見つかりませんでしたが）にもいくつかの利点があります。しかし、これらの利点は私には実際には役に立たないので、StorableまたはYAMLを使用しない理由はありますか？

言い換えれば、この方法で（Moose）オブジェクトを保存することに何か問題がありますか？それは「違法」ですか？