Esse comportamento está documentado em algum lugar e a precisão dupla total pode ser ativada?
consultas de reprodução:
select 1e-130; /* 0.0...1 result */
select 1e-131; /* 0 result */
reprodução online: https://dbfiddle.uk/5uwlkJaB
CREATE TABLE public.article (
id uuid NOT NULL,
tags _text NULL,
CONSTRAINT article_pkey PRIMARY KEY (id)
);
Tenho o requisito de carregar artigos que possuam uma tag que esteja em uma lista grande (pelo menos 300 tags) do banco de dados:
SELECT * FROM public.cms_article where tags @> ARRAY['my_long_extra_long_tag_1', '...', '...', 'my_long_extra_long_tag_300'];
Mas tenho um problema de desempenho. Alguém tem experiência com tal requisito? Qual índice seria o melhor? O número de artigos é inferior a 5.000.
Estou administrando um cluster galera com 3 nós, servindo uma aplicação Laravel e o HAProxy é a porta de entrada para o cluster. Tivemos um problema interessante e não consigo descobrir por que houve uma mensagem de erro no aplicativo Laravel. Aqui está o que eu sei: Às 13:25:36 havia uma nota no Nó1, que ... connection to peer f3e3XXXX-XXX with addr tcp://X.X.X.X:4567 timed out, no messages seen in PT3S, ...Este IP representa o Nó2. Aproximadamente no mesmo horário 13:25:37, no Nó2, a seguinte mensagem apareceu nos logs ... WSREP: (f3e3XXXX-XXX, 'tcp://X.X.X.X:4567') turning message relay requesting on, nonlive peers: tcp://X.X.X.X:4567 ...Este 2º IP representa o Nó1. Postarei um registro mais detalhado posteriormente na postagem.
Portanto, meu entendimento é que poderia ter havido um problema de rede entre os clusters e o Nó2 (e 3) teve que se juntar novamente ao cluster. Enquanto isso, alguém acionou o aplicativo Larave que fez uma consulta ao cluster. Mas esta solicitação acabou em uma mensagem de erro dizendo:[2023-11-07 13:25:46] production.ERROR: SQLSTATE[08S01]: Communication link failure: 1047 WSREP has not yet prepared node for application use .....
Se meu entendimento de como um cluster deve funcionar estiver correto, não tenho ideia do que aconteceu. O cluster galera não deveria ser capaz de gerenciar se um nó desaparecer do cluster e usar um nó existente para lidar com a consulta recebida? Talvez esse fosse um problema do HAProxy e ele não conseguiu detectar que os Node2 e 3 estão indisponíveis e enviou a consulta para lá de qualquer maneira?
Esse problema permaneceu por cerca de 10 segundos e o cluster está funcionando bem desde então (acho que ... wsrep_cluster_sizeé 3ATM, então deve estar OK).
Agora não quero " enviar spam " para esta postagem com todos os logs, então inserirei os logs dos Node1 e 2 no pastebin e URLs serão fornecidos.
!!! Alguém pode me explicar o que aconteceu exatamente nesta situação? Talvez uma maneira de evitar isso no futuro? !!!
Agradeço antecipadamente !
Registros do MariaDB: https://pastebin.com/SpDbe7Bb
Registros do Laravel:
[2023-11-07 13:25:46] production.ERROR: SQLSTATE[08S01]: Communication link failure: 1047 WSREP has not yet prepared node for application use (SQL: select * from .......) {"exception":"[object] (Illuminate\\Database\\QueryException(code: 08S01): SQLSTATE[08S01]: Communication link failure: 1047 WSREP has not yet prepared node for application use (SQL: select * from .......) at /var/www/html/myproject/releases/184/vendor/laravel/framework/src/Illuminate/Database/Connection.php:671)
Temos algumas consultas bastante grandes em nosso banco de dados postgresql (13.8) de produção que excedem o padrão 1024 para track_activity_query_size(algumas consultas têm mais de 100k). Aumentei esse valor para 8192, mas ele ainda não captura algumas de nossas consultas.
Estou me perguntando:
- Quão alto posso definir isso razoavelmente (li que 1 MB é o máximo) sem incorrer em problemas de desempenho?
- Quais métricas posso monitorar para rastrear se eu definir um valor muito alto?
Eu gostaria de defini-lo para 256k, ou possivelmente mais, mas parece que pode ser excessivo.
Um usuário relata que a taxa de transferência da consulta de intervalo é muito maior do que o esperado ao definir spark.cassandra.input.readsPerSec no conector spark-cassandra.
Dependências de trabalho. A versão do driver Java está definida como 4.13.0.
<dependency>
<groupId>com.datastax.spark</groupId>
<artifactId>spark-cassandra-connector_2.12</artifactId>
<version>3.2.0</version>
<exclusions>
<exclusion>
<groupId> com.datastax.oss</groupId>
<artifactId>java-driver-core-shaded</artifactId>
</exclusion>
</exclusions>
</dependency>
...
<dependency>
<groupId>com.datastax.oss</groupId>
<artifactId>java-driver-core</artifactId>
<version>4.13.0</version>
</dependency>
Existem duas etapas no trabalho (ambas do STF):
Dataset<Row> dataset = sparkSession.sqlContext().read()
.format("org.apache.spark.sql.cassandra")
.option("table", "inbox_user_msg_dummy")
.option("keyspace", "ssmp_inbox2").load();
-e-
Dataset<Row> olderDataset = sparkSession.sql("SELECT * FROM inbox_user_msg_dummy where app_uuid = 'cb663e07-7bcc-4039-ae97-8fb8e8a9ff77' AND " +
"create_hour < '" + minus180DaysInstant + "'");
Configuração do trabalho:
SparkConf sparkConf = new SparkConf()
.setMaster("local[*]") //uncomment while running in local
.setAppName("inbox-gateway-spark-job")
.set("spark.scheduler.mode", "FAIR")
.set("spark.cassandra.connection.port", "9042")
.set("keyspace", "ssmp_inbox2")
.set("spark.cassandra.connection.host", "cass-556799284-1-1276056270.stg.ssmp-inbox2-stg.ms-df-cassandra.stg-az-southcentralus-6.prod.us.walmart.net,
cass-556799284-2-1276056276.stg.ssmp-inbox2-stg.ms-df-cassandra.stg-az-southcentralus-6.prod.us.walmart.net,
cass-556799284-3-1276056282.stg.ssmp-inbox2-stg.ms-df-cassandra.stg-az-southcentralus-6.prod.us.walmart.net")
.set("spark.cassandra.auth.username", "ssmp-inbox-app-v2")
.set("spark.cassandra.auth.password", "*")
.set("spark.cassandra.input.consistency.level", "LOCAL_ONE")
.set("spark.cassandra.concurrent.reads", "1")
.set("spark.cassandra.input.readsPerSec", "10")
.set("spark.cassandra.input.fetch.sizeInRows", "10")
.set("spark.cassandra.input.split.sizeInMB", "10")
.set("spark.cores.max", "20")
.set("spark.executor.memory", "20G")
.set("spark.yarn.executor.memoryOverhead", "12000")
.set("spark.cassandra.read.timeoutMS", "200000")
.set("spark.task.maxFailures", "10")
.set("spark.cassandra.connection.localDC", "southcentral");
Observe que o Spark está limitando os núcleos reais a 16 porque os trabalhadores têm 8 núcleos. Existe 1 executor.
Quando o trabalho é executado, observa-se que há aproximadamente 22 mil consultas/s de intervalo para o primeiro FTS quase saturando a CPU no cluster, e para o segundo FTS, há aproximadamente 725 consultas/s de intervalo na tabela.
A expectativa é que, com um total de 16 núcleos Spark, o rendimento da consulta de intervalo seja limitado a 160/s (spark.cassandra.input.readsPerSec * spark cores).
Este raciocínio está correto? Qual é a recomendação para controlar a taxa de transferência de leitura do conector spark-cassandra?
Eu sei que outros usuários já configuraram esse acelerador com sucesso antes, mas nunca analisamos atentamente qual é o rendimento resultante. Esta parece ser uma grande discrepância porque as duas etapas estão essencialmente executando a mesma operação - uma varredura completa da tabela. As consultas que o conector executa são as mesmas.
O esquema:
CREATE TABLE ssmp_inbox2.inbox_user_msg_dummy (
user_id text,
create_hour timestamp,
app_uuid text,
message_id text,
app_name text,
create_ts bigint,
is_actiontaken boolean,
is_compensable boolean,
is_deleted boolean,
is_read boolean,
message_payload text,
mini_app_name text,
notification text,
PRIMARY KEY ((user_id, create_hour, app_uuid), message_id)
) WITH CLUSTERING ORDER BY (message_id DESC)
AND additional_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
A pergunta:
SELECT * FROM ssmp_inbox2.inbox_user_msg_dummy WHERE token(user_id, create_hour, app_uuid) >= token(G9e7Y4Y, 2023-08-10T04:17:27.234Z, cb663e07-7bcc-4039-ae97-8fb8e8a9ff77) AND token(user_id, create_hour, app_uuid) <= 9121832956220923771 LIMIT 10
FWIW, o tamanho médio da partição é 649 bytes, o máximo é 2,7kb.
Eu tenho uma tabela com 2 campos:, id (primary key) fld_1 texttenho 1 linha na tabela de destino, por exemplo 1 'hello world', e tenho um arquivo tsv de origem com 1 linha 1\t:. Depois de carregar na tabela de destino, espero ver 1 null, mas os dados não mudam e ainda recebo 1 'hello world'
a configuração que 'dsbulk.schema.nullToUnset': 'false'me ajudou, mas me parece que não é a melhor solução. Existem maneiras adequadas de carregar dados com valores nulos ou a solução fornecida está tudo bem?
Fui notificado de que a unidade de log de transações de uma instância SQL que gerencio está sendo preenchida. Comecei, descobri qual log de transações estava crescendo e fui ver por que o tlog estava crescendo. Olhando para sys.databases, a descrição de reutilização de log era active_transaction. Não é grande coisa, imaginei que poderia dar uma olhada e encontrar a sessão que executa a transação no banco de dados e descobrir os próximos passos. Este é um banco de dados de desenvolvimento, então presumi que um desenvolvedor deixou uma transação aberta e eu só precisaria entrar em contato e fechar a transação.
Agora vamos às coisas estranhas. Usei DBCC OPENTRAN para encontrar a transação aberta mais antiga no banco de dados, há duas curiosidades na saída.
- O ID da sessão está listado como 53s, nunca vi um ID de sessão com uma letra,
- O horário de início da transação é a partir de 03/11/2023, mas o servidor foi reiniciado em 06/11/2023.
Acho que posso colocar o banco de dados no modo de usuário único com reversão imediata e depois voltar ao modo multiusuário, e isso resolverá o problema. Estou adiando isso por enquanto, porque não entendo o que aconteceu, ou como e diabos as coisas acabaram assim.
Quero um determinado comportamento para transações no Postgresql, mas não sei dizer se é possível. Eu descreveria esse comportamento como “Bloqueio de leitura otimista”, mas esse não parece ser o termo certo para isso.
Aqui está o comportamento que eu quero:
- Minha transação começa. Seu nível de isolamento de transação é “leitura repetível” ou “serializável”.
- Na transação eu li a linha A.
- Na transação, leio e escrevo mais um pouco, mas nunca atualizo a linha A.
- Tento confirmar a transação.
Agora preciso que a transação falhe, se a linha A tiver sido alterada por alguma outra transação durante o tempo de vida da minha transação. Se a linha A não foi alterada, desejo que a transação seja confirmada.
Existe uma maneira de fazer isso no Postgresql?
Minha abordagem alternativa seria atualizar a linha A com algum valor aleatório na minha transação, para forçar um conflito de gravação. No entanto, isso significaria muitos conflitos desnecessários, porque sem forçar conflitos, a linha A raramente seria atualizada, mas frequentemente lida.
O requisito é: Os usuários devem ser capazes de definir a estrutura do documento que desejam armazenar.
Por exemplo, um usuário pode decidir armazenar um extrato bancário com a seguinte estrutura:
- data_post (data)
- detalhes (texto)
- débito (número)
- crédito (número)
- data_valor (data)
- referência (texto)
em seguida, selecione um arquivo para carregar no banco de dados.
Outro usuário ou o mesmo usuário também pode carregar um documento diferente com uma estrutura diferente.
Se conhecermos todas as diferentes estruturas de documentos disponíveis, podemos criar todas as tabelas do banco de dados, mas o sistema deve ser tal que o usuário possa carregar qualquer tipo de documento, e definir suas próprias estruturas.
Estou procurando uma maneira de salvar todas as linhas dos documentos em uma única tabela, se possível. Ou devo criar dinamicamente uma nova tabela quando o usuário definir uma nova estrutura de documento para carregar? É este o melhor caminho?
Nas propriedades do banco de dados em Query Store, o "Intervalo de coleta de estatísticas" é definido como 1 hora. Isso também é confirmado consultando a visualização query_store_runtime_stats_interval- todos os intervalos abrangem exatamente 1 hora. No entanto, ao visualizar relatórios como “Consumo geral de recursos”, é possível selecionar “Minuto” no menu suspenso “Tamanho da agregação” e mostra dados que parecem plausíveis.
Consegui capturar uma consulta usada no "Relatório de principais consultas que consomem recursos" e parece que ele exibe todos os planos, que também foram executados no intervalo selecionado de 1 minuto, mas as estatísticas ainda parecem se referir ao intervalo completo de coleta. Portanto, meu palpite seria não confiar em nada para intervalos menores que o intervalo de coleta. Estou correto ou os relatórios mostram dados confiáveis?
SELECT TOP (@results_row_count)
p.query_id query_id
, q.object_id object_id
, ISNULL(OBJECT_NAME(q.object_id),'') object_name
, qt.query_sql_text query_sql_text
, ROUND(CONVERT(float, SUM(rs.avg_duration*rs.count_executions))*0.001,2) total_duration
, SUM(rs.count_executions) count_executions
, COUNT(distinct p.plan_id) num_plans
FROM sys.query_store_runtime_stats rs
JOIN sys.query_store_plan p ON p.plan_id = rs.plan_id
JOIN sys.query_store_query q ON q.query_id = p.query_id
JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
WHERE NOT (rs.first_execution_time > @interval_end_time OR rs.last_execution_time < @interval_start_time)
GROUP BY p.query_id, qt.query_sql_text, q.object_id
HAVING COUNT(distinct p.plan_id) >= 1
ORDER BY total_duration DESC
