Lançamento - Azure SQL Database Edge (preview)

     Uma pausa em nossos tópicos de " Dicas que todos desenvolvedores deveria conhecer", para falar sobre um novo produto. Em 6 de novembro (hoje rs) na PASS Summit 2019. No primeiro Keynote, Rohan Kumar que é Vice President of Azure Data, apresentou o lançamento público do SQL 2019 e também anunciou o preview do Azure SQL Database Edge, que tem menos de 300mb e pode rodar dentro de um Raspberry PI. Uma nova edição do SQL Server voltada para dispositivos de borda, a Internet das Coisas (IoT). Isso significa que o SQL Server agora pode ser executado em quase qualquer lugar. 

Em primeiro lugar, lembre-se de que o Azure significa "híbrido" agora; portanto, embora possamos esperar que se refira à computação em nuvem, ele também leva em conta a infraestrutura local. Em segundo lugar, esse é o mecanismo de banco de dados completo do SQL Server em execução em uma CPU ARM de 64 bits. Ele poderia ser executado em um Raspberry Pi ou - desde que houvesse suporte para outro hardware - dispositivos Android ou iOS, no entanto, ele é voltado para dispositivos de ponta que coletam dados de sensores IoT e outros pontos de dados. Pense nisso como um passo a partir dos dispositivos IoT ...

Um dos impedimentos mais significativos para aplicativos baseados na nuvem muito exigentes é a latência de fazer vários saltos na espinha dorsal da Internet para o data center do Microsoft Azure ou Amazon AWS. Uma vez lá, os dados são processados ​​e, em seguida, devem ser enviados de volta ao cliente. Esse é um paradigma de processamento de dados muito lento para uma ampla variedade de aplicativos, especialmente aplicativos de IoT, como carros conectados / autônomos ou sistemas de segurança com reconhecimento facial.

Como mencionei anteriormente, é o mecanismo completo do SQL Server. Então, por que não chamá-lo de SQL Server Edge? Isso porque não é apenas o SQL Server. Um recurso solicitado para inclusão no SQL Server por várias pessoas ao longo dos anos é o suporte a séries temporais . Em vez de incorporá-lo ao mecanismo de banco de dados, a Microsoft incorporou o suporte a séries temporais a partir do material de análise que eles já criaram para o Azure. É aí que entra a marca do Azure, porque ela se encaixa perfeitamente na esfera da oferta de serviço da IoT do Azure .

Ainda é uma versão completa do mecanismo de banco de dados do SQL Server (sim, incluindo column store e OLTP na memória), rodando em CPUs ARM de 64 bits, que se beneficiam da redução do uso de energia, da vida útil da bateria e de todos os outros motivos pelos quais gostamos do ARM. É apenas o SQL Server, no Linux, em pequenos computadores que podem ser executados em qualquer lugar. Isso reduz bastante o esforço de criação de software de gerenciamento de dados, porque agora podemos segmentar apenas uma plataforma de dados, desde a borda até a nuvem e tudo mais.

Claro, o SQLite é um banco de dados de usuário único realmente rápido, mas não é o mecanismo completo do SQL Server.

Here is what Azure SQL Database Edge offers:

• Crie uma vez e implante em qualquer lugar, incluindo SQL do Azure

DATABASE, SQL SERVER, AND AZURE SQL DATABASE EDGE

• Movimento bidirecional de dados entre a borda e o local ou a nuvem para um padrão inteligente de armazenamento e encaminhamento

• Segurança forte incorporada ao Banco de Dados SQL do Azure para dados totalmente criptografados em repouso e em movimento em nós de borda e gateways de borda

• Capacidade de combinar fluxo de dados e séries temporais com aprendizado de máquina no banco de dados para permitir análises de baixa latência

• Cenários de borda totalmente desconectados e conectados à nuvem com computação e armazenamento local. Gerenciamento de todo o sistema a partir de um portal de gerenciamento central do Azure IoT.

• Suporte para ferramentas de visualização de dados existentes, como Power BI e Tableau.

• Suporte programático completo para a linguagem T-SQL, bem como suporte analítico usando R, Python, Java e Spark.

• Suporte para processamento e armazenamento de dados de gráficos, JSON e séries temporais no banco de dados, juntamente com a capacidade de aplicar análises e recursos de aprendizado de máquina no banco de dados em tipos de dados não relacionais. Isso permite cenários em que você deseja treinar seus modelos de aprendizado de máquina na nuvem e pontuar no nó de extremidade.

Toda comunidade está extremamente empolgada com a perspectiva desta nova edição do SQL Server. Compartilhe seus pensamentos nos comentários abaixo.

Link Oficial, para maiores informações:
https://azure.microsoft.com/en-us/services/sql-database-edge/

Link Azure SQL Database Edge Whitepaper:
https://azure.microsoft.com/mediahandler/files/resourcefiles/azure-sql-database-edge-whitepaper/White%20Paper-AzureSQLDatabaseEdge-2019.pdf

SQL SERVER - Dicas que todo DEV deveria conhecer part-2

    Nesta sequencia de tópicos abordaremos algumas dicas, que todo desenvolvedor deveria ter a oportunidade de conhecer. Todo desenvolvedor que programa em T/SQL, precisa estar atento a algumas "tips" do SQL Server em seu dia-a-dia na empresa.

Part-2 Variáveis ​​table e JOIN's (DECLARE @table_variable_name TABLE)

Não use variáveis ​​de tabela em conjunto com JOIN. Use tabelas temporárias, CTEs (Common Table Expressions) em JOIN.


Embora as variáveis ​​table sejam muito rápidas e eficientes em muitas situações, o mecanismo do SQL Server a vê como uma única linha. Devido a isso, eles apresentam um desempenho horrível quando usados ​​em JOIN's. Tabelas temporárias apresentam melhor desempenho com JOIN's em comparação com as variáveis ​​da tabela.

Dica complementar: Criação de tabelas dentro de stored procedures? Cuidado!

Quando uma tabela é criada e utilizada dentro de uma mesma stored procedure, o otimizador não tem conhecimento das suas estatísticas, e assume que esta tabela tem 100 linhas e 10 páginas. Se a tabela criada é muito grande, esta suposição pode levar o otimizador a calcular um plano de acesso não otimizado / Errado. Para evitar este problema, crie a tabela em uma rotina anterior e utilize-a em outra.

Variáveis Locais ou Parâmetros na cláusula WHERE ? 

O otimizador não tem informações sobre o valor de uma variável, mas, em tempo de compilação, sabe o valor de um parâmetro. Isso posto, a utilização de parâmetros em cláusula where, leva o otimizador a produzir um plano de acesso mais eficiente.

mais recente, detalhamos esse hint no topico especifico: Dicas que todo DEV deveria conhecer
Parte 4 - Ad Hoc Queries (Forced Parameterization)

Exemplo sugestivo, observe que na primeira procedure

a Variavel @x recebe = b1 e logo em sequencia a variavel é passada como filtro WHERE b1 = @x
(O otimizador não tem informações sobre o valor de uma variável)

Na segunda procedure, em duas estapas: @x recebe = b1

Que é passado como parâmetro pra uma segunda procedure Exec s_p2 (@x) --solução
(Que força o otimizador a produzir um plano de acesso mais eficiente)

* Imagine no exemplo, uma tabela (t2) já criada anteriormente no escopo da procedure.

SQL SERVER - Dicas que todo DEV deveria conhecer part-1

    Nesta sequencia de tópicos abordaremos algumas dicas, que todo desenvolvedor deveria ter a oportunidade de conhecer. Todo desenvolvedor que programa em T/SQL, precisa estar atento a algumas "tips" do SQL Server em seu dia-a-dia na empresa.

Serão abordados diversos temas sequenciais, e depois da conclusão listaremos todos em um menu completo aqui.

Part-1 Transaction Log 
Part-2 Variáveis ​​table e JOIN's & Criação de tabelas dentro de stored procedures

Part-1 Transaction Log 

De modo simplista, todos imaginamos que quando executamos algum DML insert, update ou delete.
O SGBD registra em disco Transaction Log (faremos referencia com T-Log, daqui pra frente) para depois efetuar commit em mdf, certo?

Não - Errado.

Neste caminho simplificado, existe um camada de Log Buffer. Uma região em memoria responsável pelo buffer das informações, que somente apos check irá "commitar" esses dados em memoria para disco log. De maneira simplificada, esse é o WAIT mais comum relacionado ao T-Log.
Ele está relacionado ao tempo que SQL Server está esperando para escrever no disco.

Como podemos otimizar essa escrita ?

Nossa primeira Dica, neste tópico será a otimização do Transaction log, imaginem um loop de 10mil transações:

Já imaginou o trabalho que o SQL Server teria para abrir e fechar 10mil transações em loop?
Então imagine como seria muito mais simples, fazer tudo em uma única transação!

Padrão:

WHILE @id < 10000

   BEGIN

    INSERT INTO TABELA_TESTE VALUES(...)

   END

Melhoria:

BEGIN TRAN

   WHILE @id < 10000

   BEGIN

    INSERT INTO TABELA_TESTE VALUES(...)

   END

COMMIT

*

Por favor não confundam transaction begin tran  / while if begin de blocos de comando ok

Essa falha é muito comum em select into, update from também, onde indiferente da transação 

Já existiria um tratamento de erro no final If (@@Error > 0). O que torna totalmente adaptável o controle transacional no bloco de repetições.

No exemplo nosso tempo de execução baixou de forma considerável de mais de 2 minutos para 45 segundos! Ou seja, foi reduzido mais da metade do tempo! Essa melhora ocorreu por que o SQL Server processou as 10 mil inserções em uma única transação. Nem sempre é possível realizar essa otimização, mas ela pode ser uma boa solução.