2

ここで 2 つの質問があります。

質問1：

-- thrift は内部クラスの機能を提供できますか? (次の例を参照してください)

――できれば、そのような機能を簡単に節約できますか？

スクライブ インターフェース (scribe/if/scribe.thrift) は次のとおりです。しかし、そのメッセージ フィールドは文字列のみであり、柔軟性が十分ではないと思います。

#!/usr/local/bin/thrift --cpp --php

##  Copyright (c) 2007-2008 Facebook
...
...
## See accompanying file LICENSE or visit the Scribe site at:
## http://developers.facebook.com/scribe/

include "fb303/if/fb303.thrift"

namespace cpp scribe.thrift

enum ResultCode
{
  OK,
  TRY_LATER
}

struct LogEntry
{
  1:  string category,
  2:  string message
}

service scribe extends fb303.FacebookService
{
  ResultCode Log(1: list<LogEntry> messages);
}

次のことができれば素晴らしいと思います（thrift自体がそのドキュメントに従って内部クラス機能を提供するかどうかさえわかりませんが、プロトコルバッファは間違いなく可能です）。

enum ResultCode
{
  OK,
  TRY_LATER
}

struct MyLogStructure {
  1: string field_name;
  2: string value;
}

struct LogEntry
{
  1:  string category,
  2:  MyLogStructure message
}

service scribe extends fb303.FacebookService
{
  ResultCode Log(1: list<LogEntry> messages);
}

質問2：

-- スクライブは内部データ表現としてプロトコル バッファを簡単に使用できますか? (あまりコードを変更しないでください)

-- 上記の質問に対する答えが「いいえ」の場合、Google はその sribe 実装をオープンソース化しましたか?

4

1 に答える 1

2

はい、Thrift構造体には他の構造体を含めることができ、定義（以下で繰り返す）は機能します。

enum ResultCode { OK, TRY_LATER }

struct MyLogStructure {
  1: string field_name;
  2: string value;
}

struct LogEntry {
  1: string category,
  2: MyLogStructure message 
}

service scribe extends fb303.FacebookService {
  ResultCode Log(1: list messages);
}

このようにScribeのインターフェースを再定義した場合、Scribeのコードを変更して、内部での処理に応じて新しい型を処理する必要がありますstring message。

もちろん、いつでもMyLogStructureオブジェクトを文字列にシリアル化して、この問題を完全に回避することができます。

いいえ、Scribeが内部データ表現としてProtocolBuffersを簡単に使用できるとは思いません。すべてのRPCコードはこれらの定義から生成されており、メソッドを再定義しLogて任意のオブジェクト（たとえば、Protocol Buffersオブジェクトにする）を取得できますが、これは上記と同じくらい難しいでしょう。

私の知る限り、Googleは分散ロギングシステムをオープンソース化していません。 Yahoo/HadoopのChukwaは1つの選択肢です。

于 2010-01-21T01:54:03.650 に答える