Nuno's questions

Sou novo no Scylla e estou procurando configurar uma solução adequada de backup e restauração.

Acabei de testar a execução nodetool snapshot -t my_backupe vejo que o que ele faz é criar uma pasta de instantâneo chamada my_backup, dentro de cada pasta de espaço de chave e tabela.

Isso causa algumas limitações a meu ver:

1. Não consigo salvar facilmente os backups em outro servidor, caso esse servidor específico morra

2. Não consigo restaurar facilmente um backup em outro servidor (por exemplo, como um instantâneo diário para fins/testes de suporte à produção)

Como os DBAs normalmente armazenam backups em outro servidor e restauram um banco de dados inteiro em outro servidor?

--

Outro problema que notei é que nodetool listsnapshotsparece não mencionar a data de criação do instantâneo na saída.

Portanto, não consigo encontrar uma maneira de limpar instantâneos antigos.

Como faço para "excluir instantâneos com mais de 10 dias" ou "manter os últimos 3 backups", por exemplo?

No meu site, as respostas à postagem são classificadas com base em um algoritmo que depende de vários fatores: Reações, Qualidade da resposta, Reputação do usuário, Relatórios, Respostas à resposta, etc... (esses são apenas alguns exemplos)

Na maioria das postagens, a classificação das respostas é rápida, mas há algumas postagens que têm, digamos, 200 mil respostas e continuam crescendo, e a classificação de todas essas respostas leva mais de 1 segundo.

Estou ciente das VIRTUAL GENERATEDcolunas. No entanto:

1. Somente se o algoritmo dependesse de colunas da mesma tabela, eu poderia criar uma VIRTUAL GENERATEDcoluna indexada.

2. Porém, o algoritmo depende de fatores de outras tabelas, como a Reputação do Usuário.

3. E, infelizmente, se uma tabela tiver uma VIRTUAL GENERATEDcoluna, não será mais possível fazer ALTER ONLINE TABLE. Como essa tabela cresce a cada dia, isso é um grande inconveniente.

Quais são as minhas alternativas para otimizar um algoritmo tão complexo para que ordenar Respostas em Posts que cresceram muito seja rápido/instância?

Como o Reddit classifica milhares e milhares de respostas, por "Top/Best", muito rapidamente?

São principalmente postagens com anos, mas ainda recebendo respostas ativamente.

Eu estava pensando em manter algum tipo de "visão materializada", que seria atualizada a cada nova resposta, ou quando algo acontecesse em uma resposta (como uma Reação, etc). E, em seguida, classifique as respostas com base na chave dessa exibição (juntando-se ao restante). No entanto, isso aumentaria muito o armazenamento necessário e UPDATES/INSERTS no banco de dados. Esta é uma solução razoável?

(Eu uso InnoDB, arquivo por tabela, sem partições. MariaDB 10.8.)

No momento, estou explorando o uso de PARTITION, para um caso de uso específico que tenho.
Eu uso InnoDB, arquivo por tabela. MariaDB 10.8.

Eu estava lendo a página Manutenção de PARTIÇÃO no MySQL de Rick .

Gostaria de destacar este trecho:

WHERE X = 1234-- Isso permite que a "remoção de partição" olhe apenas naquela partição. Mas isso não é melhor do que INDEX(x)em uma tabela não particionada. E você provavelmente precisará desse índice de qualquer maneira; após a primeira 'remoção' até a partição desejada, você ainda precisa do índice. Não mais rápido.
Uma falácia comum: "O particionamento fará com que minhas consultas sejam executadas mais rapidamente". Não vai. Pondere o que é necessário para uma 'consulta pontual'. Sem particionamento, mas com um índice apropriado, há um BTree (o índice) para detalhar para encontrar a linha desejada. Para um bilhão de linhas, isso pode ter 5 níveis de profundidade. Com o particionamento, primeiro a partição é escolhida e "aberta", então uma BTree menor (de, digamos, 4 níveis) é detalhada. Bem, a economia do BTree mais raso é consumida ao abrir a partição. Da mesma forma, se você observar os blocos de disco que precisam ser tocados e quais deles provavelmente serão armazenados em cache, chegará à conclusão de que é provável o mesmo número de acertos de disco. Como as ocorrências de disco são o principal custo em uma consulta, o particionamento não ganha nenhum desempenho (pelo menos para este caso típico).

Eu entendo perfeitamente o que isso significa, mas eu tenho uma pergunta:

No MySQL/MariaDB, o desempenho dos índices diminui à medida que eles se tornam cada vez maiores?

Para um bilhão de linhas, ou para 100 bilhões de linhas, um bom índice é sempre melhor do que partições, em termos de desempenho?

--

Há também este bit que está mais próximo do que estou tentando beneficiar:

Caso de uso nº 3 -- Ponto de acesso. Isso é meio complicado de explicar. Dada esta combinação:
⚈ O índice de uma tabela é muito grande para ser armazenado em cache, mas o índice para uma partição pode ser armazenado em cache e
⚈ O índice é acessado aleatoriamente e
⚈ A ingestão de dados normalmente seria limitada por E/S devido à atualização do índice O
particionamento pode mantenha todo o índice "quente" na RAM, evitando assim muitas E/S.

A grande vitória do Caso nº 3: Melhorar o armazenamento em cache para diminuir a E/S para acelerar as operações.

O "índice em cache" também é válido para o InnoDB? Meu entendimento se CACHE INDEXaplica apenas ao MyISAM.
Ou isso está relacionado ao fato de estar no InnoDB Buffer Pool?

E em relação à diminuição de I/O, isso se aplica a servidores NVMe? My %iowaité 0,00, enquanto meu aplicativo é de gravação intensiva.

É meu entendimento que no SQL Server, você pode ter uma Chave Primária que não é clusterizada e ter outro índice que é o clusterizado.

Para mim, isso parece o mesmo que ter apenas uma chave primária e uma chave ÚNICA extra.

Então eu tenho duas perguntas:

1. se uma chave primária não estiver em cluster, ela armazena todas as colunas com ela? Ou apenas as colunas de chave primária e as colunas que fazem referência ao índice clusterizado?

2. Acabei de ler que, se o PK não for o índice clusterizado, o índice clusterizado NÃO precisa ser ÚNICO (mas é altamente recomendável). Isso significa que a tabela pode ser "classificada aleatoriamente" nas linhas com a mesma chave?

Gostaria de saber se é possível, em um SELECT, filtrar as linhas em que o texto dessa linha atual está contido no texto da linha seguinte.

Por exemplo, imagem que registramos "pesquisas" realizadas por um usuário, "enquanto ele digita":

1  something I searched
2  another search
3  this
4  this is a
5  this is a third
6  this is a third search
7  fourth
8  fourth search
9  here's a ry
10 here's a typo

As linhas 3-6 são efetivamente as mesmas - apenas o usuário estava um pouco "lento" digitando, então salvamos várias vezes.
Linhas 7-8 o mesmo também.
As linhas 9-10 são as mesmas, mas houve um erro de digitação.

Estou procurando fazer um SELECTque retornaria apenas as seguintes linhas:

1  something I searched
2  another search
6  this is a third search
8  fourth search
9  here's a ry
10 here's a typo

Algo assim é possível?

Observação - não há nenhuma garantia de que os IDs estarão em uma sequência para um usuário específico. Então, não posso simplesmente JOINcom a própria tabela, pelo id = id+1. Tudo o que posso fazer é ORDER BY idcolocá-los em ordem.

Digamos que eu tenha um sistema que tenha grupos e postagens nesses grupos.

Um grupo pode ter vários "grupos filhos"

Grupo 1 > Grupo 2 > Grupo 3
Grupo 1 > Grupo 2 > Grupo 4
Grupo 1 > Grupo 5 > Grupo 6
...

Então eu tenho essas duas tabelas:

Groups (*GroupId*, Name, ParentGroupId, ...)
Posts (*PostId*, GroupId, UserId, Text, ...)

Exibir uma lista das últimas 10 postagens no Grupo 3, 4 e 6 não é um problema.
Um índice em GroupIdfaz isso ( WHERE GroupId=12345 ORDER BY PostId DESC).

No entanto, o desafio que estou tendo é como posso fazer postagens de lista do Grupo 2 criadas diretamente no Grupo 2, mas também nos filhos (Grupo 3 e 4), e o mesmo para o Grupo 1 (listar postagens no Grupo 1 e em todos os filhos , ordenado).

A única coisa em que consigo pensar é criar uma "tabela de indexação" extra que terá uma lista de PostIdcada grupo pai e usá-la para recuperar as postagens. Mas, temo que seja difícil manter e garantir que seja preciso (como usar um TRIGGER). E se acontecer um bug e depois tivermos que corrigir o índice, reconstruir todo o índice novamente, etc...

Existe um jeito melhor de fazer isso?
Eu esperava usar algo mais nativo e auto-mantido.

Eu uso MariaDB 10.4 e Sphinx Search.

O que significa quando dizemos que an ENUMtem um charset de utf8mb4, versus latin1?

Meu entendimento é que o ENUMcontém um índice numérico (1, 2, 3, 4...) que identifica qual dos ENUMvalores (abc, def, ghi, jkl...).
Se eu usar utf8mb4para uma ENUMcoluna, a coluna está usando mais armazenamento do que usaria se eu usasse latin1?

Se eu tiver uma tabela com a seguinte chave primária:

PRIMARY KEY (id)

E eu quero consultar documentos escritos por alguém (por exemplo, exibir uma visualização dos últimos 20), classificados por seu "id", então criei um índice:

INDEX from_id (from, id)

O "id" no final desse índice é redundante porque termina com a chave primária?
Se sim, por quê?

Na verdade, estou lutando para entender o problema aqui. Eu li em todos os lugares dizendo que UPDATE se beneficia de índices na cláusula WHERE.

No entanto, esta consulta,

UPDATE `documents` SET `read`="1" WHERE `docid` IN (<subquery>)

não parece estar usando um índice. A tabela documentstem um índice docidintermitente read.

Quando faço um EXPLAIN, vejo possible_keys = NULLe rows = 8011008(tabela cheia). A subconsulta usa chaves e lê as linhas apropriadas (2 linhas).

Por outro lado, esta consulta:

SELECT * FROM `documents` WHERE `docid` IN (<subquery>)

usa o índice docide é executado muito rapidamente. Ele lê algumas linhas a mais do que o necessário (conforme EXPLAIN), mas totalmente aceitável.

Existe alguma explicação para isso?
Eu uso o MariaDB 10.

Como uma observação engraçada (em relação a SELECT), se <subquery>eu usar um UNION, enquanto a subconsulta parece obter o número adequado de linhas, parece que a consulta primária NÃO usa o índice e faz uma verificação completa da tabela.

Se no UPDATEeu uso JOINem vez de IN, os índices são usados ​​corretamente. Resolvi meus problemas usando JOIN.

Na consulta abaixo, frome tidsão índices da repliestabela.

SELECT * FROM `replies`
WHERE `from`="<userId>"
OR `tid` IN (SELECT `tid` FROM `posts` WHERE `from`="<userId>")

Ao usar "OR", parece que ele faz uma varredura completa da tabela (~ 3 milhões de linhas). O EXPLAINdiz que uma possível chave seria from, mas não usa nenhuma.

No entanto, na consulta abaixo, frid_lte frid_gtsão indexados. As duas colunas estão em um índice complexo (frid_lt, frid_gt), mas frid_gttambém possui seu próprio índice.

SELECT `mid` FROM `messages`
WHERE `frid_lt`="<userId>" OR `frid_gt`="<userId>"

E esta consulta usa dois índices. O EXPLAINdiz "index_merge" e "Usando sort_union(frid_lt,frid_gt); Usando where".

Por que a primeira consulta não usa uma mesclagem de índice?
Existe alguma melhoria que eu possa fazer para que o mecanismo também use uma mesclagem de índice?

Estou convertendo algumas das minhas tabelas para utf8mb4, bem como a conexão de PHP para MySQL para utf8mb4. Isso é para que eu possa oferecer suporte a caracteres usados ​​para Emoji em meu site.

Tenho duas dúvidas sobre essa mudança:

1) É um problema ter algumas tabelas como "utf8", mesmo que a conexão com o MySQL agora seja "utf8mb4"? Pode haver conflitos de agrupamento?

2) As tabelas "utf8mb4" usam mais espaço em disco, mesmo que não haja nenhum caractere utf8mb4 armazenado nelas?

3) Você me recomendaria mudar todas as tabelas para utf8mb4?

Obrigada!

Eu tenho lido sobre os formatos de arquivo do MySQL Antelope e Barracuda há algum tempo, e me pergunto se poderia me beneficiar com Barracuda e Compression.

Atualmente, meu servidor está usando o Antelope, pois é o padrão do MySQL.
Muitas vezes tive problemas com memória devido ao grande banco de dados que tenho. Meu banco de dados está aumentando a cada dia.

Parece que a compactação está trazendo benefícios para algumas pessoas, como:
http://www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/

Entendo que a memória e o espaço em disco podem ser menores, mas não tenho certeza se entendi isso (citado do artigo):
"~ 5% de carga da CPU de acordo com o topo (de 80 a 100%, principalmente aguardando E/S)
0,01 segundo tempo médio de pesquisa por chave primária (de 1 a 20 segundos antes da conversão)"

Achei que essas duas coisas NÃO melhorariam, porque se os dados forem compactados, o servidor terá que descompactar para obter os dados originais novamente, então não faz sentido que o uso da CPU aumente?

Isso beneficia você em aplicativos intensivos de leitura/gravação? Você me recomendaria mudar para Barracuda e Compression?

Você está ciente de algum problema do Barracuda?
Parece que a resposta da seguinte pergunta aponta alguns problemas, mas como é de 2011, eu diria que eles já estão corrigidos: https://serverfault.com/questions/258022/mysql-innodb-how-to-switch -para-barracuda-formato

No MySQL InnoDB, qual é a diferença entre COMPRESSED, COMPACT e DYNAMIC para ROW_FORMAT?

Quais são os benefícios entre si?