|
From: Bryan T. <br...@sy...> - 2010-05-10 16:32:18
|
Brian, I think that it is still too early to say whether the metadata service (a shard locator service) should inherit from the data service (a shard container service) or not. The base abstraction for both the data service and the metadata service is really a container for named B+Trees. For the data service, those B+Trees are the shard views and include a mixture of journals and index segments for each shard. For the metadata service, the B+Trees are the shard locator indices, but are not themselves sharded. Currently, the client views of the scale-out indices are written to the common interface exposed by the data services and the metadata service. For example, a key-range query directed to the metadata service will report the shard locators for a key-range of the corresponding scale-out index. The client then issues the appropriate requests to the data services on which the shards are located. In the future, we may see a lot of evolution in the metadata service. For example, there is a proposal to use a P2P gossip protocol to distribute the shard locator service across the data services. The impact of that change on the metadata service has not been mapped out in detail yet. Thanks, Bryan ________________________________ From: Brian Murphy [mailto:btm...@gm...] Sent: Monday, May 10, 2010 11:58 AM To: big...@li... Subject: [Bigdata-developers] Question on the MetadataService The implementation of the MetadataService implements IMetadataService, which extends IDataService which extends IService, ITxCommitProtocol, and IRemoteExecutor. Additionally, MetadataService also extends DataService, which extends AbstractService. After an initial examination of the MetadataService implementation, I'm wondering if all the functionality required by the IDataService interface and provided by the DataService class is really necessary for the MetadataService. Was there a reason MetadataService was made a "super service" of DataService? Thanks, Brian |