Skip to content

Commit

Permalink
Merge pull request #852 from MicrosoftDocs/main
Browse files Browse the repository at this point in the history
11/19/2024 AM Publish
  • Loading branch information
Taojunshen authored Nov 19, 2024
2 parents b3e7fd6 + fc236fa commit d29cb47
Show file tree
Hide file tree
Showing 43 changed files with 583 additions and 320 deletions.
117 changes: 82 additions & 35 deletions articles/cosmos-db/emulator-linux.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,13 @@ c1bb8cf53f8a mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-prev
>
> The emulator gateway endpoint is typically available on port `8081` at the address <http://localhost:8081>. To navigate to the data explorer, use the address <http://localhost:1234> in your web browser. It may take a few seconds for data explorer to be available. The gateway endpoint is typically available immediately.
> [!IMPORTANT]
> The .NET and Java SDKs don't support HTTP mode in the emulator. Since this version of the emulator starts with HTTP by default, you will need to explicitly enable HTTPS when starting the container (see below). For the Java SDK, you will also need to [install certificates](#installing-certificates-for-java-sdk).
>
> ```bash
> docker run --detach --publish 8081:8081 --publish 1234:1234 mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview --protocol https
> ```
## Docker commands
The following table summarizes the available Docker commands for configuring the emulator. This table details the corresponding arguments, environment variables, allowed values, default settings, and descriptions of each command.
Expand All @@ -75,63 +82,103 @@ The following table summarizes the available Docker commands for configuring the
This emulator is in active development and preview. As a result, not all Azure Cosmos DB features are supported. Some features will also not be supported in the future. This table includes the state of various features and their level of support.
| | Support |
| Feature | Support |
|---|---|
| **Create database** | ✅ Supported |
| **Read database** | ✅ Supported |
| **Delete database** | ✅ Supported |
| **Read database feed** | ✅ Supported |
| **Create database twice conflict** | ✅ Supported |
| **Batch API** | ✅ Supported |
| **Bulk API** | ✅ Supported |
| **Change Feed** | ⚠️ Not yet implemented |
| **Create and read document with utf data** | ✅ Supported |
| **Create collection** | ✅ Supported |
| **Read collection** | ✅ Supported |
| **Update collection** | ✅ Supported |
| **Delete collection** | ✅ Supported |
| **Read collection feed** | ✅ Supported |
| **Create collection twice conflict** | ✅ Supported |
| **Create collection with custom index policy** | ✅ Supported |
| **Create collection with ttl expiration** | ✅ Supported |
| **Create partitioned collection** | ✅ Supported |
| **Get and change collection performance** | ✅ Supported |
| **Create collection with custom index policy** | ⚠️ Not yet implemented |
| **Create collection with ttl expiration** | ⚠️ Not yet implemented |
| **Create database** | ✅ Supported |
| **Create database twice conflict** | ✅ Supported |
| **Create document** | ✅ Supported |
| **Read document** | ✅ Supported |
| **Update document** | ✅ Supported |
| **Patch document** | ✅ Supported |
| **Create partitioned collection** | ⚠️ Not yet implemented |
| **Delete collection** | ✅ Supported |
| **Delete database** | ✅ Supported |
| **Delete document** | ✅ Supported |
| **Read document feed** | ✅ Supported |
| **Get and change collection performance** | ⚠️ Not yet implemented |
| **Insert large document** | ✅ Supported |
| **Create and read document with utf data** | ✅ Supported |
| **Query with sql query spec** | ✅ Supported |
| **Query with equality** | ✅ Supported |
| **Query with and filter and projection** | ⚠️ Not yet implemented |
| **Patch document** | ✅ Supported |
| **Query partitioned collection in parallel** | ⚠️ Not yet implemented |
| **Query with aggregates** | ⚠️ Not yet implemented |
| **Query with and filter** | ⚠️ Not yet implemented |
| **Query with and filter and projection** | ⚠️ Not yet implemented |
| **Query with equality** | ✅ Supported |
| **Query with equals on id** | ✅ Supported |
| **Query with inequality** | ⚠️ Not yet implemented |
| **Query with range operators on numbers** | ⚠️ Not yet implemented |
| **Query with range operators on strings** | ⚠️ Not yet implemented |
| **Query with range operators date times** | ⚠️ Not yet implemented |
| **Query with joins** | ⚠️ Not yet implemented |
| **Query with order by** | ✅ Supported |
| **Query with order by for partitioned collection** | ⚠️ Not yet implemented |
| **Query with order by numbers** | ✅ Supported |
| **Query with order by strings** | ⚠️ Not yet implemented |
| **Query with aggregates** | ⚠️ Not yet implemented |
| **Query with paging** | ⚠️ Not yet implemented |
| **Query with range operators date times** | ⚠️ Not yet implemented |
| **Query with range operators on numbers** | ⚠️ Not yet implemented |
| **Query with range operators on strings** | ⚠️ Not yet implemented |
| **Query with single join** | ⚠️ Not yet implemented |
| **Query with string math and array operators** | ⚠️ Not yet implemented |
| **Query with subdocuments** | ⚠️ Not yet implemented |
| **Query with joins** | ⚠️ Not yet implemented |
| **Query with two joins** | ⚠️ Not yet implemented |
| **Query with two joins and filter** | ⚠️ Not yet implemented |
| **Query with single join** | ⚠️ Not yet implemented |
| **Query with string math and array operators** | ⚠️ Not yet implemented |
| **Query with paging** | ⚠️ Not yet implemented |
| **Query partitioned collection in parallel** | ⚠️ Not yet implemented |
| **Query with order by for partitioned collection** | ⚠️ Not yet implemented |
| **Stored procedure** | ❌ Not planned |
| **Read collection** | ✅ Supported |
| **Read collection feed** | ⚠️ Not yet implemented |
| **Read database** | ✅ Supported |
| **Read database feed** | ⚠️ Not yet implemented |
| **Read document** | ✅ Supported |
| **Read document feed** | ✅ Supported |
| **Replace document** | ✅ Supported |
| **Request Units** | ⚠️ Not yet implemented |
| **Stored procedures** | ❌ Not planned |
| **Triggers** | ❌ Not planned |
| **UDFs** | ❌ Not planned |
| **Update collection** | ⚠️ Not yet implemented |
| **Update document** | ✅ Supported |
## Limitations
In addition to features not yet supported or not planned, the following list includes current limitations of the emulator.
- The .NET SDK for Azure Cosmos DB doesn't support bulk execution in the emulator.
- The .NET SDK doesn't support HTTP mode in the emulator.
- The .NET and Java SDKs don't support HTTP mode in the emulator.
## Installing certificates for Java SDK
When using the [Java SDK for Azure Cosmos DB](./nosql/sdk-java-v4.md) with this version of the emulator in https mode, it is necessary to install it's certificates to your local Java trust store.
### Get certificate
In a `bash` window, run the following:
```bash
# If the emulator was started with /AllowNetworkAccess, replace localhost with the actual IP address of it:
EMULATOR_HOST=localhost
EMULATOR_PORT=8081
EMULATOR_CERT_PATH=/tmp/cosmos_emulator.cert
openssl s_client -connect ${EMULATOR_HOST}:${EMULATOR_PORT} </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > $EMULATOR_CERT_PATH
```
### Install certificate
Navigate to the directory of your java installation where `cacerts` file is located (replace below with correct directory):
```bash
cd "C:/Program Files/Eclipse Adoptium/jdk-17.0.10.7-hotspot/bin"
```
Import the cert (you may be asked for a password, the default value is "changeit"):
```bash
keytool -cacerts -importcert -alias cosmos_emulator -file $EMULATOR_CERT_PATH
```
If you get an error because the alias already exists, delete it and then run the above again:
```bash
keytool -cacerts -delete -alias cosmos_emulator
```
## Reporting issues
Expand Down
55 changes: 55 additions & 0 deletions articles/cosmos-db/how-to-configure-nsp.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
---
title: Configure Network Security Perimeter for an Azure Cosmos DB account
description: Learn how to secure your Cosmos DB account using Network Service Perimeter.
ms.service: azure-cosmos-db
ms.topic: how-to
ms.date: 11/20/2024
ms.author: iriaosara
author: iriaosara
---

# Configure Network Security Perimeter for an Azure Cosmos DB account
[!INCLUDE[NoSQL](includes/appliesto-nosql.md)]

This article explains how to configure Network Security Perimeter on your Azure Cosmos DB account.

> [!IMPORTANT]
> Network Security Perimeter is in public preview.
> This feature is provided without a service level agreement.
> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
## Feature overview
Network administrators can define a network isolation boundary for their PaaS services, which allows communication between their Azure Cosmos DB account and Keyvault, SQL, and other services using Azure Network Security Perimeter. Securing public access on Azure Service can be accomplished in several ways:

- Securing inbound connections: Restrict public exposure of your Azure Cosmos DB account by explicitly granting ingress access to resources inside the perimeter. By default, access from unauthorized networks is denied, and access from private endpoints into the perimeter or resources in a subscription can be configured.
- Securing service-to-service communication: All resources inside the perimeter can communicate with any other resources within the perimeter, preventing data exfiltration.
- Securing outbound connections: If Network Security Perimeter doesn't manage the destination tenant, it blocks access when attempting to copy data from one tenant to another. Access is granted based on FQDN or access from other network perimeters; all other access attempts are denied.

:::image type="content" source="./media/network-service-perimeter/nsp-overview.png" alt-text="Screenshot showing network service perimeter.":::

All of these communications are taken care of automatically once Network Security Perimeter is set up, and users don't have to manage them. Instead of setting up a private endpoint for each resource to enable communication or configure virtual network, Network Security Perimeter at the top level enables this functionality.

> [!NOTE]
> Azure Network security perimeter complements what we currently have in place today, including private endpoint, which allows access to a private resource within the perimeter, and VNet injection, which enables managed VNet offerings to access resources within the perimeter.
> We currently do not support the combination of network security perimeter, customer-managed keys (CMK), and log store features. If you need to perform restores on a CMK with a network security perimeter account, you'll temporarily need to relax the perimeter settings in the key vault to allow your Cosmos DB account access to the key.
## Getting started
> [!IMPORTANT]
> Before setting up a network security perimeter [create a managed identity in Azure](./how-to-setup-managed-identity.md#add-a-user-assigned-identity).
* In the Azure portal, search for **network security perimeters** in the resource list and select **Create +**.
* From the list of resources, select the resources that you want to associate with the perimeter.
* Add an inbound access rule, the source type can be either an IP address or a subscription.
* Add outbound access rules to allow resources inside the perimeter to connect to the internet and resources outside of the perimeter.

In cases where you have existing Azure Cosmos DB account and looking to add security perimeter:
* Select **Networking** from the **Settings**

:::image type="content" source="./media/network-service-perimeter/add-nsp.png" alt-text="Screenshot showing how to add NSP to an Azure resource.":::

* Then select **Associate NSP** to associate this resource with your network security perimeter to enable communication with other Azure resources in the same perimeter while restricting public access to only allow the connections you specify.

## Next steps

* Overview of [network service perimeter](https://aka.ms/networksecurityperimeter)
* Learn to monitor with [diagnostic logs in network security perimeter](https://aka.ms/networksecurityperimeter)
6 changes: 3 additions & 3 deletions articles/cosmos-db/index-policy.md
Original file line number Diff line number Diff line change
Expand Up @@ -159,14 +159,14 @@ Here are some rules for included and excluded paths precedence in Azure Cosmos D
| **`diskANN`** | Creates an index based on DiskANN for fast and efficient approximate search. | 4096 |

A few points to note:
- The `flat` and `quantizedFlat` index types apply Azure Cosmos DB's index to store and read each vector when performing a vector search. Vector searches with a `flat` index are brute-force searches and produce 100% accuracy or recall. That is, it's guaranteed to find the most similar vectors in the dataset. However, there's a limitation of `505` dimensions for vectors on a flat index.
- The `flat` and `quantizedFlat` index types apply Azure Cosmos DB's index to store and read each vector when performing a vector search. Vector searches with a `flat` index are brute-force searches and produce 100% accuracy or recall. That is, it's guaranteed to find the most similar vectors in the dataset. However, there's a limitation of `505` dimensions for vectors on a flat index.

- The `quantizedFlat` index stores quantized (compressed) vectors on the index. Vector searches with `quantizedFlat` index are also brute-force searches, however their accuracy might be slightly less than 100% since the vectors are quantized before adding to the index. However, vector searches with `quantized flat` should have lower latency, higher throughput, and lower RU cost than vector searches on a `flat` index. This is a good option for scenarios where you're using query filters to narrow down the vector search to a relatively small set of vectors, and high accuracy is required.

- The `diskANN` index is a separate index defined specifically for vectors applying [DiskANN](https://www.microsoft.com/research/publication/diskann-fast-accurate-billion-point-nearest-neighbor-search-on-a-single-node/), a suite of high performance vector indexing algorithms developed by Microsoft Research. DiskANN indexes can offer some of the lowest latency, highest throughput, and lowest RU cost queries, while still maintaining high accuracy. However, since DiskANN is an approximate nearest neighbors (ANN) index, the accuracy might be lower than `quantizedFlat` or `flat`.

The `diskANN` and `quantizedFlat` indexes can take optional index build parameters that can be used to tune the accuracy versus latency trade-off that applies to every Approximate Nearest Neighbors vector index.
- `quantizationByteSize`: Sets the size (in bytes) for product quantization. Min=1, Default=dynamic (system decides), Max=512. Setting this larger may result in higher accuracy vector searches at expense of higher RU cost and higher latency. This applies to both `quantizedFlat` and `DiskANN` index types.
- `quantizationByteSize`: Sets the size (in bytes) for product quantization. Min=1, Default=dynamic (system decides), Max=512. Setting this larger may result in higher accuracy vector searches at expense of higher RU cost and higher latency. This applies to both `quantizedFlat` and `DiskANN` index types.
- `indexingSearchListSize`: Sets how many vectors to search over during index build construction. Min=10, Default=100, Max=500. Setting this larger may result in higher accuracy vector searches at the expense of longer index build times and higher vector ingest latencies. This applies to `DiskANN` indexes only.

Here's an example of an indexing policy with a vector index:
Expand Down Expand Up @@ -494,7 +494,7 @@ WHERE r.familyname = 'Anderson' AND ch.age > 20
A container's indexing policy can be updated at any time [by using the Azure portal or one of the supported SDKs](how-to-manage-indexing-policy.md). An update to the indexing policy triggers a transformation from the old index to the new one, which is performed online and in-place (so no extra storage space is consumed during the operation). The old indexing policy is efficiently transformed to the new policy without affecting the write availability, read availability, or the throughput provisioned on the container. Index transformation is an asynchronous operation, and the time it takes to complete depends on the provisioned throughput, the number of items and their size. If multiple indexing policy updates have to be made, it's recommended to do all the changes as a single operation in order to have the index transformation complete as quickly as possible.

> [!IMPORTANT]
> Index transformation is an operation that consumes [request units](request-units.md).
> Index transformation is an operation that consumes [request units](request-units.md) and updating the index policy is an RU bound operation. If any indexing term is missed, the customer will see queries consuming more overall RUs.
> [!NOTE]
> You can track the progress of index transformation in the [Azure portal](how-to-manage-indexing-policy.md#use-the-azure-portal) or by [using one of the SDKs](how-to-manage-indexing-policy.md#dotnet-sdk).
Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 2 additions & 0 deletions articles/cosmos-db/mongodb/vcore/TOC.yml
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,8 @@
href: tutorial-nodejs-web-app.md
- name: Concepts
items:
- name: Autoscale
href: autoscale.md
- name: Free tier
href: free-tier.md
- name: Burstable tier
Expand Down
Loading

0 comments on commit d29cb47

Please sign in to comment.