Início / dba / Perguntas / 335379
Accepted
Ajit Goel
Asked: 2024-02-01 01:44:34 +0800 CST

Armazenando terabytes de dados no Azure SQL Server

  • 772

Preciso desenvolver um sistema de produção de servidor SQL do Azure capaz de armazenar recomendações de itens do usuário com base no histórico de compras do usuário, perfil de saúde do usuário e recomendações de itens (cerca de 415 MB). Conheço a produção aproximada em 13 meses, o tempo que os dados devem ser armazenados e calculei uma necessidade de cerca de 30 TB de armazenamento.

Tenho alguma experiência em trabalhar com bancos de dados, mas lidar com essa quantidade de dados é uma novidade para mim.

Minha abordagem inicial seria armazenar esses dados em vários bancos de dados usando sharding, mas não tenho certeza sobre como lidar com a parte de design do aplicativo, onde o aplicativo precisa estar ciente da estratégia de sharding e saber a qual banco de dados (shard) se conectar, por uma determinada operação (em nosso aplicativo, cada usuário é um guia). Também não tenho certeza da complexidade do gerenciamento de vários bancos de dados, do gerenciamento de transações que abrangem vários bancos de dados. Como será a estrutura de custos considerando que no Azure eu pago por banco de dados.

A comunidade teria alguma opinião sobre o meu problema?

sql-server

2 respostas

  1. Best Answer

    A comunidade teria alguma opinião sobre o meu problema?

    Claro, esses são meus pensamentos...

    recomendações de itens do usuário com base no histórico de compras do usuário, perfil de saúde do usuário e recomendações de itens (cerca de 415 MB)

    Parece muito para um único usuário. Como você chegou a esse número?

    calcularam uma necessidade de cerca de 30 TB de armazenamento.

    Você incluiu compactação de dados em seu cálculo de tamanho?

    Tenho alguma experiência em trabalhar com bancos de dados, mas lidar com essa quantidade de dados é uma novidade para mim.

    O tamanho dos dados em repouso não importa muito. Contanto que seu banco de dados seja arquitetado corretamente, não há diferença .

    Minha abordagem inicial seria armazenar esses dados em vários bancos de dados usando sharding, mas não tenho certeza sobre como lidar com a parte de design do aplicativo, onde o aplicativo precisa estar ciente da estratégia de sharding e saber a qual banco de dados (shard) se conectar, por uma determinada operação (em nosso aplicativo, cada usuário é um guia). Também não tenho certeza da complexidade do gerenciamento de vários bancos de dados, do gerenciamento de transações que abrangem vários bancos de dados.

    Na verdade, isso seria desnecessariamente complexo e provavelmente com pouco ou nenhum ganho. Parece um pouco prematuro uma otimização atualmente, até que você tenha esgotado outras opções.

    Como será a estrutura de custos considerando que no Azure eu pago por banco de dados.

    Parece que se você fragmentasse, seria caro. Se você o mantivesse em um único banco de dados e dimensionasse verticalmente conforme necessário, não seria tão caro. Mas a nuvem tem um custo premium de qualquer maneira.

    Resumindo, eu não me preocuparia em fragmentar os dados até esgotar minhas outras opções. Basta construir um banco de dados normal e resolver problemas de desempenho se e quando eles ocorrerem. Não tente otimizar proativamente e prematuramente.

    • 1

  2. Parece um bom caso para o Azure Synapse Analytics. https://azure.microsoft.com/en-ca/products/synapse-analytics

    • 0

relate perguntas