I am very excited to use Cosmos DB into my current application instead of Azure SQL database.
Before use Cosmos DB as backend in my current application, I have few questions in my mind those are
In my current application I used Entity framework.
And also used column encryption, dynamic data masking features.
So, if I moved to Cosmos DB instead of using Azure SQL database then how can I achieve those features by using Cosmos DB?
Documentation doesn't specify details about encryption, masking and entity framework.
Can you please tell me “is it possible to use Cosmos DB with above requirements instead of Azure SQL Database?
Entity Framework is specific to relational databases, so it doesn't fit with Cosmos DB's document store (or graph, or tables).
Regarding encryption: Cosmos DB provides encryption-at-rest, built-in. There is no per-property data-masking feature built-in; you'd have to do your own data masking.
Whether you migrate to a document (or graph, or table) store is really up to you, and whether you want to re-shape your data to fit in such a storage model, vs a relational model. No real way to answer that for you. (TL;DR you cannot just switch from relational to, say, document, without any changes, as they are fundamentally different storage concepts).
Related
I am trying to figure out how to create a meta model for a graph database on Azure Cosmos DB using the Gremlin API, such as the meta graph in neo4j, but I haven't been able to find a way so far.
I want to be able to see the entities of my database as nodes, and the relationships among them as edges, without having to load any data yet (so that I can map these nodes and edges programmatically to the data sources, and the sources are only called -and the data loaded- when there is a matching query).
The only information that's relatively close to this that I've managed to find, is about visualizing the whole graph but not its meta structure (although even this seems to not be possible yet, or only possible through external visualization platforms).
Is it actually possible to do so? Or Cosmos DB being a schema-free database means that it indeed isn't?
There isn't a way to specify a meta-graph in Azure Cosmos DB's Gremlin API - usually Azure Data Factory, or other application-level solutions are recommended.
Please let me know whether we can migrate stored procedure from Microsoft SQL server to Microsoft Azure Cosmos DB ?
Either with DocumentDB migration tool or any other tool
There's really no direct correlation between the two: Stored procedures within the two databases are completely different. No possible way to migrate them, aside from you doing a complete rewrite. SQL Server stored procedures are written in SQL, vs Cosmos DB's JS-based stored procedures. Plus there is the notion of partitions, context, etc.
And Cosmos DB doesn't offer SQL Server compatibility and isn't a relational database. The Core (SQL) API takes advantage of SQL query language, but only for queries.
Microsoft Cosmos DB includes DocumentDB API, Table API and others. I have about ~ 10 TB of data and would like to have a fast key-value lookup (very little updating and writing, mostly are reading). Add a link for Microsoft Cosmos DB:
https://learn.microsoft.com/en-us/azure/cosmos-db/
So how should I choose between DocumentDB API and Table API?
Or when should I choose DocumentDB API? When should I choose Table API?
Is it a good practice to use DcoumentDB API to store 10 TB of data?
The Azure Cosmos DB Table API was introduced to make Cosmos DB and its advanced indexing, geo-distribution, etc. features available to the Azure Table storage community. The idea is that someone using Azure Table storage who needs more advanced features only offered by Cosmos DB can literally just change their connection string and their existing code will work with Cosmos DB.
But if you are a greenfield customer then I would recommend using SQL API (formerly called Document DB API) which is a super set of Table API. We are constantly investing in providing more advanced features and capabilities to SQL API where as for Table API we are just looking to maintain compatibility with Azure Table storage's API which hasn't changed in many years.
How much data you have doesn't have any affect on what API you choose. They both have the same multi-model infrastructure and can handle the same sizes of data, query loads, distribution, etc.
So how should I choose between DocumentDB API and Table API?
Choosing between DocumentDB API and Table API will primarily depend on the kind of data that you're going to store. DocumentDB API provides a schema-less JSON database engine with SQL querying capabilities whereas Table API provides a key-value storage database service. Since you mentioned that your data is key-value based, recommended is that you use Table API.
Or when should I choose DocumentDB API? When should I choose Table API?
Same as above.
Is it a good practice to use DcoumentDB API to store 10 TB of data?
Both Document DB API and Table API are designed to store huge amounts of data.
However you may want to look into Azure Table Storage as well. Cosmos DB lets you fine tune the throughput that you need and robust indexing/querying support and that comes at a price. Azure Tables on the other hand comes with fixed throughput and limited indexing/querying support and is extremely cheap compared to Cosmos DB.
You may find this link helpful to explore more about Cosmos DB: https://learn.microsoft.com/en-us/azure/cosmos-db/introduction.
Please don't flag this as off-topic.
It might help for you to know in advance: if you are considering the document interface, then in fact there is a case-insensitivity that can affect how DataContract classes (and I believe all others) are transformed to and from Cosmos.
In the linked discussion below, you will see that there is a case insensitivity in Newtonsoft.Json that can have effects on your handling of objects that you pass or get directly from the API. Not that Cosmos has ANY flaws, and in fact it is totally excellent. But with a document API, you might (like me) start to simply pass DataContract objects into Cosmos (which is obviously not wrong, and in fact very much expected from the object API), but there are some serializer and naming strategy handler options that you are probably better of at least being aware of up front.
So just to add a note for you to be aware of this behavior with an object interface. The discussion is here on GitHub:
https://github.com/JamesNK/Newtonsoft.Json/issues/815
If there is any guidance available on how to use ADO.NET for CRUD Operations on Windows Azure Table Storage?
Table Storage is sometimes a confusing name as it has nothing to do with a relational tables based database like for example SQL Server.
If you want to get your hands dirty with Table Storage then follow How to Use the Table Storage Service. Another way is to make use of for example Simple.Data.Azure which you can install as a Nuget package.
However if you want to keep on making use of ADO.NET to a relational database like you're used to now then take a look at SQL Databases: How to Use SQL Database in .NET applications.
I have a SQL Azure Database Server and I need to query between the Databases but can't figure out how to accomplish this.
Here is the structure of my databases:
Server.X
Database.A
Database.B
Database.C
In Database.A I have a Stored Procedure that needs to retrieve data from Database.B. Normally, I would reference the database like SELECT * FROM [Database.B].[dbo].[MyTable] but this does not appear to be allowed in SQL Azure.
Msg 40515, Level 15, State 1, Line 16
Reference to database and/or server name in 'Database.B.dbo.MyTable' is not supported in this version of SQL Server.
Is there a way to do this on the database end?
In the final version Databases A & C will both need data from Database B.
Update:
As per Illuminati's comment and answer, the situation has changed since this answer was originally accepted and there is now support for cross database queries as per https://azure.microsoft.com/en-us/blog/querying-remote-databases-in-azure-sql-db/
Original Answer (2013):
Cross database queries aren't supported in SQL Azure. Which means you need to either combine the databases to prevent the need in the first place, or query both databases independently and basically join the data in your application.
Cross database queries are now supported in SQL Azure
https://azure.microsoft.com/en-us/blog/querying-remote-databases-in-azure-sql-db/
Azure SQL DB is previewing Elastic Database Query feature at this point in time that will help you query among Azure SQL DBs with some limitations. You can get detailed information about the feature here.