Banco De Dados SQL Do Azure Vs. Azure Cosmos DB

Você começou recentemente a desenvolver ou portar um aplicativo para o Microsoft Azure? Nesse caso, uma das coisas que você provavelmente terá que decidir é a solução de banco de dados que deseja usar. A nuvem da Microsoft oferece várias opções, sendo as duas mais populares o Azure SQL Database (e seus dois irmãos, Azure SQL Managed Instances e SQL Server em VMs do Azure) e Azure Cosmos DB.

Recentemente, eu estava comparando essas duas alternativas para minha aplicação. Ganhei alguns insights que adoraria compartilhar com meus leitores. Primeiro, vamos analisar os dois produtos separadamente e ver quais recursos eles oferecem.

Banco de Dados SQL do Azure

Azure SQL é a oferta de SQL Server da Microsoft no Azure. Há três serviços relacionados ao Azure SQL para escolher:

  • Banco de Dados SQL do Azure
  • Instância Gerenciada de SQL do Azure
  • SQL Server em VMs do Azure

O Banco de Dados SQL do Azure é o serviço mais “gerenciado” dos três. É uma oferta de PaaS que permite configurar o SQL Server de forma rápida e sem esforço. A maioria das tarefas de administração, incluindo backups, atualizações e monitoramento, são feitas para você. Você também não precisa gerenciar a infraestrutura subjacente.

Há várias camadas de serviço para escolher, incluindo uma única opção de banco de dados com memória e computação configuráveis, uma opção de pool elástico que permite compartilhar recursos entre vários bancos de dados, bem como uma opção sem servidor que pode dimensionar seus recursos dinamicamente dependendo do uso.

O SQL Server em VMs do Azure simplesmente permite que você execute uma instância do SQL Server em sua própria máquina virtual do Azure provisionada. Isso significa que você obtém controle quase total sobre todos os aspectos da implantação. Isso também significa que você precisará se preocupar com a maioria das tarefas de administração que está acostumado a executar em sua solução local.

A Instância Gerenciada de SQL do Azure é uma espécie de híbrido entre esses dois. Por um lado, ele permite que você transfira perfeitamente seu banco de dados local do SQL Server para a nuvem. Por outro lado, oferece muitas vantagens da nuvem, incluindo segurança aprimorada, correção automática, atualizações de versão e backups automatizados.

Como o Azure SQL é compatível principalmente com o SQL Server, ele também oferece as mesmas garantias transacionais (ACID) que o produto local. Devido a essas fortes garantias, o dimensionamento horizontal adicionando várias instâncias de servidor é limitado principalmente a réplicas somente leitura. Isso também vale para o recurso de replicação geográfica do Azure SQL.

O preço do Banco de Dados SQL do Azure é baseado na computação e na memória de que você precisa (vCores), bem como no armazenamento local e no armazenamento de backup que você configura. No geral, o preço parece fácil de entender.

Azure Cosmos DB

Cosmos DB é a oferta NoSQL no Azure. Ele foi projetado desde o início para suportar escalabilidade extrema, adotando totalmente o conceito de consistência eventual. Os principais aplicativos de destino são IoT e aplicativos de nuvem voltados para o mundo. Para isso, o Cosmos DB oferece diferentes níveis de consistência, métodos de acesso a dados (APIs) e opções de dimensionamento.

Como o Cosmos DB é um banco de dados NoSQL, geralmente está em conformidade com a forma como os dados são usados ​​pelo seu aplicativo. Por exemplo, um “item” pode ser inserido no banco de dados como um documento JSON e a saída de uma consulta também é um documento JSON. Bancos de dados e contêineres são usados ​​como namespaces sobre os itens com determinadas funções adicionais.

Para dar suporte ao dimensionamento horizontal extremo, o Cosmos DB usa vários mecanismos. Primeiro, o Cosmos DB particiona cada contêiner de acordo com uma chave de partição. Essas partições são distribuídas automaticamente entre nós físicos. Além disso, a distribuição global de dados é alcançada implantando seus dados em várias regiões do Azure. Isso diminui a latência e aumenta a capacidade de resposta em todo o mundo. Ele também fornece um failover durante interrupções regionais.

Compreensivelmente, a distribuição global vem à custa da consistência. Ao contrário do SQL Server, que fornece garantias ACID fortes por padrão, o Cosmos DB permite que você escolha entre vários níveis de consistência , cada um fornecendo suas garantias. A mais extrema delas, a consistência eventual, apenas garante que todas as réplicas convergirão em algum momento no futuro.

O modelo de preços do Cosmos DB é baseado em unidades de solicitação (RU). 1RU é o custo de uma leitura de ponto de 1 KB. As consultas são correspondentemente mais caras. As unidades de solicitação parecem bastante simples, mas é difícil estimar o uso considerando seus padrões específicos de acesso a dados sem experiência prévia.

Prós e contras

Tendo descrito ambas as soluções, você pode perguntar qual é a mais adequada para você? Vamos discutir alguns pontos fortes e fracos de ambos os bancos de dados.

Profissionais do Banco de Dados SQL do Azure

  • Opções de implantação flexíveis. Se você deseja um serviço totalmente gerenciado ou simplesmente deseja executar o SQL Server nas VMs do Azure, o Banco de Dados SQL do Azure oferece cobertura.
  • Familiarizado com desenvolvedores SQL. Como o Banco de Dados SQL do Azure é essencialmente a implementação do Azure do conhecido SQL Server, a maioria das habilidades é transferida diretamente para a oferta de nuvem.
  • Personalização. Se você executar sua própria instância do SQL Server, terá controle sobre todas as configurações.
  • Preços transparentes. O preço é baseado nos recursos necessários de memória, computação e armazenamento.
  • Migração. Migração relativamente fácil de seus bancos de dados locais do SQL Server para o Azure SQL devido ao mesmo mecanismo subjacente.
  • Estabilidade e confiabilidade. O Microsoft SQL Server foi lançado inicialmente em 1989 e percorreu um longo caminho desde então. É um mecanismo de banco de dados maduro, estável e bem testado.

Contras do Banco de Dados SQL do Azure

  • Esquema fixo. Geralmente, os bancos de dados SQL são menos adequados para requisitos de software que mudam com frequência devido ao seu esquema fixo. A migração de esquema pode ser difícil de gerenciar. Embora o SQL Server possa trabalhar com dados JSON hoje em dia (fazendo a ponte entre SQL e NoSQL), ele requer uma sintaxe especial e parece um pouco uma reflexão tardia.
  • Garantias ACID e transações distribuídas. Embora esses recursos possam ser muito úteis para alguns aplicativos, eles também reduzem drasticamente a escalabilidade caso você não precise deles.
  • Escala limitada. Embora o aumento de escala (adicionando mais memória ou computação às instâncias do SQL Server) seja uma maneira rápida e fácil de aumentar o desempenho, pode se tornar proibitivamente caro além de um determinado ponto. O dimensionamento horizontal (adicionando várias instâncias do SQL Server) é limitado principalmente a réplicas somente leitura.

Profissionais do Azure Cosmos DB

  • Distribuição global. Muitas empresas hoje atuam em todo o mundo. Seus clientes esperam o mesmo desempenho dos aplicativos, independentemente de onde estejam localizados. Isso torna o modelo de banco de dados SQL padrão muito ineficiente. Ter um nó mestre habilitado para gravação com várias réplicas somente leitura não é suficiente para tarefas como feeds de redes sociais ou fluxos de dados IoT.
  • Vários níveis de consistência. Por outro lado, essas aplicações geralmente não precisam das garantias de consistência dos bancos de dados tradicionais. Eles podem contar com modelos de consistência mais fracos, como prefixo consistente ou até consistência eventual. Ter a liberdade de escolher o nível de consistência é um grande benefício do Cosmos DB.
  • Suporte de indexação automática. Cada contêiner tem uma política de indexação definida para acelerar as consultas. Por padrão, todas as propriedades são indexadas e os índices de intervalo são aplicados. Isso é suficiente para a maioria dos casos de uso. No entanto, as configurações de indexação avançadas estão disponíveis.
  • Suporte para vários idiomas pronto para uso. Existem APIs prontas disponíveis para .NET, Java, Python, Ruby e JavaScript. Não há necessidade de camadas ORM complexas.
  • Várias APIs. O Cosmos DB fornece sua própria API Core, bem como várias APIs de banco de dados alternativas (API Gremlin, API Cassandra, API MongoDB, API de tabela) que ajudam na migração de outros bancos de dados NoSQL. Isso reduz o custo de migração e a curva de aprendizado.

Contras do Azure Cosmos DB

  • Mais difícil de entender para administradores de banco de dados tradicionais. Como o Cosmos DB é um banco de dados NoSQL e não fornece necessariamente fortes garantias ACID (dependendo da configuração), é mais difícil de entender para administradores de banco de dados acostumados a lidar com bancos de dados SQL tradicionais.
  • Migração complexa do SQL Server. A migração de uma solução baseada em SQL Server pode ser muito cara e, em casos extremos, pode exigir a reescrita de grandes partes do aplicativo. A otimização subsequente levará ainda mais tempo. Eu só aconselharia fazer isso se os benefícios da escala global superarem os esforços.
  • Modelo de precificação difícil de entender. O modelo de preços é baseado em Unidades de Solicitação que podem não ser intuitivas. A Calculadora de Capacidade do Cosmos DB no portal pode ajudar com estimativas de custo, desde que você possa estimar determinadas métricas-chave. Em geral, o Cosmos DB pode ser bastante caro.
  • Somente nuvem pública. O único local onde o Cosmos DB é implantado é nos datacenters da Microsoft. Atualmente, não há oferta para soluções de nuvem híbridas ou locais, como o Azure Arc.

Conclusão

Ambos os produtos têm um lugar no ecossistema do Azure. Embora o Banco de Dados SQL do Azure forneça uma migração fácil de sua solução SQL Server local e ajude você a aproveitar seu conhecimento existente do SQL Server, o Cosmos DB foi projetado desde o início para distribuição global e é totalmente gerenciado.

Se eu tivesse que decidir qual banco de dados usar para um novo projeto, certamente escolheria o Cosmos DB, pois simplesmente adoro sua escalabilidade e flexibilidade. Como um serviço NoSQL, interagir com o banco de dados simplesmente parece mais natural em seu código de aplicativo do que trabalhar para middleware ORM complexo necessário para bancos de dados tradicionais. Além disso, a escolha de vários níveis de consistência torna muito fácil escolher o equilíbrio certo entre velocidade e consistência.

Minha principal preocupação com o Cosmos DB é sua curva de aprendizado íngreme para administradores acostumados a lidar com bancos de dados SQL tradicionais. A configuração do seu primeiro banco de dados Cosmos DB parece esmagadora. Você terá que ler muita documentação ou assistir a muitos tutoriais para descobrir como configurar o serviço para atender aos seus requisitos específicos.

No entanto, acho que isso melhorará com o tempo à medida que a taxa de adoção aumentar. O Cosmos DB já percorreu um longo caminho em pouco tempo e mal posso esperar para ver para onde iremos a seguir.

Fonte: https://betterprogramming.pub/azure-sql-database-vs-cosmos-db-which-should-you-choose-cda17b60d6d2

#cosmosdb #azure #sql 

What is GEEK

Buddha Community

Banco De Dados SQL Do Azure Vs. Azure Cosmos DB
Cayla  Erdman

Cayla Erdman

1594369800

Introduction to Structured Query Language SQL pdf

SQL stands for Structured Query Language. SQL is a scripting language expected to store, control, and inquiry information put away in social databases. The main manifestation of SQL showed up in 1974, when a gathering in IBM built up the principal model of a social database. The primary business social database was discharged by Relational Software later turning out to be Oracle.

Models for SQL exist. In any case, the SQL that can be utilized on every last one of the major RDBMS today is in various flavors. This is because of two reasons:

1. The SQL order standard is genuinely intricate, and it isn’t handy to actualize the whole standard.

2. Every database seller needs an approach to separate its item from others.

Right now, contrasts are noted where fitting.

#programming books #beginning sql pdf #commands sql #download free sql full book pdf #introduction to sql pdf #introduction to sql ppt #introduction to sql #practical sql pdf #sql commands pdf with examples free download #sql commands #sql free bool download #sql guide #sql language #sql pdf #sql ppt #sql programming language #sql tutorial for beginners #sql tutorial pdf #sql #structured query language pdf #structured query language ppt #structured query language

Eric  Bukenya

Eric Bukenya

1624713540

Learn NoSQL in Azure: Diving Deeper into Azure Cosmos DB

This article is a part of the series – Learn NoSQL in Azure where we explore Azure Cosmos DB as a part of the non-relational database system used widely for a variety of applications. Azure Cosmos DB is a part of Microsoft’s serverless databases on Azure which is highly scalable and distributed across all locations that run on Azure. It is offered as a platform as a service (PAAS) from Azure and you can develop databases that have a very high throughput and very low latency. Using Azure Cosmos DB, customers can replicate their data across multiple locations across the globe and also across multiple locations within the same region. This makes Cosmos DB a highly available database service with almost 99.999% availability for reads and writes for multi-region modes and almost 99.99% availability for single-region modes.

In this article, we will focus more on how Azure Cosmos DB works behind the scenes and how can you get started with it using the Azure Portal. We will also explore how Cosmos DB is priced and understand the pricing model in detail.

How Azure Cosmos DB works

As already mentioned, Azure Cosmos DB is a multi-modal NoSQL database service that is geographically distributed across multiple Azure locations. This helps customers to deploy the databases across multiple locations around the globe. This is beneficial as it helps to reduce the read latency when the users use the application.

As you can see in the figure above, Azure Cosmos DB is distributed across the globe. Let’s suppose you have a web application that is hosted in India. In that case, the NoSQL database in India will be considered as the master database for writes and all the other databases can be considered as a read replicas. Whenever new data is generated, it is written to the database in India first and then it is synchronized with the other databases.

Consistency Levels

While maintaining data over multiple regions, the most common challenge is the latency as when the data is made available to the other databases. For example, when data is written to the database in India, users from India will be able to see that data sooner than users from the US. This is due to the latency in synchronization between the two regions. In order to overcome this, there are a few modes that customers can choose from and define how often or how soon they want their data to be made available in the other regions. Azure Cosmos DB offers five levels of consistency which are as follows:

  • Strong
  • Bounded staleness
  • Session
  • Consistent prefix
  • Eventual

In most common NoSQL databases, there are only two levels – Strong and EventualStrong being the most consistent level while Eventual is the least. However, as we move from Strong to Eventual, consistency decreases but availability and throughput increase. This is a trade-off that customers need to decide based on the criticality of their applications. If you want to read in more detail about the consistency levels, the official guide from Microsoft is the easiest to understand. You can refer to it here.

Azure Cosmos DB Pricing Model

Now that we have some idea about working with the NoSQL database – Azure Cosmos DB on Azure, let us try to understand how the database is priced. In order to work with any cloud-based services, it is essential that you have a sound knowledge of how the services are charged, otherwise, you might end up paying something much higher than your expectations.

If you browse to the pricing page of Azure Cosmos DB, you can see that there are two modes in which the database services are billed.

  • Database Operations – Whenever you execute or run queries against your NoSQL database, there are some resources being used. Azure terms these usages in terms of Request Units or RU. The amount of RU consumed per second is aggregated and billed
  • Consumed Storage – As you start storing data in your database, it will take up some space in order to store that data. This storage is billed per the standard SSD-based storage across any Azure locations globally

Let’s learn about this in more detail.

#azure #azure cosmos db #nosql #azure #nosql in azure #azure cosmos db

Ruthie  Bugala

Ruthie Bugala

1620435660

How to set up Azure Data Sync between Azure SQL databases and on-premises SQL Server

In this article, you learn how to set up Azure Data Sync services. In addition, you will also learn how to create and set up a data sync group between Azure SQL database and on-premises SQL Server.

In this article, you will see:

  • Overview of Azure SQL Data Sync feature
  • Discuss key components
  • Comparison between Azure SQL Data sync with the other Azure Data option
  • Setup Azure SQL Data Sync
  • More…

Azure Data Sync

Azure Data Sync —a synchronization service set up on an Azure SQL Database. This service synchronizes the data across multiple SQL databases. You can set up bi-directional data synchronization where data ingest and egest process happens between the SQL databases—It can be between Azure SQL database and on-premises and/or within the cloud Azure SQL database. At this moment, the only limitation is that it will not support Azure SQL Managed Instance.

#azure #sql azure #azure sql #azure data sync #azure sql #sql server

Creating and Cataloging SQL pools in Azure SQL Server

This article will walk you through creating a new SQL pool within an existing Azure SQL Server as well as catalog the same using the Azure Purview service.

Introduction

Data is generated by transactional systems and typically stored in relational data repositories. This data is generally used by live applications and for operational reporting. As this data volume grows, this data is often required by other analytical repositories and data warehouses where it can be used for referential purposes and adding more context to other data from across the organization. Transactional systems (also known as Online Transaction Processing (OLTP) systems) usually need a relational database engine, while analytical systems (also known as Online Analytical Processing (OLAP) systems) usually need analytical data processing engines. On Azure cloud, it is usually known that for OLTP requirements, SQL Server or Azure SQL Database can be employed, and for analytical data processing needs, Azure Synapse and other similar services can be employed. SQL Pools in Azure Synapse host the data on an SQL Server environment that can process the data in a massively parallel processing model, and the address of this environment is generally the name of the Azure Synapse workspace environment. At times, when one has already an Azure SQL Server in production or in use, the need is to have these SQL Pools on an existing Azure SQL Server instance, so data in these SQL pools can be processed per the requirements on an OLAP system as well as the data can be co-located with data generated by OLTP systems. This can be done by creating SQL Pools within the Azure SQL Server instance itself. In this article, we will learn to create a new SQL Pool within an existing Azure SQL Server followed by cataloging the same using the Azure Purview service.

Pre-requisite

As we intend to create a new SQL Pool in an existing Azure SQL Server instance, we need to have an instance of Azure SQL in place. Navigate to Azure Portal, search for Azure SQL and create a new instance of it. We can create an instance with the most basic configuration for demonstration purposes. Once the instance is created, we can navigate to the dashboard page of the instance and it would look as shown below.

As we are going to catalog the data in the dedicated SQL Pool hosted on Azure SQL instance, we also need to create an instance of Azure Purview. We would be using the Azure Purview studio from the dashboard of this instance, tonregister this SQL Pool as the source and catalog the instance.

#azure #sql azure #azure sql server #sql #sql #azure

Christa  Stehr

Christa Stehr

1603941420

Support for Synapse SQL serverless in Azure Synapse Link for Azure Cosmos DB

Co-authored by Rodrigo Souza, Ramnandan Krishnamurthy, Anitha Adusumilli and Jovan Popovic (Azure Cosmos DB and Azure Synapse Analytics teams)

Azure Synapse Link now supports querying Azure Cosmos DB data using Synapse SQL serverless. This capability, available in public preview, allows you to use familiar analytical T-SQL queries and build powerful near real-time BI dashboards on Azure Cosmos DB data.

As announced at Ignite 2020, you can now also query Azure Cosmos DB API for Mongo DB data using Azure Synapse Link, enabling analytics with Synapse Spark and Synapse SQL serverless.

Support for T-SQL queries and building near real-time BI dashboards

Azure Synapse SQL serverless (previously known as SQL on-demand) is a serverless, distributed data processing service offering built-in query execution fault-tolerance and a consumption-based pricing model. It enables you to analyze your data in Cosmos DB analytical store within seconds, without any performance or RU impact on your transactional workloads.

Using OPENROWSET syntax and automatic schema inference, data and business analysts can use familiar T-SQL query language to quickly explore and reason about the contents in Azure Cosmos DB analytical store. You can query this data in place without the need to copy or load the data into a specialized store.

You can also create SQL views to join data in the analytical stores across multiple Azure Cosmos DB containers, to better organize your data in a semantic layer that will accelerate your data exploration and reporting workloads. BI Professionals can quickly create Power BI reports on top of these SQL views in Direct Query mode.

You can further extend this by building a logical data warehouse to create and analyze unified views of data across Azure Cosmos DB, Azure Data Lake Storage and Azure Blob Storage.

 

#analytics #announcements #api for mongodb #core (sql) api #data architecture #query #azure cosmos db #azure synapse analytics #serverless sql pools #sql on-demand #synapse link #synapse sql serverless