Chris Betti's questions

Estou brincando com a ideia de exportar as estatísticas de um banco de dados da produção e aplicá-las em um banco de dados de teste (mesma estrutura, conjunto de dados pequeno). O objetivo é testar o software para alterações que introduzem planos de consulta caros em um ambiente de não produção antes que a alteração vá para a produção.

Eu não vejo nenhuma arte anterior sobre isso. Como posso aplicar estatísticas de uma instância de banco de dados para outra instância e bloquear essas estatísticas para realizar esse tipo de teste?

Entendo que o PostgreSQL armazenará campos grandes em um espaço de armazenamento separado automaticamente. Quando isso ocorre, há algo armazenado por linha para esse campo na tabela? Uma referência ou dica de algum tipo?

Dada uma tabela "SoftwareReleases":

| id | version |
|  1 | 0.9     |
|  2 | 1.0     |
|  3 | 0.9.1   |
|  4 | 1.1     |
|  5 | 0.9.9   |
|  6 | 0.9.10  |

Como faço para produzir esta saída?

| id | version |
|  1 | 0.9     |
|  3 | 0.9.1   |
|  5 | 0.9.9   |
|  6 | 0.9.10  |
|  2 | 1.0     |
|  4 | 1.1     |

Um projeto de web de hobby meu usa dados de muitas fontes, algumas planas, outras altamente normalizadas. Meu processo ETL resume todas as fontes em uma tabela lógica (que em breve incluirá alguns campos com vários valores). A tabela final é carregada em alguns ambientes de apresentação de dados separados (com base em Solr ou MySQL). Meu ambiente Solr exige um modelo desnormalizado (ele apenas carrega a tabela de saída transformada diretamente como um arquivo simples) e meus ambientes MySQL podem usar um modelo altamente normalizado (o carregamento envolve alguma normalização). Ambos os processos de carregamento do ambiente de apresentação são muito simples agora.

Para facilitar o uso de arquivos simples em todo o meu processo ETL (importante porque uso uma variedade de ferramentas para resumir e limpar os dados e fazer uso intenso de pipelines por motivos de desempenho), consegui reduzir campos com vários valores de minhas fontes para um único campo usando agrupamento ou seleção de melhor candidato.

Agora estou projetando os campos de vários valores que preciso preservar em minha saída. O processo de carregamento do MySQL é fácil porque já o normalizei com esses campos em mente. Mas estou tendo problemas com a parte do Solr:

• Não tenho experiência com campos "multiValued" no Solr
• o processo de carregamento de arquivo simples é atualmente muito simples, gostaria de preservar o máximo de simplicidade possível
• meus campos multiValor devem ser coordenados por posição dentro de um registro, por exemplo
  • registro X, campo A, posição 3 é uma licença #
  • registro X, campo B, posição 3 é o estado correspondente para aquela licença

Como posso projetar meu ETL para os campos de vários valores que pretendo preservar?

Algumas ideias que tive e que estou encontrando obstáculos:

• introduzir um registro "aditivo" usando a mesma chave de documento que ocupa sua própria linha no arquivo simples
  • não faço ideia por onde começar neste
• pré-montar valores em um único campo, analisar usando Solr, por exemplo
  • {[[123],[456]];[[MA],[CA]]} -> "123,MA;456,CA"
  • não tenho certeza se o Solr pode descompactar uma string e preservar as informações de posição apropriadamente nos campos

Não consegui encontrar informações sobre como coordenar valores de campo multiValor de campos separados. Permitindo o fato de que isso pode não ser suportado nativamente pelo Solr, ainda estou interessado em soluções para carregar campos multiValued no Solr de uma maneira quase tão simples quanto carregar um arquivo simples.