Explore topic-wise InterviewSolutions in Current Affairs.

No, the COST of running your APP on AZURE Cosmos DB is the same as it was before.

No, the cost of running your app on Azure Cosmos DB is the same as it was before.

There are no changes to MAKE. Classes, NAMESPACES, and NuGet package names have not CHANGED. As always, we recommend that you keep your SDKs up to date to TAKE advantage of the latest features and improvements.

There are no changes to make. Classes, namespaces, and NuGet package names have not changed. As always, we recommend that you keep your SDKs up to date to take advantage of the latest features and improvements.

You don't NEED to make any CHANGES all. Your DocumentDB RESOURCES are now Azure Cosmos DB resources, and there was no interruption in the service when this move occurred.

You don't need to make any changes all. Your DocumentDB resources are now Azure Cosmos DB resources, and there was no interruption in the service when this move occurred.

• Azure Cosmos DB is the next big leap in globally distributed, at-SCALE cloud databases. As a DocumentDB customer, you now have access to the breakthrough system and capabilities offered by Azure Cosmos DB.
• Azure Cosmos DB started as “Project Florence” in 2010 to address the pain points faced by developers in building large-scale applications inside Microsoft. The challenges of building globally distributed apps are not unique to Microsoft, so we made the first generation of this technology AVAILABLE in 2015 to Azure developers in the form of Azure DocumentDB.
• Since that time, we’ve added new features and introduced significant new capabilities. Azure Cosmos DB is the result. As a part of this release, DocumentDB customers, with their data, AUTOMATICALLY and seamlessly become Azure Cosmos DB customers. These capabilities are in the areas of the core database engine, as well as global distribution, elastic scalability, and industry-leading, comprehensive SLAs. Specifically, we have evolved the Azure Cosmos DB database engine to efficiently map all popular data models, type systems, and APIs to the underlying data model of Azure Cosmos DB.
• The current developer-facing manifestation of this work is the new support for Gremlin and Table storage APIs. And this is just the beginning. We plan to add other popular APIs and newer data models over time, with more advances in performance and storage at global scale.
• It is important to point out that the DocumentDB SQL dialect has always been just one of the many APIs that the underlying Azure Cosmos DB can support. For developers who USE a fully managed service such as Azure Cosmos DB, the only interface to the service is the APIs that are exposed by the service. Nothing really changes for existing DocumentDB customers. In Azure Cosmos DB, you get exactly the same SQL API that DocumentDB offers. And now (and in the future), you can access other previously INACCESSIBLE capabilities
• Another manifestation of our continued work is the extended foundation for global and elastic scalability of throughput and storage. We have made several foundational enhancements to the global distribution subsystem. One of the many such developer-facing features is the Consistent Prefix consistency model, which makes a total five well-defined consistency models. We will release many more interesting capabilities as they mature.

The APACHE CASSANDRA API provides the same CQL functionality as Apache Cassandra. We do PLAN to look into feasibility of supporting VARIOUS CAPABILITIES in future.

The Apache Cassandra API provides the same CQL functionality as Apache Cassandra. We do plan to look into feasibility of supporting various capabilities in future.

Yes, all ATTRIBUTES of an ENTITY are indexed by DEFAULT by AZURE Cosmos DB. 

Yes, all attributes of an entity are indexed by default by Azure Cosmos DB. 

The AZURE Cosmos DB Cassandra API borrows from the globally distributed platform of Azure Cosmos DB. To ENSURE that your APPLICATION can TOLERATE DATACENTER downtime, enable at least one more region for the account in the Azure Cosmos DB portal developing with multi-region Azure Cosmos DB accounts. You can set the priority of the region by using the portal developing with multi-region Azure Cosmos DB accounts.

You can add as many regions as you want for the account and control where it can fail over to by providing a failover priority. To use the database, you need to provide an application there too. When you do so, your customers will not experience downtime.

The Azure Cosmos DB Cassandra API borrows from the globally distributed platform of Azure Cosmos DB. To ensure that your application can tolerate datacenter downtime, enable at least one more region for the account in the Azure Cosmos DB portal developing with multi-region Azure Cosmos DB accounts. You can set the priority of the region by using the portal developing with multi-region Azure Cosmos DB accounts.

You can add as many regions as you want for the account and control where it can fail over to by providing a failover priority. To use the database, you need to provide an application there too. When you do so, your customers will not experience downtime.

Azure COSMOS DB provides TWO FREE full backups taken at four hours interval TODAY across all APIS. This ensures you do not need to setup a backup schedule etc. If you want to modify retention and frequency, send an email to askcosmosdbcassandra@microsoft.com or raise a support case. Information about backup capability is provided in the Automatic online backup and restore with Azure Cosmos DB article.

Azure Cosmos DB provides two free full backups taken at four hours interval today across all APIs. This ensures you do not need to setup a backup schedule etc. If you want to modify retention and frequency, send an email to askcosmosdbcassandra@microsoft.com or raise a support case. Information about backup capability is provided in the Automatic online backup and restore with Azure Cosmos DB article.

No, during PREVIEW SSTABLE LOADER is not SUPPORTED.

No, during preview sstable loader is not supported.

Yes, you can USE regular SYNTAX to create COMPOSITE PARTITION KEY.

Yes, you can use regular syntax to create composite partition key.

Azure Cosmos DB is a platform service that helps you increase productivity and not worry about managing and monitoring infrastructure. You just need to take care of THROUGHPUT which is available on portal METRICS to find if you are getting THROTTLED and increase or decrease that throughput. Monitor SLAs. Use Metrics Use Diagnostic LOGS.

Azure Cosmos DB is a platform service that helps you increase productivity and not worry about managing and monitoring infrastructure. You just need to take care of throughput which is available on portal metrics to find if you are getting throttled and increase or decrease that throughput. Monitor SLAs. Use Metrics Use Diagnostic logs.

YES, TTL is SUPPORTED.

Yes, TTL is supported.

Azure COSMOS DB provides PERFORMANCE for reads/writes and throughput without need for touching any of the configuration SETTINGS and accidently MANIPULATING them.

Azure Cosmos DB provides performance for reads/writes and throughput without need for touching any of the configuration settings and accidently manipulating them.

Azure COSMOS DB provides global distribution out of the box for availability and low latency REASONS. You do not need to setup REPLICAS etc. All writes are ALWAYS durably quorum committed in a any region where you write while providing performance GUARANTEES.

Azure Cosmos DB provides global distribution out of the box for availability and low latency reasons. You do not need to setup replicas etc. All writes are always durably quorum committed in a any region where you write while providing performance guarantees.

Apache Cassandra API is a platform service which makes capacity planning, RESPONDING to the elasticity demands for throughput & storage a breeze. With Azure Cosmos DB you provision throughput you need. Then you can SCALE it up and down any number of times through the day without worrying about adding/deleting nodes or MANAGING them. This IMPLIES you do not need to use the node, cluster management tool too.

Apache Cassandra API is a platform service which makes capacity planning, responding to the elasticity demands for throughput & storage a breeze. With Azure Cosmos DB you provision throughput you need. Then you can scale it up and down any number of times through the day without worrying about adding/deleting nodes or managing them. This implies you do not need to use the node, cluster management tool too.

Apache Cassandra API of Azure Cosmos DB is a platform service. It provides protocol level compatibilty for executing operations. It hides away the COMPLEXITY of management, monitoring and configuration. As a developer/user you do not need to worry about availability, tombstones, key cache, row cache, bloom filter and multitude of other settings. Azure Cosmos DB's Apache Cassandra API focuses on PROVIDING read and write performance that you require WITHOUT the overhead of configuration and management.

Apache Cassandra API of Azure Cosmos DB is a platform service. It provides protocol level compatibilty for executing operations. It hides away the complexity of management, monitoring and configuration. As a developer/user you do not need to worry about availability, tombstones, key cache, row cache, bloom filter and multitude of other settings. Azure Cosmos DB's Apache Cassandra API focuses on providing read and write performance that you require without the overhead of configuration and management.

The STORAGE CAPACITY is automatically managed and INCREASES as you push in more data. So you can confidently import as much data as you NEED without managing and provisioning nodes, ETC.

The storage capacity is automatically managed and increases as you push in more data. So you can confidently import as much data as you need without managing and provisioning nodes, etc.

Azure Cosmos DB is resource governed system for both DATA and CONTROL plane activities. Containers like collections, tables are runtime entities which are provisioned for given THROUGHPUT capacity. The creation of these containers in quick SUCCESSION is not expected activity and throttled. If you have tests which drop/create tables immediately - please try to SPACE them out.

Azure Cosmos DB is resource governed system for both data and control plane activities. Containers like collections, tables are runtime entities which are provisioned for given throughput capacity. The creation of these containers in quick succession is not expected activity and throttled. If you have tests which drop/create tables immediately - please try to space them out.

YES, it is possible to CRETE multiple tables with Apache CASSANDRA API. Each of those tables is treated as unit for throughput and storage.

Yes, it is possible to Crete multiple tables with Apache Cassandra API. Each of those tables is treated as unit for throughput and storage.

Azure Cosmos DB can store unlimited data by scaling out the storage. This is independent of the throughput. Yes you can always just use Cassandra API to store and retrieve key/values by specifying right primary/partition key. These individual KEYS get their own LOGICAL partition and SIT atop physical partition WITHOUT issues.

Azure Cosmos DB can store unlimited data by scaling out the storage. This is independent of the throughput. Yes you can always just use Cassandra API to store and retrieve key/values by specifying right primary/partition key. These individual keys get their own logical partition and sit atop physical partition without issues.

Azure Cosmos DB is a SLA-based system that provides unlimited SCALE, with GUARANTEES for latency, throughput, availability, and consistency. It's Cassandra API too allows unlimited storage of data. This unlimited storage is based on horizontal scaleout of data using partitioning as the key concept. The partitioning concept is well explained in the Partition and scale in Azure Cosmos DB article.

The 10-GB LIMIT on the NUMBER of entities or items per logical partition you should ADHERE to. To ensure that your application scales well, we recommend that you not create a hot partition by storing all information in one partition and querying it. This error can only come if you data is skewed - that is you have lot of data for one partition key - i.e., more than 10 GB. You can find the distribution of data using the storage portal. Way to fix this error is to recreate the table and choose a granular primary (partition key), which allows better distribution of data.

Azure Cosmos DB is a SLA-based system that provides unlimited scale, with guarantees for latency, throughput, availability, and consistency. It's Cassandra API too allows unlimited storage of data. This unlimited storage is based on horizontal scaleout of data using partitioning as the key concept. The partitioning concept is well explained in the Partition and scale in Azure Cosmos DB article.

The 10-GB limit on the number of entities or items per logical partition you should adhere to. To ensure that your application scales well, we recommend that you not create a hot partition by storing all information in one partition and querying it. This error can only come if you data is skewed - that is you have lot of data for one partition key - i.e., more than 10 GB. You can find the distribution of data using the storage portal. Way to fix this error is to recreate the table and choose a granular primary (partition key), which allows better distribution of data.

Yes, the partition key is used to place the entity in RIGHT location. In Azure COSMOS DB it is used to FIND right LOGICAL partition that is stored on a physical partition. The partitioning concept is well explained in the Partition and scale in Azure Cosmos DB article. The essential take away here is that a logical partition should not exceed the 10 GB limit TODAY.

Yes, the partition key is used to place the entity in right location. In Azure Cosmos DB it is used to find right logical partition that is stored on a physical partition. The partitioning concept is well explained in the Partition and scale in Azure Cosmos DB article. The essential take away here is that a logical partition should not exceed the 10 GB limit today.

Azure Cosmos DB provides guarantees for performance and latency, with upper bounds on operation. This guarantee is possible when the engine can enforce governance on the tenant's operations. This is possible based on setting the throughput, which ensures that you GET the guaranteed throughput and latency, because platform reserves this capacity and guarantees operation success. When you exceed this capacity you get overloaded error message indicating your capacity was exceeded. 0x1001 Overloaded: the request cannot be processed because "Request Rate is large". At this juncture it is essential to see what operations and their volume causes this issue. You can get an idea about consumed capacity exceeding the provisioned capacity with METRICS on the portal. Then you need to ensure capacity is consumed nearly equally across all underlying partitions. If you see most of the throughput is consumed by one partition, you have SKEW of workload.

Metrics are available that SHOW you how throughput is USED over hours, days, and per seven days, across partitions or in aggregate.

Azure Cosmos DB provides guarantees for performance and latency, with upper bounds on operation. This guarantee is possible when the engine can enforce governance on the tenant's operations. This is possible based on setting the throughput, which ensures that you get the guaranteed throughput and latency, because platform reserves this capacity and guarantees operation success. When you exceed this capacity you get overloaded error message indicating your capacity was exceeded. 0x1001 Overloaded: the request cannot be processed because "Request Rate is large". At this juncture it is essential to see what operations and their volume causes this issue. You can get an idea about consumed capacity exceeding the provisioned capacity with metrics on the portal. Then you need to ensure capacity is consumed nearly equally across all underlying partitions. If you see most of the throughput is consumed by one partition, you have skew of workload.

Metrics are available that show you how throughput is used over hours, days, and per seven days, across partitions or in aggregate.

Azure COSMOS DB SETS default throughput for your container based on where you create the table from - portal or CQL. Azure Cosmos DB provides guarantees for PERFORMANCE and latency, with upper bounds on operation. This guarantee is possible when the ENGINE can enforce governance on the tenant's operations. Setting throughput ensures that you get the guaranteed throughput and latency, because the platform RESERVES this capacity and guarantees operation success. You can elastically change throughput to benefit from the seasonality of your application and save costs.

Azure Cosmos DB sets default throughput for your container based on where you create the table from - portal or CQL. Azure Cosmos DB provides guarantees for performance and latency, with upper bounds on operation. This guarantee is possible when the engine can enforce governance on the tenant's operations. Setting throughput ensures that you get the guaranteed throughput and latency, because the platform reserves this capacity and guarantees operation success. You can elastically change throughput to benefit from the seasonality of your application and save costs.

To GET STARTED, complete the Graph API quick-start ARTICLE.

To get started, complete the Graph API quick-start article.

Yes, we plan to ADD other MECHANISMS for query in the future.

Yes, we plan to add other mechanisms for query in the future.

You can USE an EXTENSION library to apply the FUNCTIONALITY of Graph API (Preview). This library is CALLED Microsoft Azure Graphs, and it is available on NuGet.

You can use an extension library to apply the functionality of Graph API (Preview). This library is called Microsoft Azure Graphs, and it is available on NuGet.

Azure Cosmos DB is an SLA-based SYSTEM that provides LATENCY, THROUGHPUT, AVAILABILITY, and consistency guarantees. Because it is a provisioned system, it reserves resources to guarantee these requirements. The rapid rate of creation of tables is detected and throttled. We recommend that you look at the rate of creation of tables and lower it to less than 5 per minute.Remember that the Table API is a provisioned system. The moment you provision it, you will begin to pay for it.

Azure Cosmos DB is an SLA-based system that provides latency, throughput, availability, and consistency guarantees. Because it is a provisioned system, it reserves resources to guarantee these requirements. The rapid rate of creation of tables is detected and throttled. We recommend that you look at the rate of creation of tables and lower it to less than 5 per minute.Remember that the Table API is a provisioned system. The moment you provision it, you will begin to pay for it.

Azure Table STORAGE and Azure COSMOS DB Table API use the same SDKs so most of the errors will be the same.

Azure Table storage and Azure Cosmos DB Table API use the same SDKs so most of the errors will be the same.

YES. Because the surface area of the Table API is SIMILAR to that of the Azure Table storage SDK, the partition key provides an efficient way to distribute the data. The row key is unique within that partition. The row key NEEDS to be present and can't be null as in the standard SDK. The length of RowKey is 255 bytes and the length of Partition Key is 1 KB.

Yes. Because the surface area of the Table API is similar to that of the Azure Table storage SDK, the partition key provides an efficient way to distribute the data. The row key is unique within that partition. The row key needs to be present and can't be null as in the standard SDK. The length of RowKey is 255 bytes and the length of Partition Key is 1 KB.

Azure COSMOS DB is an SLA-based system that provides unlimited scale, with guarantees for latency, throughput, availability, and consistency. To ensure guaranteed premium performance, make sure that your data size and index are manageable and scalable. The 10-GB limit on the number of entities or items per partition key is to ensure that we provide GREAT lookup and query performance. To ensure that your APPLICATION scales WELL, EVEN for Azure Storage, we recommend that you not create a hot partition by storing all information in one partition and querying it.

Azure Cosmos DB is an SLA-based system that provides unlimited scale, with guarantees for latency, throughput, availability, and consistency. To ensure guaranteed premium performance, make sure that your data size and index are manageable and scalable. The 10-GB limit on the number of entities or items per partition key is to ensure that we provide great lookup and query performance. To ensure that your application scales well, even for Azure Storage, we recommend that you not create a hot partition by storing all information in one partition and querying it.

Azure Cosmos DB is DESIGNED to be a globally distributed, SLA-based system with guarantees for availability, latency, and throughput. When you reserve throughput in Azure Cosmos DB, it is GUARANTEED, unlike the throughput of other SYSTEMS. Azure Cosmos DB provides ADDITIONAL capabilities that customers have requested, such as SECONDARY indexes and global distribution.

Azure Cosmos DB is designed to be a globally distributed, SLA-based system with guarantees for availability, latency, and throughput. When you reserve throughput in Azure Cosmos DB, it is guaranteed, unlike the throughput of other systems. Azure Cosmos DB provides additional capabilities that customers have requested, such as secondary indexes and global distribution.

Azure COSMOS DB sets a default throughput for your container if you do not provide one in the app.config file or via the portal.

Azure Cosmos DB provides GUARANTEES for performance and latency, with upper bounds on operation. This guarantee is possible when the engine can enforce governance on the tenant's OPERATIONS. Setting Table Throughput ensures that you get the guaranteed throughput and latency, because the platform RESERVES this CAPACITY and guarantees operational success.

By using the throughput specification, you can elastically change it to benefit from the seasonality of your application, meet the throughput needs, and save costs.

Azure Cosmos DB sets a default throughput for your container if you do not provide one in the app.config file or via the portal.

Azure Cosmos DB provides guarantees for performance and latency, with upper bounds on operation. This guarantee is possible when the engine can enforce governance on the tenant's operations. Setting Table Throughput ensures that you get the guaranteed throughput and latency, because the platform reserves this capacity and guarantees operational success.

By using the throughput specification, you can elastically change it to benefit from the seasonality of your application, meet the throughput needs, and save costs.

If the request RATE exceeds the capacity of the provisioned THROUGHPUT for the UNDERLYING container, you GET an error, and the SDK retries the call by applying the retry policy.

If the request rate exceeds the capacity of the provisioned throughput for the underlying container, you get an error, and the SDK retries the call by applying the retry policy.

The PRICE DEPENDS on the ALLOCATED Table THROUGHPUT.

The price depends on the allocated Table Throughput.

NONE. There is no CHANGE in price for EXISTING AZURE Table storage customers.

None. There is no change in price for existing Azure Table storage customers.

Yes, if you do not override the Table THROUGHPUT via app.config and do not use a pre-created container in Azure COSMOS DB, the service CREATES a table with throughput of 400.

Yes, if you do not override the Table Throughput via app.config and do not use a pre-created container in Azure Cosmos DB, the service creates a table with throughput of 400.

Yes, you can use the Azure Cosmos DB PORTAL’s SCALE pane to scale the throughput. 

Yes, you can use the Azure Cosmos DB portal’s scale pane to scale the throughput. 

You should change Table Throughput when either of the following conditions applies:

• You're performing an extract, transform, and load (ETL) of data, or you want to UPLOAD a LOT of data in short amount of time.
• You need more throughput from the container at the back END. For example, you see that the used throughput is more than the PROVISIONED throughput, and you are getting throttled. 

You should change Table Throughput when either of the following conditions applies:

The Table API provides the same query functionality as Azure Table storage. Azure Cosmos DB ALSO supports SORTING, aggregates, geospatial query, HIERARCHY, and a wide range of built-in functions. We will provide ADDITIONAL functionality in the Table API in a future service UPDATE. 

The Table API provides the same query functionality as Azure Table storage. Azure Cosmos DB also supports sorting, aggregates, geospatial query, hierarchy, and a wide range of built-in functions. We will provide additional functionality in the Table API in a future service update. 

Yes, you can change the indexing policy by providing the index definition. For more information, see Azure Cosmos DB capabilities. You need to properly encode and escape the settings.

For the non-.NET SDKs the indexing policy can only be set in the portal at Data Explorer, navigate to the SPECIFIC table you want to change and then go to the Scale & Settings->Indexing Policy, make the desired change and then Save.

From the .NET SDK it can be submitted in the app.config file:

Copy

{

"indexing Mode": "consistent",

"automatic": TRUE,

"INCLUDED Paths": [

{

"path": "/some path",

"indexes": [

{

"kind": "RANGE",

"datatype": "Number",

"precision": -1

},

{

"kind": "Range",

"datatype": "String",

"precision": -1

} 

]

}

],

"excludedPaths": 

[

 {

"path": "/anotherpath"

 }

]

}

Yes, you can change the indexing policy by providing the index definition. For more information, see Azure Cosmos DB capabilities. You need to properly encode and escape the settings.

For the non-.NET SDKs the indexing policy can only be set in the portal at Data Explorer, navigate to the specific table you want to change and then go to the Scale & Settings->Indexing Policy, make the desired change and then Save.

From the .NET SDK it can be submitted in the app.config file:

Copy

{

"indexing Mode": "consistent",

"automatic": true,

"included Paths": [

{

"path": "/some path",

"indexes": [

{

"kind": "Range",

"datatype": "Number",

"precision": -1

},

{

"kind": "Range",

"datatype": "String",

"precision": -1

} 

]

}

],

"excludedPaths": 

[

 {

"path": "/anotherpath"

 }

]

}

Yes, Azure COSMOS DB Table API provides automatic indexing of all attributes without any schema definition. This automation frees developers to focus on the application rather than on index creation and MANAGEMENT.

Yes, Azure Cosmos DB Table API provides automatic indexing of all attributes without any schema definition. This automation frees developers to focus on the application rather than on index creation and management.

YES, all ATTRIBUTES of an ENTITY are INDEXED by DEFAULT. 

Yes, all attributes of an entity are indexed by default. 

Yes, the Table API leverages the PLATFORM of Azure Cosmos DB for BACKUPS. Backups are made AUTOMATICALLY.

Yes, the Table API leverages the platform of Azure Cosmos DB for backups. Backups are made automatically.

The Table API leverages the globally distributed platform of Azure Cosmos DB. To ensure that your application can tolerate datacenter DOWNTIME, enable at LEAST one more region for the account in the Azure Cosmos DB portal Developing with multi-region Azure Cosmos DB ACCOUNTS. You can set the priority of the region by using the portal developing with multi-region Azure Cosmos DB accounts.

You can add as many regions as you want for the account and control where it can FAIL over to by providing a failover priority. Of course, to use the database, you NEED to provide an application there too. When you do so, your customers will not experience downtime. The latest .NET client SDK is auto homing but the other SDKs are not. That is, it can detect the region that's down and automatically fail over to the new region.

The Table API leverages the globally distributed platform of Azure Cosmos DB. To ensure that your application can tolerate datacenter downtime, enable at least one more region for the account in the Azure Cosmos DB portal Developing with multi-region Azure Cosmos DB accounts. You can set the priority of the region by using the portal developing with multi-region Azure Cosmos DB accounts.

You can add as many regions as you want for the account and control where it can fail over to by providing a failover priority. Of course, to use the database, you need to provide an application there too. When you do so, your customers will not experience downtime. The latest .NET client SDK is auto homing but the other SDKs are not. That is, it can detect the region that's down and automatically fail over to the new region.

With AZURE COSMOS DB, you can set the consistency level at the container level (on the table). By using the .NET SDK, you can change the level by providing the value for Table ConsistencyLevel key in the app.config file. The possible values are: Strong, Bounded Staleness, Session, Consistent Prefix, and EVENTUAL. For more information, see Tunable data consistency levels in Azure Cosmos DB. The key idea is that you cannot set the request consistency level at more than the setting for the table. For example, you cannot set the consistency level for the table at Eventual and the request consistency level at Strong.

With Azure Cosmos DB, you can set the consistency level at the container level (on the table). By using the .NET SDK, you can change the level by providing the value for Table ConsistencyLevel key in the app.config file. The possible values are: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual. For more information, see Tunable data consistency levels in Azure Cosmos DB. The key idea is that you cannot set the request consistency level at more than the setting for the table. For example, you cannot set the consistency level for the table at Eventual and the request consistency level at Strong.

AZURE Cosmos DB commits the DATA durably in the LOCAL region and pushes the data to other regions immediately in a MATTER of milliseconds. This replication is dependent only on the round-trip time (RTT) of the datacenter. 

Azure Cosmos DB commits the data durably in the local region and pushes the data to other regions immediately in a matter of milliseconds. This replication is dependent only on the round-trip time (RTT) of the datacenter. 

YES, for information about how to benefit from the distributed nature of AZURE Cosmos DB, SEE Consistency LEVELS. Because guarantees are provided for the consistency levels, you can use them with confidence.

Yes, for information about how to benefit from the distributed nature of Azure Cosmos DB, see Consistency levels. Because guarantees are provided for the consistency levels, you can use them with confidence.

AZURE Cosmos DB PROVIDES well-reasoned trade-offs between consistency, availability, and latency. Azure Cosmos DB offers five consistency levels to Table API developers, so you can choose the right consistency model at the table level and make individual requests while querying the data. When a client connects, it can specify a consistency level. You can change the level via the consistency Level ARGUMENT of CreateCloudTableClient.

The Table API provides low-latency reads with "Read your own writes," with Bounded-staleness consistency as the default.

By default, Azure Table storage provides STRONG consistency within a region and Eventual consistency in the secondary locations.

Azure Cosmos DB provides well-reasoned trade-offs between consistency, availability, and latency. Azure Cosmos DB offers five consistency levels to Table API developers, so you can choose the right consistency model at the table level and make individual requests while querying the data. When a client connects, it can specify a consistency level. You can change the level via the consistency Level argument of CreateCloudTableClient.

The Table API provides low-latency reads with "Read your own writes," with Bounded-staleness consistency as the default.

By default, Azure Table storage provides Strong consistency within a region and Eventual consistency in the secondary locations.

To help read from the LOCAL location, use the Preferred Location KEY in the app.config file. For existing applications, the Table API THROWS an error if Location Mode is SET. Remove that CODE, because the Table API picks up this information from the app.config file.

To help read from the local location, use the Preferred Location key in the app.config file. For existing applications, the Table API throws an error if Location Mode is set. Remove that code, because the Table API picks up this information from the app.config file.