This is an old revision of the document!
Table of Contents
Elasticsearch Best Practice
The App Store Connect installer deploys the Big Data Service: a single node elasticsearch cluster that is employed by the App Store Connection for local data storage. The main use-cases are when the App Store Connection is configured to record process data to IP Historian, and/or record Alarm & Event data to Alarm Analysis. If significant volumes of data are stored, the server administrator should be prepared to monitor and reconfigure the Elasticseach installation to maintain performance and availability.
Elasticsearch Terminology
| Cluster | Elasticsearch is made up of a cluster of one or more nodes. The default “Big Data Service” install is composed of only a single node running on the same server as the other App Store Connect processes. |
| Node | A node is a single running instance of elasticseach. Typically one node runs per server. |
| Index | An index is where the documents are stored. |
| Document | A document is a structured data object, like a record |
| Shard | An index is made up of one or more shards. A shard is defined as either a “primary” or “replica” shard: * A primary shard is responsible for write operations (index, re-index and delete) and reads. * A replica shard is responsible only for read operations (searches and gets). Each shard is a complete set of all the data in the index. The reason for duplicating the data across multiple shards is to improve availaility and read/write througput. |
Considerations...
Server Constraints
The server hosting App Store Connect must have suitable for processing and storing data. Consider CPU, RAM, dirve size, drive type (SSD or hard disk).
Balance this against your requirements: - What are the data ingestion rates? - Are these consistant or do they vary over the course of the day? - How manu users must you support?
Sharding
The number of shards that an Elasticsearch node can support is