Eu realmente adoraria esse recurso também!

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Eu realmente preciso desse recurso

: +1:

Enquanto esperava esse recurso ser oficialmente finalizado e lançado, empacotei a solicitação pull # 2231 como um plug-in: yakaz / elasticsearch-action-updatebyquery .
Divirta-se.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

: +1:: orar:

+1

+1

Existe uma maneira de passar a pontuação da consulta como um parâmetro para o script de atualização? Preciso atualizar as entradas com pontuações atualizadas com base nos campos de seus filhos.

+1

+1

+1

@ scottc52 Você conseguiu fazer isso? Também estou procurando uma maneira de fazer isso.

+1

@gboivin Não. Estou fazendo uma consulta has_child e enviando uma solicitação de atualização separada, mas é lenta.

esperando esse recurso também ..

+1

+1

+1

+1

+1

+1

+1

Acabei de escrever um pequeno script para ajudar a esperar por algo ... mais "pronto para produção" ;-)

https://github.com/YannBrrd/esNodeUpdater

Sinta-se à vontade para comentar / atualizar ...

+1

Existe um status oficial para este recurso da equipe de desenvolvimento? Não vejo nenhuma entrada deles. Existem planos para adicionar este recurso ao núcleo ou é preferível que os usuários usem um plugin como o listado acima ?

Pretendemos voltar atrás, o principal motivo pelo qual colocamos isso em espera é que precisamos ter uma maneira de interromper a atualização existente por consultas, pois elas podem ser executadas por engano em uma grande quantidade de dados, causando problemas. .

+1. Obrigado pela atualização e por trabalhar nisso.

+1

+1

+1

+1

+1, parece útil

+1

+1

+1

+1

+1

+1

+1

+1

+2

+1

+10

+1

+1

+1

Você já pensou em implementar com uma chamada dupla de HTTP esse recurso? Eu penso em aquecedores que dão a possibilidade de armazenar a consulta e depois executar a consulta (não é realmente a mesma coisa, mas me faz pensar a respeito).

@kimchy você diz que pensa em uma maneira de interromper a atualização se ela foi lançada em uma grande quantidade de dados por engano. Se você pará-lo, talvez os dados indexados fiquem em estado inválido (talvez seja possível fazer rollback ...?). Talvez a melhor abordagem seja evitar erros.

Se você precisar de duas chamadas HTTP antes de acionar a atualização em massa real (1 para preparar e 1 para realmente acioná-la com um id de transação entre) e, em seguida, um manipulador de status de atualização (como o dataimporthandler em SolR) para saber quando a consulta está realmente concluída.

Não tenho certeza se ser muito claro, mas acho que pode ser uma solução para evitar chamadas incorretas ...

+1

+1

Eu também gostaria de votar a favor disso.

+1

@kimchy : Perfomance não pode ser a questão: Atualmente estou executando milhares de consultas para pesquisar dados (por exemplo, pesquisa de endereço de índice OSM para localizações de GPS - pesquisas são rápidas, ei, eu tenho ElasticSearch!) e atualizo cada documento em outro índice (por exemplo, para adicionar um endereço de texto não criptografado). Minhas atualizações adicionam novos campos. Uma atualização em massa dentro do ES deve ser mais eficiente do que 10.000 consultas de pesquisa + 10.000 solicitações de atualização (também usando atualizações em massa ...). Do ponto de vista da codificação e do tempo de execução, seria mais eficiente, por exemplo, o arquivo de atualização em massa obtém 20.000 linhas e poderia ter apenas 2 com o novo recurso - todos os dados movidos pela rede e tornando o ES ocupado lendo arquivos de atualização em massa ...

Talvez você concorde em adicionar limites para a operação de atualização, por exemplo, _update / _query = some_conditions & size = 1000 de forma que evite atualizar um milhão de documentos - e nós, como desenvolvedores, podemos decidir se executaremos 1000 * 1000 atualizações para atualizar um milhão de registros ... É deve retornar o número de documentos atualizados para dar algum controle se outra chamada de atualização for necessária.

+1

Para o meu cenário (enriquecer registros após pesquisas em outros indicadores), posso fazer de outra maneira: inserir dados primeiro no mongoDb, fazer pesquisas nos registros de atualização do ElasticSearch no Mongo, usar o rio mongo para obter os resultados finais no ElasticSearch para mostrá-lo na GUI (compilar no topo do ES). Alguém já experimentou esses cenários? Eu esperava que eu pudesse ir apenas para o ES ... até agora, eu rejeitei o uso de um banco de dados no meu projeto.

Oi,

você poderia simplesmente usar Couchbase + Elasticsearch para isso, pois Couchbase
oferece uma interface com Elasticsearch

Cordialement,
Yann Barraud

03/02/2014 seti123 [email protected] :

Para o meu cenário (enriquecer registros após pesquisas em outros indicadores), eu poderia
faça de outra maneira: insira dados primeiro no mongoDb, faça pesquisas em
ElasticSearch atualiza registros em Mongo, use o rio mongo para obter os resultados finais
no ElasticSearch para mostrá-lo na GUI (construído em cima do ES). Tem alguém
experiente com tais cenários? Eu esperava que eu pudesse ir apenas para o ES ... até
agora, rejeitei o uso de um banco de dados em meu projeto.

Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/elasticsearch/elasticsearch/issues/1607#issuecomment -33917801
.

+1

+100

+1

+1

Existe uma alternativa no ElasticSearch, por exemplo, acionar um script que executa uma ação quando novos dados são inseridos ou atualizados? Algum tipo antes do Index-Trigger poderia me ajudar a remover a cadeia de pré-processamento (fizemos agora Message Ques com REDIS e cadeia de processamento 0MQ antes de inserirmos Dados no ES - tudo isso custa largura de banda de rede para embaralhar dados para precessão paralela ... )

Gostaria de ver
http: // localhost : 9200 / index / type / _preprocessBeforeIndex? script = myDataAnalysisScript
http: // localhost : 9200 / index / type / _preprocessBeforeUpdate? script = myDataAnalysisScript
O Script deve ser capaz de adicionar novos campos ao registro atual antes que o ES o armazene / indexe (para evitar a ação de índice duplo após as alterações). Como trabalhamos muito com node.js, os scripts devem funcionar na linguagem necessária (em nosso Case JavaScript).

Melhor ainda se pudéssemos definir o Script no MAPEAMENTO por Tipo de dados ao invés de um indício gerado.
Qualquer plug-in disponível que seja capaz de acionar esses scripts? Qualquer documentação sobre o uso de ES API em Scripts?

+1

+1

+1

+1

+1

+1

+1

+1

+1

Esperando por este recurso ... (+1)

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Este recurso está em desenvolvimento?
Isso resolveria muitos problemas que são quase impossíveis de tratar de forma confiável no nível do aplicativo agora.

+1

+1

+1

Só para lembrar que desde meados fevereiro 2013 eu embalado, e mantida desde então, a "solicitação de recebimento oficial" # 2231 via @martijnvg do ramo como um plugin: Yakaz / ElasticSearch-ação-updatebyquery .

+1

+1

+1

+1

+1
Como é possível que este recurso desde fevereiro de 2013 ainda não tenha mesclado com o master?

+1
Idem no comentário de @KrzysztofWilczek . Por que o RP ficou estagnado no ano passado sem atualizações? Este é de longe o assunto mais comentado.

+1

Recebemos esse problema há vários meses (veja minhas postagens como @ seti123 janeiro / fevereiro) e gostaria de compartilhar nossos resultados - depois de desistir do DB + ES River (muita preocupação com as dependências de versão) avaliamos nosso caso de uso com sucesso com Crate Data (que usa ES como biblioteca e adiciona uma interface SQL para mapeamento e consulta, incluindo "atualização por consulta" https://crate.io/docs/stable/sql/dml.html#updating-data).
Um bom ponto de partida para ler sobre semelhanças e diferenças: https://crate.io/blog/crate_data_elasticsearch

Fechado a favor de # 2230

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

irá atualizar por setPostFilter de suporte de consulta?
edição # 12295

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

alguém pode revisar isso e dar feedback.
https://discuss.elastic.co/t/updatebyqueryresponse-throwing-timeout/29176

A atualização por consulta falha durante a atualização de mais de 20 + milhões de registros.

@ Praveen82 você está usando um plugin de terceiros. Este não é o lugar certo para solicitar suporte, você deve postar isso como um problema no repositório desse plugin.

https://github.com/elastic/elasticsearch/pull/15125 está implementando uma sintaxe que se parecerá um pouco com

curl -XPOST localhost:9200/index/type/_update_by_query -d '{
    "query" : { "term" : { "counter" : 0 } },
    "script" : {
      "inline": "ctx._source.counter += count",
      "params" : {
          "count" : 4
      }
  }
}'

O motivo pelo qual isso ficou parado por tanto tempo foi por causa dos tempos limite: até agora, havia uma maneira de iniciar trabalhos de longa execução no Elasticsearch e relatar seu status e outras coisas. Com a API de gerenciamento de tarefas (# 15347) eminente, peguei a tocha nas coisas do estilo "reindexar" e "atualizar por consulta" e iniciei-as novamente com a intenção de integrar com o gerenciamento de tarefas o mais rápido possível.

De qualquer forma, o # 15125 e quaisquer PRs subsequentes são o lugar para procurar esse recurso.

+1

+1

+1

+1

+1

A atualização por consulta está disponível em 2.3.0 e 5.0.0-alpha-1. Os documentos estão aqui .

A atualização por consulta em 2.3. + Ou 5. + é compatível com o plugin javascript?

A atualização por consulta em 2.3. + Ou 5. + é compatível com o plugin javascript?

Se você realmente quer, com certeza. No 2.3+ testamos update-by-query com o groovy e no 5.+ testamos com o indolor. Costumávamos testar contra o groovy e funcionou lá também. Espero que o javascript funcione bem.

O suporte a JS seria muito bom.

O suporte a JS seria muito bom.

Como falei, ele existe, basta instalar o plugin.

O problema com todas essas linguagens é que sua implementação na JVM não é orientada adequadamente para incorporação. É por isso que não o incluímos por padrão.

De qualquer forma, se você quiser falar mais sobre isso, acho que discuss.elastic.co é um lugar mais apropriado para isso.