Microsoft Azure Search is the default search engine for Sitecore, and is where Sitecore stores the content and analytics indexes. This topic describes:
Keeping costs low
Azure Search costs depend on the number and size of the documents that are ingested into search. If you are using xDB, you can keep your document count low by disabling indexing of anonymous contact data in the Contact Segmentation index.
You must look at the SKU size for your Azure Search solution. Each SKU size has several metric limitations but the main ones you must pay attention to are storage, index count, and document count. When designing your solution, you must keep these metrics in mind and monitor them, otherwise your search costs can grow faster than you might expect. The minimum SKU size you can use with Sitecore Azure Search is S1, this is because the sizes lower than S1 are limiting (for example, Basic only allows 100 fields in an index and Free is limited to three indexes).
There is no way to upgrade your existing Azure Search service to a different tier on the fly, so it is important you plan the right service capacity upfront. When you upgrade or downgrade, you must create a new service and rebuild all of the search indexes in Sitecore.
Understanding API keys
Sitecore communicates with Azure Search through its REST API; all calls to the API use an API key as the sole mechanism for authentication. When you deploy Sitecore with the ARM templates, a key is generated automatically for you and added to the
cloud.search connection string. You can always change the key if you need to and then update the
cloud.search connection string with the new value.
Scaling with Azure Search
Azure Search can scale in two dimensions: Partitions and Replicas. You can increase the number of documents you can store with Partitions, whereas with Replicas, you can achieve high availability and increase queries per second by copying your index to a new instance of the search service. You can use one or both scaling types, depending on your scaling requirements, but keep in mind that if you add an additional scaling type, then you increase your monthly costs. You can read about service administration for Azure Search in the Microsoft Azure portal and about how to scale resource levels for query and indexing workloads in Azure Search.
Monitoring your usage and metrics
Azure Search does not provide any form of traditional logging. However, you can obtain information about your service in the Azure portal on the service dashboard, through notifications, properties, and status messages.
On the dashboard, resource monitoring is limited to the information shown on the service dashboard and the metrics that you can obtain by querying the service. On the service dashboard, in the Usage section, you can quickly determine whether partition resource levels are adequate for your application.
You can use the Azure Search metrics: Search Latency, Search queries per sec., and Throttled queries percentage, to create alerts on the Azure Search and Monitor tabs. You can also create charts on the Monitor tab.
Search traffic analytics is another monitoring tool in Azure Search that gives you visibility of your search service and unlocks insights about your users and their behavior. When you enable this feature, you can copy your search service data to a storage account of your choice. You can process and manipulate this data from your search service logs and aggregated operational metrics, for further analysis.
Refer to the Microsoft Azure documentation website for more information about monitoring, usage, and query metrics in an Azure Search service; enabling and using Search Traffic Analytics; scaling resource levels for query and indexing workloads in Azure Search, and considerations about Azure Search performance and optimization.