...
Configuring common parameters
The following parameters are common for both the Analytics Record Store and the Analytics File System
Data purging parameters
| Parameter | Description | Default Value |
|---|---|---|
<purging-enable> | This parameter specifies whether the functionality to purge data from event tables is enabled or not. | false |
<cron-expression> | A regex expression to select the tables from which data should be purged. | 0 0 0 * * ? |
<purge-include-tables> | A list of event tables from which data should be purged can be defined as subelements of this element. | |
<data-retention-days> | The number of days for which the data should be retained in the event tables that were selected to have their data purged. All the data in these tables are cleared once the number of days that equal the value specified for this parameter have elapsed. | 365 |
...
| Parameter | Description | Default Value | ||
|---|---|---|---|---|
<analytics-lucene-analyzer> | The implementation of the Analytics Lucene Analyzer is defined as a subelement of this parameter. e.g., <implementation>org.apache.lucene.analysis.standard.StandardAnalyzer</implementation> | |||
<indexingThreadCount> | The maximum number of threads used for indexing per node. When | -1 | ||
<shardCount> | The number of index shards the server should maintain per cluster. This fine tunes the scaling nature of the indexing cluster.
| 6 | ||
<shardIndexRecordBatchSize> | The number of batch index records the indexing node should process per each indexing thread at a given time. An index record contains data of a record batch inserted in a single put operation. This batch can be as high as the event receiver queue data size, which is 10MB by default. Therefore, the highest amount of in-memory record data that an indexing processing thread can have is 10MB * 100. This parameter should be configured to change the maximum amount of memory available to the indexing node based on your requirement. The above implementations can be done by general users and can be plugged in at-will to the server. And allows implementors to provide new, as well as special wrapper implementations on top of existing implementations to provide additional enhanced features such as data encryption, custom auditing etc.. The above two interfaces can be found in | 100 |
Implementation with different database types
For detailed information on configuring a record store with each database type, see the following topics.
...