[img]http://dl.iteye.com/upload/attachment/345936/f0623906-7e05-342b-b74b-97761da59b2a.jpg[/img]
[b]StoreRepository:[/b]
A wrapper class that holds all the server's stores--storage engines, routed stores, and remote stores. The store repository holds various store types:
1. Local stores – These are the local stores used to perform reads and writes on the local node.
2. Storage Engines – These are also local, but represent the lowest level of the storage chain (no wrappers).
3. Routed Stores – Writes to these stores will be rerouted to the appropriate nodes.
4. Node Stores – These represent socket stores for writing to individual nodes.
[b]StoreEngine:[/b]
A base storage class which is actually responsible for data persistence. This interface implies all the usual responsibilities of a Store implementation, and in addition:
1. The implementation MUST throw an ObsoleteVersionException if the user attempts to put a version which is strictly before an existing version (concurrent is okay)
2. The implementation MUST increment this version number when the value is stored.
3. The implementation MUST contain an ID identifying it as part of the cluster
4. A hash value can be produced for known subtrees of a [b]StorageEngine[/b]
[b]BdbStorageEngine:[/b] A store that uses BDB for persistence
[b]InMemoryStorageEngine: [/b] A simple non-persistent, in-memory store. Useful for unit testing.
[b]MysqlStorageEngine:[/b] A StorageEngine that uses Mysql for persistence
[b]ReadOnlyStorageEngine: [/b] A read-only store that fronts a big file
[b]SerializingStorageEngine: [/b] A StorageEngine that handles serialization to bytes, transforming each request to a request to StorageEngine
[b]ViewStorageEngine: [/b] Views are transformations of other stores
[b]CompressingStore:[/b] A Store Decorator that compresses keys and values as it stores them and uncompresses them as it reads them based on the CompressionStrategy objects provided. A NoopCompressionStrategy can be used if no compression is desired for either keys or values
[b]GzipStore:[/b] A Store decorator that gzips and ungzips its contents as it stores them
[b]HttpStore:[/b] A remote store client that transmits operations via HTTP and interacts with the VoldemortHttpServer
[b]LoggingStore: [/b] A store wrapper that handles debug logging
[b]MetedataStore:[/b] MetadataStore maintains metadata for Voldemort Server. Metadata is persisted as strings in inner store for ease of readability.Metadata Store keeps a in memory write-through-cache for performance.
[b]RebootStrippingStore:[/b] The RebootstrappingStore catch all InvalidMetadataException and updates the routed store with latest cluster metadata, client rebootstrapping behavior same in DefaultStoreClient for server side routing
[b]RedirectingStore:[/b] if current server_state is MetadataStore.VoldemortState.REBALANCING_MASTER_SERVER
then before serving any client request do a remote get() call, put it locally ignoring any ObsoleteVersionException and then serve the client requests
[b]RoutedStore: [/b] A Store which multiplexes requests to different internal Stores
[b]SerializingStore:[/b] A store that transforms requests to a Store to a Store
[b]SloppyStore:[/b] A Sloppy store is a store wrapper that delegates to an inner store, and if that store fails, instead stores some slop in the first of a list of backup stores. This is a simple consistency mechanism that ensures a transient failure can be recovered from. This is intended to live on the client side and redeliver messages when a given server fails. This makes for a somewhat awkward situation when a failure occurs, though: Either we return successfully, in which case the user may believe their data is available when it is not OR we throw an exception, in which case the user may think the update will not occur though eventually it will. Our choice is to throw a special exception that the user can choose to ignore if they like In the common case, this Store will be used as one of many routed stores, so a single failure will not propagate to the user.
[b]SlopDetectingStore:[/b] A delegating store that calculates ownership and stores unowned objects in a special slop store for later delivery to their rightful owner. This store is intended to live on the server side, and check that data the server receives was properly routed.
[b]SocketStore:[/b] The client implementation of a socket store--translates each request into a network operation to be handled by the socket server on the other side.
[b]StatTrackingStore: [/b] A store wrapper that tracks basic usage statistics
[b]VersionIncrementingStore: [/b] A wrapper that increments the version on the value for puts and delegates all other operations
[b]InconsistencyResolvingStore:[/b] A Store that uses a InconsistencyResolver to eliminate some duplicates.
[b]StoreRepository:[/b]
A wrapper class that holds all the server's stores--storage engines, routed stores, and remote stores. The store repository holds various store types:
1. Local stores – These are the local stores used to perform reads and writes on the local node.
2. Storage Engines – These are also local, but represent the lowest level of the storage chain (no wrappers).
3. Routed Stores – Writes to these stores will be rerouted to the appropriate nodes.
4. Node Stores – These represent socket stores for writing to individual nodes.
[b]StoreEngine:[/b]
A base storage class which is actually responsible for data persistence. This interface implies all the usual responsibilities of a Store implementation, and in addition:
1. The implementation MUST throw an ObsoleteVersionException if the user attempts to put a version which is strictly before an existing version (concurrent is okay)
2. The implementation MUST increment this version number when the value is stored.
3. The implementation MUST contain an ID identifying it as part of the cluster
4. A hash value can be produced for known subtrees of a [b]StorageEngine[/b]
[b]BdbStorageEngine:[/b] A store that uses BDB for persistence
[b]InMemoryStorageEngine: [/b] A simple non-persistent, in-memory store. Useful for unit testing.
[b]MysqlStorageEngine:[/b] A StorageEngine that uses Mysql for persistence
[b]ReadOnlyStorageEngine: [/b] A read-only store that fronts a big file
[b]SerializingStorageEngine: [/b] A StorageEngine that handles serialization to bytes, transforming each request to a request to StorageEngine
[b]ViewStorageEngine: [/b] Views are transformations of other stores
[b]CompressingStore:[/b] A Store Decorator that compresses keys and values as it stores them and uncompresses them as it reads them based on the CompressionStrategy objects provided. A NoopCompressionStrategy can be used if no compression is desired for either keys or values
[b]GzipStore:[/b] A Store decorator that gzips and ungzips its contents as it stores them
[b]HttpStore:[/b] A remote store client that transmits operations via HTTP and interacts with the VoldemortHttpServer
[b]LoggingStore: [/b] A store wrapper that handles debug logging
[b]MetedataStore:[/b] MetadataStore maintains metadata for Voldemort Server. Metadata is persisted as strings in inner store for ease of readability.Metadata Store keeps a in memory write-through-cache for performance.
[b]RebootStrippingStore:[/b] The RebootstrappingStore catch all InvalidMetadataException and updates the routed store with latest cluster metadata, client rebootstrapping behavior same in DefaultStoreClient for server side routing
[b]RedirectingStore:[/b] if current server_state is MetadataStore.VoldemortState.REBALANCING_MASTER_SERVER
then before serving any client request do a remote get() call, put it locally ignoring any ObsoleteVersionException and then serve the client requests
[b]RoutedStore: [/b] A Store which multiplexes requests to different internal Stores
[b]SerializingStore:[/b] A store that transforms requests to a Store to a Store
[b]SloppyStore:[/b] A Sloppy store is a store wrapper that delegates to an inner store, and if that store fails, instead stores some slop in the first of a list of backup stores. This is a simple consistency mechanism that ensures a transient failure can be recovered from. This is intended to live on the client side and redeliver messages when a given server fails. This makes for a somewhat awkward situation when a failure occurs, though: Either we return successfully, in which case the user may believe their data is available when it is not OR we throw an exception, in which case the user may think the update will not occur though eventually it will. Our choice is to throw a special exception that the user can choose to ignore if they like In the common case, this Store will be used as one of many routed stores, so a single failure will not propagate to the user.
[b]SlopDetectingStore:[/b] A delegating store that calculates ownership and stores unowned objects in a special slop store for later delivery to their rightful owner. This store is intended to live on the server side, and check that data the server receives was properly routed.
[b]SocketStore:[/b] The client implementation of a socket store--translates each request into a network operation to be handled by the socket server on the other side.
[b]StatTrackingStore: [/b] A store wrapper that tracks basic usage statistics
[b]VersionIncrementingStore: [/b] A wrapper that increments the version on the value for puts and delegates all other operations
[b]InconsistencyResolvingStore:[/b] A Store that uses a InconsistencyResolver to eliminate some duplicates.
3313
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
