Can Azure Search be used as the primary database for some data?

Question

Microsoft touts Azure Search as a "cloud search", but does not necessarily say that it is a "database" or "data warehouse." He stops talking big data.

Can / azure search be used as the primary database for some data? Or should there always be some kind of “primary” data store that is “duplicated” in an azure search for a search?

If so, under what circumstances / what scenarios does it make sense to use Azure Search as the primary database?

Answer 1

Although we usually do not recommend it, you can use Azure Search as your primary repository if:

• Your application may tolerate some data inconsistency. The search in Azure is ultimately consistent.
  • When indexing data, it is not available for immediate query.
  • There is currently no mechanism for managing concurrent updates of the same document in an index.
  • When reading data using search queries, paging is not based on any snapshots, so you may get missing or duplicated documents.
• You do not need to read the entire contents of your index . The paging search in Azure Search depends on the $skip parameter, which is currently limited to a maximum of 100,000. For indexes larger than 100,000 documents, it can be very difficult to read all of your data. You will need to select some field for separation, and your readings will not have a guarantee of consistency.
• In the event of a disaster, you are fine without direct control over the process of recovering lost data. Azure Search automatically backs up your data in the event of a disaster, but there is currently no way to restore from a backup yourself or to start a backup yourself.
• You do not need to change the index definition much. Changing or deleting fields from your index currently requires re-indexing all of your data (you can add new fields without re-indexing). If Azure Search is your primary repository, the only option might be to try to read all the data from your old index into the new one, which obeys all the aforementioned consistency restrictions, $skip , etc.
• Your application’s request should match the features that Azure Search provides. Azure Search supports full-text search, faces, and a subset of the OData filter language, but it does not support such things as joins between indexes or arbitrary aggregations. If your application needs different query functions than Azure Search offers, you should consider a different NoSQL solution, such as Azure Document DB.
• Your application may suffer a high recording delay. . Because it is a search engine, not a general-purpose database, Azure Search is optimized for query performance (especially for full-text search queries). This is due to lower write performance, because each record requires a lot of work on indexing data. In particular, you get maximum write throughput by combining indexing actions (batches can contain up to 1000 indexing actions). Writing documents using a single index will result in significantly lower throughput.

Please note that many of these are areas where we want to improve Azure Search in the future for ease of management and ease of use, but it was never our goal to make Azure Search a general-purpose NoSQL database.