писец с буфером протокола и продвинутой экономией? - PullRequest
Новая
       31

писец с буфером протокола и продвинутой экономией?

2 голосов
/ 21 января 2010

У меня здесь два вопроса:

Вопрос 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?

1 Ответ

2 голосов
/ 21 января 2010

Да, структуры 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 сможет легко использовать протоколные буферы для внутреннего представления данных. Весь код RPC был сгенерирован из этих определений, и вы можете переопределить метод Log, чтобы получить произвольный объект (например, сделать его объектом Буфера протокола), но это будет так же сложно, как и выше.

Насколько мне известно, Google не имеет открытых источников ни одной распределенной системы ведения журналов. Chukwa от Yahoo / Hadoop - одна из альтернатив.

...