Metadados estruturados para memórias de longo prazo

A filtragem de metadados no Amazon Bedrock AgentCore Memory permite que você adicione atributos estruturados aos seus registros de memória de longo prazo. Você pode usar esses atributos para restringir quais registros são retornados durante a recuperação. Os namespaces já isolam as memórias por entidade primária (usuário, inquilino, paciente, cliente). No entanto, em um único namespace, uma ampla pesquisa semântica retorna tudo o que tem um significado próximo. Com a filtragem de metadados, você pode recuperar somente resultados que correspondam a valores de atributos específicos. Por exemplo, você pode recuperar somente registros de alta prioridade, somente registros de um departamento específico ou somente registros criados dentro de um determinado intervalo de tempo.

Com a filtragem de metadados, você pode:

Introdução

A configuração da filtragem de metadados envolve cinco etapas:

As seções subsequentes descrevem cada etapa detalhadamente.

Principais conceitos

Chaves de metadados indexadas

As chaves indexadas são declaradas no nível do recurso de memória em CreateMemory (ou adicionadas posteriormente por meio deUpdateMemory). As chaves indexadas são armazenadas em um formato otimizado para filtragem rápida de consultas. Somente chaves indexadas podem ser consultadas em e. metadataFilters ListMemoryRecords RetrieveMemoryRecords

O exemplo a seguir declara duas chaves indexadas:

{
  "indexedKeys": [
    { "key": "priority", "type": "STRING" },
    { "key": "tags",     "type": "STRINGLIST" }
  ]
}

typeValores suportados:STRING,STRINGLIST,NUMBER.

As chaves devem corresponder ^[a-zA-Z0-9\s._:/=+@-]*$ (máximo de 128 caracteres).

Adicionar uma chave indexada não preenche os registros existentes. Somente registros criados ou atualizados após a declaração da chave são indexados para essa chave. Para obter mais detalhes sobre a evolução do seu esquema ao longo do tempo, consulte. Etapa 5: evolua seu esquema de metadados

Esquema de metadados (por estratégia)

Opcionalmente, a estratégia de memória pode ter um esquema de metadados declarado em. memoryRecordSchema.metadataSchema O esquema de metadados informa ao LLM quais metadados extrair do conteúdo conversacional ao gerar registros de memória. Somente as chaves definidas no esquema de metadados da estratégia são preenchidas nos registros de memória resultantes durante a extração orientada por eventos.

Cada entrada no esquema define:

O exemplo a seguir mostra uma entrada do esquema de metadados com validação:

{
  "metadataSchema": [
    {
      "key": "priority",
      "type": "STRING",
      "extractionConfig": {
        "llmExtractionConfig": {
          "definition": "Issue priority level based on customer impact. Values range from critical (most severe) to low (least severe).",
          "llmExtractionInstruction": "LATEST_VALUE",
          "validation": {
            "stringValidation": {
              "allowedValues": ["critical", "high", "medium", "low"]
            }
          }
        }
      }
    }
  ]
}

Opções de validação por tipo:

Metadados determinísticos (tipo de extração STRICTLY_CONSISTENT)

As chaves de metadados determinísticos contêm valores que seu aplicativo já conhece ao criar um evento. Esses valores são copiados exatamente para os registros de memória resultantes sem modificação. Classificadores organizacionais como departmentcompliance_level, ou não agent_id devem ser inferidos pelo LLM. A inferência do LLM introduz variabilidade. Por exemplo, a mesma conversa pode ser produzida "eng" em um registro e "Engineering" em outro.

Para essas chaves, extractionType defina como STRICTLY_CONSISTENT na entrada do esquema de metadados. O valor fornecido no evento se propaga inalterado por meio de extração e consolidação. O LLM não é consultado para essa chave.

O JSON a seguir mostra um esquema de metadados com ambos os STRICTLY_CONSISTENT tipos de extração: LLM_INFERRED

{
  "metadataSchema": [
    {
      "key": "department",
      "type": "STRING",
      "extractionType": "STRICTLY_CONSISTENT"
    },
    {
      "key": "compliance_level",
      "type": "STRING",
      "extractionType": "STRICTLY_CONSISTENT"
    },
    {
      "key": "topic",
      "type": "STRING",
      "extractionType": "LLM_INFERRED",
      "extractionConfig": {
        "llmExtractionConfig": {
          "definition": "Primary topic of the conversation",
          "llmExtractionInstruction": "Identify the main topic discussed"
        }
      }
    }
  ]
}

Quando você omiteextractionType, o padrão éLLM_INFERRED.

Isolamento de extração e consolidação

STRICTLY_CONSISTENTas chaves fazem mais do que ignorar a inferência do LLM. Eles agrupam eventos por seus valores determinísticos durante a extração. Eventos com valores diferentes são processados separadamente. A consolidação segue a mesma regra. Os registros de um grupo de valores nunca são mesclados com registros de outro grupo.

O exemplo de Python a seguir mostra uma sessão de suporte com duas chaves determinísticas (departmente): priority

# Event 1: high-priority billing inquiry
agentcore_client.create_event(
    memoryId="mem-support-abc123",
    actorId="customer-123",
    sessionId="session-escalation-001",
    payload=[{"conversational": {"role": "USER",
        "content": {"text": "I'm seeing duplicate charges on my invoice and it's blocking our deployment."}}}],
    metadata={
        "department": {"stringValue": "billing"},
        "priority": {"stringValue": "high"}
    }
)

# Event 2: also high-priority billing (same deterministic values as Event 1)
agentcore_client.create_event(
    memoryId="mem-support-abc123",
    actorId="customer-123",
    sessionId="session-escalation-001",
    payload=[{"conversational": {"role": "USER",
        "content": {"text": "The charges appeared after we upgraded from standard to enterprise tier last week."}}}],
    metadata={
        "department": {"stringValue": "billing"},
        "priority": {"stringValue": "high"}
    }
)

# Event 3: high-priority engineering (same priority, different department)
agentcore_client.create_event(
    memoryId="mem-support-abc123",
    actorId="customer-123",
    sessionId="session-escalation-001",
    payload=[{"conversational": {"role": "USER",
        "content": {"text": "Your team found a provisioning bug that triggered the duplicate charge."}}}],
    metadata={
        "department": {"stringValue": "engineering"},
        "priority": {"stringValue": "high"}
    }
)

# Event 4: low-priority billing (same department as Events 1-2, different priority)
agentcore_client.create_event(
    memoryId="mem-support-abc123",
    actorId="customer-123",
    sessionId="session-escalation-001",
    payload=[{"conversational": {"role": "USER",
        "content": {"text": "Also, can you update the billing contact email on file when you get a chance?"}}}],
    metadata={
        "department": {"stringValue": "billing"},
        "priority": {"stringValue": "low"}
    }
)

O sistema agrupa eventos pela combinação exata de todos os valores-chave determinísticos:

Todos os valores-chave determinísticos devem corresponder para que os eventos sejam agrupados. Uma consulta com department=billing AND priority=high retorna somente os fatos urgentes da cobrança duplicada. Os outros eventos estão em partições separadas. Registros de combinações de valores diferentes nunca são mesclados durante a consolidação.

Restrições

Como as chaves indexadas e as chaves do esquema interagem

A relação entre chaves indexadas e chaves de esquema determina como os metadados se comportam:

Como os metadados fluem de eventos para registros de memória

Os metadados do evento aceitam somente stringValue entradas. Suporte stringValue e numberValue tipos de registros de memória — preenchidos pelo LLM durante a extração ou fornecidos diretamente por meio das APIs Batch. stringListValue O dateTimeValue tipo é reservado para campos gerados pelo sistema (x-amz-agentcore-memory-createdAtex-amz-agentcore-memory-updatedAt). Somente as chaves definidas na estratégia metadataSchema são preenchidas nos registros extraídos — as chaves de metadados do evento que não estão no esquema são ignoradas. Para limites de entrada, consulteCotas.

System-generated metadados

Cada registro de memória carrega esses campos do sistema, que podem ser consultados com os mesmos operadores de filtro:

Você não precisa declará-las como chaves indexadas — elas estão sempre disponíveis para filtragem. Esses dateTimeValue campos gerados pelo sistema oferecem suporte BEFORE e AFTER operadores, permitindo consultas por intervalo de tempo sem exigir que você declare chaves indexadas de data e hora.

Pré-requisitos

Antes de configurar a filtragem de metadados, verifique se você tem:

Etapa 1: criar uma memória com chaves indexadas e um esquema de metadados

O seguinte cria uma memória de suporte ao cliente com cinco chaves indexadas e um esquema de metadados. priority,agent_type, e sentiment são definidos no esquema de metadados da estratégia — o LLM extrai seus valores do conteúdo da conversa. Observe que sentiment está no esquema, mas não é declarado como uma chave indexada: o LLM deriva seu valor das conversas e o preenche nos registros, mas não pode ser usado em expressões de filtro. tags(STRINGLIST), channel (STRING) e ticket_id (STRING) são declaradas como chaves indexadas, mas não estão no esquema. Elas não são preenchidas durante a extração orientada por eventos, mas podem ser fornecidas por meio das APIs Batch.

aws bedrock-agentcore-control create-memory \
  --name "CustomerSupportMemory" \
  --event-expiry-duration 30 \
  --indexed-keys '[
    {"key": "priority",   "type": "STRING"},
    {"key": "agent_type", "type": "STRING"},
    {"key": "tags",       "type": "STRINGLIST"},
    {"key": "channel",    "type": "STRING"},
    {"key": "ticket_id",  "type": "STRING"}
  ]' \
  --memory-strategies '[
    {
      "semanticMemoryStrategy": {
        "name": "SupportSemanticStrategy",
        "description": "Captures support interaction details",
        "namespaceTemplates": ["support/{actorId}"],
        "memoryRecordSchema": {
          "metadataSchema": [
            {
              "key": "priority",
              "type": "STRING",
              "extractionConfig": {
                "llmExtractionConfig": {
                  "definition": "Issue priority level based on customer impact. Values range from critical (most severe) to low (least severe).",
                  "llmExtractionInstruction": "LATEST_VALUE",
                  "validation": {
                    "stringValidation": {
                      "allowedValues": ["critical", "high", "medium", "low"]
                    }
                  }
                }
              }
            },
            {
              "key": "agent_type",
              "type": "STRING",
              "extractionConfig": {
                "llmExtractionConfig": {
                  "definition": "Support agent classification.",
                  "llmExtractionInstruction": "Prefer the most specialized agent type. Hierarchy: specialist > tier3 > tier2 > tier1 > bot."
                }
              }
            },
            {
              "key": "sentiment",
              "type": "STRING",
              "extractionConfig": {
                "llmExtractionConfig": {
                  "definition": "Customer sentiment during the interaction.",
                  "llmExtractionInstruction": "LATEST_VALUE",
                  "validation": {
                    "stringValidation": {
                      "allowedValues": ["positive", "neutral", "negative", "frustrated"]
                    }
                  }
                }
              }
            }
          ]
        }
      }
    }
  ]'

Etapa 2: verificar a configuração

Use GetMemory para confirmar que as chaves indexadas e o esquema de metadados foram aceitos:

aws bedrock-agentcore-control get-memory --memory-id "<memory-id>"

Etapa 3: ingerir dados com metadados

Há dois caminhos para colocar metadados em registros de memória.

Event-driven ingestão

Anexe stringValue metadados aos eventos no momento da criação. O LLM usa o esquema de metadados da estratégia para extrair e preencher metadados nos registros de memória resultantes. Somente as chaves definidas na estratégia metadataSchema são preenchidas nos registros resultantes — as chaves de metadados do evento que não estão no esquema são ignoradas durante a extração.

aws bedrock-agentcore create-event \
  --memory-id "<memory-id>" \
  --actor-id "customer-123" \
  --session-id "session-001" \
  --event-timestamp "$(date -u +"%Y-%m-%dT%H:%M:%S.%3NZ")" \
  --metadata '{
    "priority":  {"stringValue": "high"},
    "channel":   {"stringValue": "email"},
    "ticket_id": {"stringValue": "TKT-5001"}
  }' \
  --payload '[
    {"conversational": {"role": "USER",      "content": {"text": "I have a billing issue that is blocking my production deployment"}}},
    {"conversational": {"role": "ASSISTANT", "content": {"text": "I understand this is urgent. Let me escalate to our billing specialist team."}}}
  ]'

Neste exemplo, priority está na estratégiametadataSchema, então seu valor se propaga para o registro de memória. channele não ticket_id estão no esquema, então são ignorados durante a extração. O LLM também infere agent_type (provavelmente "specialist" com base na escalação) e sentiment (provavelmente"frustrated") a partir do conteúdo da conversa — essas chaves de esquema são preenchidas mesmo que não tenham sido fornecidas como metadados do evento.

Extração implícita de metadados do conteúdo da conversa

Os metadados do evento não são necessários para que as chaves do esquema produzam valores. Quando uma chave de esquema não tem metadados correspondentes nos eventos de origem, o LLM deriva o valor inteiramente do conteúdo da conversa. Ele usa a chave definition e llmExtractionInstruction para determinar o valor. Isso é útil para dimensões que só existem na conversa em si, sem exigir que os chamadores as forneçam no momento da criação do evento.

Usando a mesma memória de suporte ao cliente da Etapa 1, o evento a seguir não tem nenhum metadado:

aws bedrock-agentcore create-event \
  --memory-id "<memory-id>" \
  --actor-id "customer-789" \
  --session-id "session-002" \
  --event-timestamp "$(date -u +"%Y-%m-%dT%H:%M:%S.%3NZ")" \
  --payload '[
    {"conversational": {"role": "USER",      "content": {"text": "My production deployment is down because of a billing hold on our account"}}},
    {"conversational": {"role": "ASSISTANT", "content": {"text": "I understand the urgency. Let me connect you with our billing specialist team right away."}}}
  ]'

O LLM analisa o conteúdo da conversa e preenche todas as três chaves de esquema no registro de memória extraído —priority,agent_type, e sentiment — mesmo que nenhuma tenha sido fornecida como metadado do evento:

{
  "content": {"text": "Customer reported a production outage caused by a billing hold. Escalated to billing specialist."},
  "metadata": {
    "priority":   {"stringValue": "critical"},
    "agent_type": {"stringValue": "specialist"},
    "sentiment":  {"stringValue": "frustrated"}
  }
}

As regras de validação ainda se aplicam — a saída do LLM é restrita aos valores permitidos especificados, independentemente de o valor ter vindo de metadados de eventos ou inferência de conteúdo.

Como o LLM resolve conflitos entre eventos

Quando vários eventos em uma sessão carregam valores diferentes para a mesma chave de metadados, o LLM usa o. llmExtractionInstruction Isso determina qual valor manter no registro de memória resultante.

Por exemplo, considere uma sessão de suporte em que o primeiro evento tenha ocorrido priority: "low" e um evento posterior aumente parapriority: "critical". O LLM resolve isso com base na instrução:

Outro exemplo: para agent_type com a instrução “Prefira o tipo de agente mais especializado”. Hierarquia: expert > tier3 > tier2 > tier1 > bot”, se uma sessão começar com um bot e escalar para um agente de nível 2, o registro de memória será obtido. agent_type: "tier2"

Ingestão determinística de metadados

As chaves configuradas como STRICTLY_CONSISTENT seguem um caminho de ingestão diferente. O valor que você fornece no evento é o valor que cai no registro resultante. Não há inferência de LLM nem resolução de conflitos.

AgentCore A memória agrupa eventos por seus valores-chave determinísticos antes da extração. Por exemplo, eventos marcados department: "engineering" são processados separadamente dos eventos marcadosdepartment: "finance".

A consolidação opera dentro desses grupos. Um registro que compliance_level: "hipaa" nunca se funde com um registro rotuladocompliance_level: "standard". Isso torna as chaves determinísticas ideais para:

Se um evento não tiver valor para uma chave determinística, a chave estará ausente no registro resultante.

Os caminhos de gravação direta (BatchCreateMemoryRecordseBatchUpdateMemoryRecords) ignoram a extração. O tipo de STRICTLY_CONSISTENT extração não tem efeito sobre eles. Forneça metadados diretamente, como você já faz para essas APIs.

Criação direta de registros com Batch APIs

Para importações de base de conhecimento, estratégias autogerenciadas ou conteúdo pré-processado, use BatchCreateMemoryRecords (ouBatchUpdateMemoryRecords) para fornecer metadados explicitamente. Isso ignora totalmente a extração do LLM — o chamador controla os valores dos metadados.

A forma como os metadados são tratados nos registros criados em lote depende de você fornecer: memoryStrategyId

O exemplo a seguir cria um registro sem memoryStrategyId armazenar todos os metadados fornecidos:

aws bedrock-agentcore batch-create-memory-records \
  --memory-id "<memory-id>" \
  --records '[{
    "requestIdentifier": "import-001",
    "namespaces": ["support/customer-456"],
    "content": {"text": "Customer prefers phone support for urgent billing issues"},
    "timestamp": "2026-01-15T10:00:00Z",
    "metadata": {
      "priority":   {"stringValue": "high"},
      "agent_type": {"stringValue": "billing_agent"},
      "channel":    {"stringValue": "phone"},
      "ticket_id":  {"stringValue": "TKT-7890"}
    }
  }]'

Para impor a consistência do esquema, inclua o. memoryStrategyId Nesse caso, somente as chaves presentes nessa estratégia memoryRecordSchema são mantidas:

aws bedrock-agentcore batch-create-memory-records \
  --memory-id "<memory-id>" \
  --records '[{
    "requestIdentifier": "import-002",
    "namespaces": ["support/customer-456"],
    "memoryStrategyId": "<strategy-id>",
    "content": {"text": "Billing dispute resolved after account credit applied"},
    "timestamp": "2026-01-16T14:00:00Z",
    "metadata": {
      "priority":   {"stringValue": "medium"},
      "agent_type": {"stringValue": "billing_agent"},
      "channel":    {"stringValue": "phone"}
    }
  }]'

No segundo exemplo, se o esquema da estratégia definir apenaspriority,, e agent_typesentiment, então será channel removido silenciosamente do registro armazenado.

Atualizando registros com BatchUpdateMemoryRecords

BatchUpdateMemoryRecordssegue o mesmo comportamento de filtragem de memoryStrategyId metadados de. BatchCreateMemoryRecords O exemplo a seguir atualiza o conteúdo e os metadados de um registro existente:

aws bedrock-agentcore batch-update-memory-records \
  --memory-id "<memory-id>" \
  --records '[{
    "memoryRecordId": "<record-id>",
    "namespaces": ["support/customer-456"],
    "content": {"text": "Customer prefers phone support for urgent billing issues. Account credit applied."},
    "metadata": {
      "priority":   {"stringValue": "critical"},
      "agent_type": {"stringValue": "billing_agent"},
      "channel":    {"stringValue": "phone"}
    }
  }]'

Etapa 4: consultar com filtros de metadados

Os filtros de metadados são aplicados antes da execução da pesquisa de similaridade vetorial (pré-filtragem). Isso reduz o candidato definido primeiro. Como resultado, a pesquisa de K-nearest vizinhos (KNN) opera em um subconjunto menor e mais relevante.

Estrutura Filter

Cada filtro é uma { left, operator, right } expressão:

{
  "left":     { "metadataKey": "priority" },
  "operator": "EQUALS_TO",
  "right":    { "metadataValue": { "stringValue": "high" } }
}

Até 5 filtros podem ser combinados por consulta. Vários filtros são aplicados com AND lógica.

Operadores compatíveis

Observação: os metadados do evento ListEvents filtram somente no suporteEXISTS,NOT_EXISTS, eEQUALS_TO, e somentestringValue.

Recupere com filtros de metadados (pesquisa semântica + pré-filtro)

AtivadoRetrieveMemoryRecords, metadataFilters está aninhado por dentrosearchCriteria. O exemplo a seguir define o escopo dos resultados para registros de alta prioridade do ano atual, antes que a pesquisa semântica corresponda aos “problemas de cobrança”:

aws bedrock-agentcore retrieve-memory-records \
  --memory-id "<memory-id>" \
  --namespace "support/customer-123" \
  --search-criteria '{
    "searchQuery": "billing issues",
    "topK": 10,
    "metadataFilters": [
      {
        "left":     {"metadataKey": "priority"},
        "operator": "EQUALS_TO",
        "right":    {"metadataValue": {"stringValue": "high"}}
      },
      {
        "left":     {"metadataKey": "x-amz-agentcore-memory-createdAt"},
        "operator": "AFTER",
        "right":    {"metadataValue": {"dateTimeValue": "2026-01-01T00:00:00Z"}}
      }
    ]
  }'

A combinação de um filtro de metadados personalizado com um carimbo de data/hora gerado pelo sistema compacta o conjunto de candidatos em duas dimensões — prioridade comercial e atualidade — antes que a pesquisa por similaridade seja executada.

Lista com filtros de metadados (sem pesquisa semântica)

ListMemoryRecordsfornece filtragem de metadados sem pesquisa semântica. Isso é útil quando você precisa enumerar registros que correspondam a critérios específicos de metadados — por exemplo, listar todos os registros de alta prioridade de um cliente ou extrair todos os registros criados após uma data específica.

ListMemoryRecordsAtivado, metadataFilters é um parâmetro de nível superior:

aws bedrock-agentcore list-memory-records \
  --memory-id "<memory-id>" \
  --namespace "support/customer-123" \
  --metadata-filters '[
    {
      "left":     {"metadataKey": "priority"},
      "operator": "EQUALS_TO",
      "right":    {"metadataValue": {"stringValue": "high"}}
    },
    {
      "left":     {"metadataKey": "x-amz-agentcore-memory-createdAt"},
      "operator": "AFTER",
      "right":    {"metadataValue": {"dateTimeValue": "2026-01-20T00:00:00Z"}}
    }
  ]'

Combinando vários filtros

Essa consulta abrange a recuperação das discussões sobre ações do terceiro trimestre de 2026 em um namespace de cliente específico:

{
  "searchQuery": "portfolio rebalancing strategy",
  "topK": 10,
  "metadataFilters": [
    {
      "left":     {"metadataKey": "asset_class"},
      "operator": "EQUALS_TO",
      "right":    {"metadataValue": {"stringValue": "equities"}}
    },
    {
      "left":     {"metadataKey": "x-amz-agentcore-memory-createdAt"},
      "operator": "AFTER",
      "right":    {"metadataValue": {"dateTimeValue": "2026-07-01T00:00:00Z"}}
    },
    {
      "left":     {"metadataKey": "x-amz-agentcore-memory-createdAt"},
      "operator": "BEFORE",
      "right":    {"metadataValue": {"dateTimeValue": "2026-09-30T23:59:59Z"}}
    }
  ]
}

Os valores do filtro para carimbos de data/hora devem estar em UTC (formato ISO 8601). O serviço normaliza todos os timestamps armazenados para UTC antes da comparação, portanto, sempre expresse os valores do filtro em UTC.

Etapa 5: evolua seu esquema de metadados

AgentCore A memória suporta a evolução do esquema para que você possa adaptar sua configuração de metadados à medida que suas necessidades mudam.

Adicionar chaves indexadas

Você pode adicionar novas chaves indexadas a uma memória a qualquer momento:

aws bedrock-agentcore-control update-memory \
  --memory-id "<memory-id>" \
  --add-indexed-keys '[
    {"key": "customer_segment", "type": "STRING"}
  ]'

Novas chaves ficam imediatamente disponíveis para eventos recebidos e registros de memória. Os registros existentes não são preenchidos — somente registros novos ou atualizados contêm a nova chave. Você não pode remover uma chave indexada anteriormente, o que evita a perda acidental da capacidade de filtragem dos dados existentes.

Modificar o esquema de metadados de uma estratégia

Você pode adicionar, remover ou atualizar entradas livremente no esquema de metadados de uma estratégia. Isso controla quais metadados o LLM extrai das conversas futuras.

Por exemplo, para adicionar um novo resolution_type campo a uma estratégia existente:

aws bedrock-agentcore-control update-memory \
  --memory-id "<memory-id>" \
  --memory-strategies '{
    "modifyMemoryStrategies": [
      {
        "memoryStrategyId": "<strategy-id>",
        "memoryRecordSchema": {
          "metadataSchema": [
            {
              "key": "resolution_type",
              "type": "STRING",
              "extractionConfig": {
                "llmExtractionConfig": {
                  "definition": "How the customer support issue was resolved",
                  "validation": {
                    "stringValidation": {
                      "allowedValues": ["refund", "replacement", "escalation", "self-resolved"]
                    }
                  }
                }
              }
            }
          ]
        }
      }
    ]
  }'

Você também pode remover uma chave do esquema de metadados de uma estratégia se não quiser mais que o LLM extraia esse campo. A remoção de uma entrada do esquema interrompe a extração de novos registros, mas não afeta os metadados que já estão nos registros existentes.

Os registros de memória existentes não recebem retroativamente novos LLM-extracted campos. No entanto, quando as memórias mais antigas são consolidadas com as mais novas durante o ciclo de vida normal da memória, o registro consolidado é extraído novamente usando o esquema atual e incluirá os novos campos de metadados.

Cotas

Práticas recomendadas

Anti-patterns para evitar