<?xml version="1.0" encoding="UTF-8"?>
<!--
~ Copyright (c) 2015, WSO2 Inc. (http://www.wso2.org) All Rights Reserved.
~
~ WSO2 Inc. licenses this file to you under the Apache License,
~ Version 2.0 (the "License"); you may not use this file except
~ in compliance with the License.
~ You may obtain a copy of the License at
~
~    http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing,
~ software distributed under the License is distributed on an
~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~ KIND, either express or implied.  See the License for the
~ specific language governing permissions and limitations
~ under the License.
-->
<analytics-dataservice-configuration>
   <!-- The name of the primary record store -->
   <primaryRecordStore>EVENT_STORE</primaryRecordStore>
   <!-- Analytics Record Store - properties related to record storage implementation -->
   <analytics-record-store name="EVENT_STORE">
      <implementation>org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRecordStore</implementation>
      <properties>
         <property name="datasource">WSO2_ANALYTICS_EVENT_STORE_DB</property>
         <property name="category">read_write_optimized</property>
      </properties>
   </analytics-record-store>
   <analytics-record-store name="EVENT_STORE_WO">
      <implementation>org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRecordStore</implementation>
      <properties>
         <property name="datasource">WSO2_ANALYTICS_EVENT_STORE_DB</property>
         <property name="category">write_optimized</property>
      </properties>
   </analytics-record-store>
   <analytics-record-store name="PROCESSED_DATA_STORE">
      <implementation>org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRecordStore</implementation>
      <properties>
         <property name="datasource">WSO2_ANALYTICS_PROCESSED_DATA_STORE_DB</property>
         <property name="category">read_write_optimized</property>
      </properties>
   </analytics-record-store>
   <!-- The data indexing analyzer implementation -->
   <analytics-lucene-analyzer>
   	<implementation>org.apache.lucene.analysis.standard.StandardAnalyzer</implementation>
   </analytics-lucene-analyzer>
   <taxonomy-writer-cache>
      <!--This can be DEFAULT or LRU. For Large taxonomies LRU is recommended. DEFAULT will cache whole taxonomy tree-->
      <cacheType>DEFAULT</cacheType>
      <!--LRUType is only valid for cacheType "LRU". It can be either STRING or HASHED. STRING guarantees the correctness/no-collision
      and HASHED does not guarantee no-collision, but uses less RAM than STRING-->
      <!--<LRUType>STRING</LRUType>-->
      <!--cacheSize is only valid for cacheType "LRU". the size is given in Bytes-->
      <!--<cacheSize>4096</cacheSize>-->
   </taxonomy-writer-cache>
   <!--Taxonomy writer's cache implementation-->
   <taxonomy-writer-cache>
       <!--This can be DEFAULT or LRU. For Large taxonomies LRU is recommended. DEFAULT will cache whole taxonomy tree-->
       <cacheType>LRU</cacheType>
       <!--LRUType is only valid for cacheType "LRU". It can be either STRING or HASHED. STRING guarantees the correctness/no-collision
       and HASHED does not guarantee no-collision, but uses less RAM than STRING-->
       <LRUType>STRING</LRUType>
       <!--cacheSize is only valid for cacheType "LRU". the size is given in Bytes-->
       <!--<cacheSize>4096</cacheSize>-->
   </taxonomy-writer-cache>

   <!--Configuration for Facet indexing,
       facet-splitter is used to split the facet hierarchy by the character given in facet-splitter
       facet-default-value is used if a null value or empty value is published to a facet field
       These values can be set in either global level, table level or field level-->
    <!--
   <facet-configuration enabled = "true">
      <facet-splitter>,</facet-splitter>
      <facet-default-value>EMPTY_FACET_VALUE!</facet-default-value>
      <tables>
         <table name="aTable">
            <facet-splitter>,</facet-splitter>
            <facet-default-value>EMPTY_FACET_VALUE!</facet-default-value>
            <facet-fields>
               <facet-field name="field1">
               </facet-field>
               <facet-field name="field2">
                  <facet-splitter>,</facet-splitter>
                  <facet-default-value>EMPTY_FACET_VALUE!</facet-default-value>
               </facet-field>
            </facet-fields>
         </table>
         <table name="anotherTable">

         </table>

      </tables>
   </facet-configuration>
   -->
   <!-- The number of index data replicas the system should keep, for H/A, this should be at least 1, e.g. the value 0 means
        there aren't any copies of the data -->
   <indexReplicationFactor>1</indexReplicationFactor>
   <!-- The number of index shards, should be equal or higher to the number of indexing nodes that is going to be working,
        ideal count being 'number of indexing nodes * [CPU cores used for indexing per node]' -->
   <shardCount>6</shardCount>
   <!-- The amount of index data (in bytes) to be processed at a time by a shard index worker. Minimum value is 1000. -->
   <shardIndexRecordBatchSize>20971520</shardIndexRecordBatchSize>
   <!-- The interval in milliseconds, which a shard index processing worker thread will sleep during index processing operations. This setting
        along with the 'shardIndexRecordBatchSize' setting can be used to increase the final index batched data amount the indexer processes
        at a given time. Usually, higher the batch data amount, higher the throughput of the indexing operations, but will have a higher latency
        of record insertion to indexing. Minimum value of this is 10, and a maximum value is 60000 (1 minute). -->
   <shardIndexWorkerInterval>1500</shardIndexWorkerInterval>
   <!-- The number of index workers to operate in the current node. This basically results in the number of execution threads created
        to do the indexing operations of the local shards. When this value is increased, the parallel I/O operations being done on the
        system grows larger. So a system which can handle parallel I/O operation could increase this, e.g. SSDs. -->
   <indexWorkerCount>1</indexWorkerCount>
   <!--Buffer size (number of messages) of the ringBuffer which is used to send indexing messages in the cluster.
    Should be a number equals to "2" to the power of n -->
   <maxIndexerCommunicatorBufferSize>1024</maxIndexerCommunicatorBufferSize>
    <!--Indexing queue cleanup threshold in bytes-->
   <indexingQueueCleanupThreshold>209715200</indexingQueueCleanupThreshold>
   <!-- Data purging related configuration -->
   <analytics-data-purging>
      <!-- Below entry will indicate purging is enable or not. If user wants to enable data purging for cluster then this property
       need to be enable in all nodes -->
      <purging-enable>false</purging-enable>
      <cron-expression>0 0 0 * * ?</cron-expression>
      <!-- Tables that need include to purging. Use regex expression to specify the table name that need include to purging.-->
      <purge-include-tables>
         <table>.*</table>
         <!--<table>.*jmx.*</table>-->
      </purge-include-tables>
      <!-- All records that insert before the specified retention time will be eligible to purge -->
      <data-retention-days>365</data-retention-days>
   </analytics-data-purging>
   <static-quorum enabled="false">
        <quorum-size>2</quorum-size>
   </static-quorum>
</analytics-dataservice-configuration>
