Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Busca de alta performance com GraphQL e Elastic...

Busca de alta performance com GraphQL e Elasticsearch

13 vezes mais rápido, 50% menos servidores e 30 vezes mais carga. Parece utopia mas não é. Saiba o porquê Go e GraphQL formam uma ótima combinação e como suas características se complementam para uma performance incrível. Entenda como Go ajudou a atingir esse resultado, como é a integração entre Go e Elasticsearch e como estruturar uma API GraphQL utilizando Go. Vamos entrar a fundo nos conceitos do GraphQL, conhecer as alternativas de bibliotecas existentes para GraphQL em Go, entender os seus desafios, limitações e mostrar como contornamos as dificuldades para extrair o melhor dessa combinação.

Guilherme Baptista

April 23, 2019
Tweet

More Decks by Guilherme Baptista

Other Decks in Programming

Transcript

  1. Busca de alta performance Busca de alta performance com GraphQL

    e Elasticsearch com GraphQL e Elasticsearch Guilherme Baptista TDC Florianópolis - Trilha Go, Abril de 2019. 1
  2. Agenda Agenda O que é performance? Qual problema queremos resolver?

    Como escolhemos Go? Como trabalhamos com Elasticsearch? Onde entra GraphQL na história? Resultados Re exões 2
  3. O que é performance? O que é performance? Estrangeirismo predileto

    na área de T.I. Não satisfeitos, ainda usamos: "Tá performando legal!" "Será que vai performar esse código?" "Essa API nova deu uma performada boa..." 4
  4. Tempo de resposta: 1 milissegundo 1 milissegundo Servidores: 150 mil

    dólares por mês; Taxa de erros: 97% das requisições. 8
  5. Serviço de alta Serviço de alta performance: performance: Alta velocidade;

    Baixa taxa de erros; Mínimo custo nanceiro; Etc. 9
  6. Tempo de resposta Tempo de resposta "Essa página demora quantos

    segundos para abrir?" Throughput suportado (rpm) Throughput suportado (rpm) "Quantos acessos por minuto esse site aguenta? 11
  7. Sites que demoram mais que 3 segundos 3 segundos v

    80% nunca voltam; 57% desistem do acesso; 50% falam mal para outras pessoas. 14
  8. Para cada 100 milissegundos 100 milissegundos a mais no tempo

    de resposta a Amazon perde -1% de suas vendas. -1% de suas vendas. 15
  9. Para cada 1 segundo 1 segundo a menos no tempo

    de resposta o Walmart ganha +2% de aumento em suas +2% de aumento em suas vendas. vendas. 16
  10. Com uma melhoria de 40% 40% no tempo de carregamento

    de suas páginas o Pinterest conseguiu um aumento de +15% no cadastro de usuários. +15% no cadastro de usuários. 17
  11. Para cada 1 segundo 1 segundo a mais no tempo

    de resposta a BBC perde -10% de seus usuários. -10% de seus usuários. 18
  12. Um estudo identi cou que quando sites cam fora do

    ar fora do ar v Queda de 100% nos acessos; Queda de 100% nas vendas; Aumento de 300% nos batimentos cardíacos de quem cuida do site. 20
  13. Ciência cognitiva Ciência cognitiva George A. Miller Mnemônica; Lei de

    Miller: 7 coisas de cada vez; Palácio da memória (Sherlock Holmes); Programação neurolinguística (PNL); Psicologia e informação. 22
  14. 1968 1968 A interação entre seres humanos e sistemas de

    informação. Quais os limites para manter a atenção de seres humanos ao interagirem com sistemas de informações? 23
  15. 24

  16. Até 100 milissegundos Até 100 milissegundos Ter a sensação de

    instantâneo. Até 1 segundo Até 1 segundo Ter a sensação de continuidade. 25
  17. Entre 1 e 10 segundos Entre 1 e 10 segundos

    Manter a atenção enquanto aguarda. Acima de 10 segundos Acima de 10 segundos Atenção perdida. 26
  18. FPS ( FPS (quadros por segundo quadros por segundo) )

    Olho humano: 12 FPS 12 FPS Tela de um celular moderno: 60 FPS 60 FPS 28
  19. Olho humano (12 FPS): 83 milissegundos 83 milissegundos Tela de

    um celular moderno (60 FPS): 16 milissegundos 16 milissegundos 29
  20. Até 16 milissegundos Até 16 milissegundos Não existe diferença real

    para renderização. Mais que 100 milissegundos 100 milissegundos Seres humanos perdem a percepção de instantâneo. 30
  21. API's: Idealmente, mantenha tudo abaixo de 100 milissegundos 100 milissegundos

    Nunca ultrapasse os 200 milissegundos 200 milissegundos 33
  22. Interfaces: Idealmente, renderize tudo em até 100 milissegundos 100 milissegundos

    Utilize técnicas de renderização progressiva e nunca ultrapasse 1 segundo 1 segundo 34
  23. enjoei.com.br enjoei.com.br Marketplace de moda com milhões de produtos que

    precisa: Fazer buscas em todos esses milhões de produtos; Aguentar picos de acessos por conta de programas na TV. 36
  24. O cenário O cenário Altos custos com infraestrutura; Tempo de

    resposta acima dos 200 milissegundos; Grande di culdade em aguentar picos de acessos instantâneos. 37
  25. O custo de reescrever tudo O custo de reescrever tudo

    "Se for pra mudar, tem que valer a pena." "Será que precisa mesmo?" https://roda.jeremyevans.net/ 41
  26. 42

  27. "Se for pra mudar, tem que valer a pena." "Se

    for pra mudar, tem que valer a pena." 47
  28. Muitos testes, estudos e benchmarks depois: Let's Go! Let's Go!

    Sempre no top 3 de qualquer benchmark; Mais opções de bibliotecas; Curva de aprendizado menor; Maior produtividade no dia a dia. 50
  29. Como servir dados via HTTP? Como servir dados via HTTP?

    Sem reinventar a roda ou fazer tudo na mão. Equilíbrio entre alta performance e usabilidade. Nossa escolha: https://github.com/go-chi/chi 53
  30. router := chi.NewRouter() router.Use( middleware.Logger, render.SetContentType(render.ContentTypeJSON), ) router.Get("/status", statusHandler) func

    statusHandler(w http.ResponseWriter, r *http.Request) { w.Write([]byte("ok")) } http.ListenAndServe(":8484", router) 54
  31. 1 segundo 1 segundo é igual a 1 mil milissegundos

    1 mil milissegundos que é igual a 1 milhão de microssegundos 1 milhão de microssegundos 58
  32. O que aprendemos: O que aprendemos: É a melhor opção

    para buscas complexas em um volume enorme de dados. É tão simples e prático que mesmo fazendo tudo errado ele funciona. A modelagem dos seus documentos é tudo. 62
  33. O que aprendemos: O que aprendemos: Não tentar usar o

    mesmo índice para responder perguntas diferentes. "keyword" ao invés de "text" faz toda diferença. Scripts são malignos. Arredondar datas economiza muito dinheiro. 63
  34. Como ler dados do Como ler dados do Elasticsearch com

    Go? Elasticsearch com Go? Nossa escolha: https://github.com/olivere/elastic 64
  35. client, _ := elastic.NewClient( elastic.SetURL("http://127.0.0.1:9201")) searchResult, _ := client.Search(). Index("products").

    Query(elastic.NewTermQuery("title", "sandália preta")). Do(context.Background()) var product Product for _, p := range searchResult.Each(reflect.TypeOf(product)) { product := p.(Product) fmt.Printf("%s", product.Title) } 65
  36. Elasticsearch Query DSL Elasticsearch Query DSL Uma lição que aprendemos:

    Toda biblioteca que tenta criar uma abstração para Elasticsearch resulta em código que ninguém entende. 67
  37. user := &User{} db.Model(user) .Where("name", "David").Where("occupation", "Code Artist") .Order("created_at DESC").Select()

    db.Model(user).Where("email", "[email protected]").Select() var users []User db.Model(&users).Where('update_at > ?', 1989).Select() for _, user := range users { fmt.Printf("%s", user.Name) } 70
  38. query do script_fields distance: { script: "doc['location'].distance(lat, lon)", params: {lat:

    latitude, lon:longitude} } fields ['_source'] query do filtered do query do multi_match do query str fields %w[title name] end 72
  39. query := elastic.NewMatchAllQuery() aggs := elastic.NewDateHistogramAggregation(). Field("time"). Interval("hour"). Format("yyyy-MM-dd HH")

    aggs.SubAggregation( "count", elastic.NewSumAggregation().Field("no_of_hits")) searchResult, _ := client.Search(). Index("my_index"). Type("_doc"). Query(query). Aggregation("date", aggs). Do(ctx) hour_agg, found := searchResult.Aggregations.Terms("date") 73
  40. { "size": 10, "query": { "bool": { "must": { "match":

    { "title": "vestido" } }, "filter": { { "term": { "color": "vermelho" } } } } } } 76
  41. Qual engine de templates? Qual engine de templates? Equilíbrio entre

    alta performance e usabilidade. Nossa escolha: https://github.com/shiyanhui/hero 77
  42. 78

  43. 79

  44. <%: func SearchProducts(term string, color string) %> { "size": 10,

    "query": { "bool": { "must": { "match": { "title": "<%==s term %>" } }, "filter": { { "term": { "color": "<%==s color %>" } } } } } } 80
  45. Precisa da biblioteca para Elasticsearch então? Precisa da biblioteca para

    Elasticsearch então? Sim Sim Controle de conexões com o Elasticsearch; Autenticação do cliente; Parser de resultados; Bulk API para inserção de dados. https://github.com/olivere/elastic 82
  46. Representação com conexões e arestas: { "user": { "productConnection": {

    "totalCount": 37, "productEdges": [ { "node": { "title": "vestido vermelho" }, "cursor": "726" } ] } } } 98
  47. Como paginar os dados: query userProducts($user_id: ID!, $first: Int, $after:

    ID) { user(id: $user_id) { products(first: $first, after: $after) { totalCount edges { node { title } cursor } } } } { "user_id": 1873, "first": 10, "after": "726" } 99
  48. Como uma busca é feita: query Search($search: Search, $first: Int,

    $after: ID) { search(search: $search) { term products(first: $first, after: $after) { totalCount edges { node { title seller { name } } cursor } } } } { "search": { "term": "vestido vermelho" }, "first": 10, "after": "236" } 101
  49. O resultado: "search": { "term": "vestido vermelho", "products": { "totalCount":

    152836, "edges": [ { "node": { "title": "vestido vermelho", "seller": { "name": "beatriz" } }, "cursor": "245" } ] } } 102
  50. search(search: $search) { products(first: $first, after: $after) { edges {

    node { ...productWithSeller } } } } product(id: $id) { ...productWithSeller } 105
  51. Agora imagine fazer isso... Agora imagine fazer isso... 4 vezes;

    4 vezes; Servidor nos EUA; Servidor nos EUA; Celular com 3G. Celular com 3G. 110
  52. 1 requisição para resolver tudo: currentUser { name gender }

    product { title price seller { name } comments { author { name } message replies { author { name } message } } } 112
  53. var waitGroup sync.WaitGroup user := &User{} product := &Product{} waitGroup.Add(1)

    go loadUser(&waitGroup, user) waitGroup.Add(1) go loadProduct(&waitGroup, product) waitGroup.Wait() 115
  54. Como servir dados via Como servir dados via GraphQL? GraphQL?

    Equilíbrio entre alta performance e usabilidade. Nossa primeira tentativa: https://github.com/graphql-go/graphql 116
  55. graphql.NewObject( graphql.ObjectConfig{ Name: "GraphQL", Fields: fields}) graphql.ObjectConfig{ Name: "Query", Fields:

    graphql.Fields{ "source": &graphql.Field{Type: graphql.String}}}) graphql.NewSchema(graphql.SchemaConfig{Query: queryType}) var query_args = graphql.FieldConfigArgument{ "term": &graphql.ArgumentConfig{Type: graphql.String}, var Query = &graphql.Field{ Type: gq.Query, Args: query_args, Resolve: resolvers.Query,} 117
  56. type Query { user(id: ID!): User product(id: ID!): Product }

    type User { id: ID name: String } type Product { id: ID title: String seller: User } 120
  57. type Query { user(id: ID!): User product(id: ID!): Product }

    type User { id: ID name: String } type Product { id: ID title: String seller: User } 124
  58. type UserResolver struct { Field fields.Field `graphql:"user"` Model models.User }

    func (resolver *Resolver) User(id params.Id) *UserResolver { return &UserResolver{Model: userModel.Find(id)} } func (userResolver *UserResolver) Name() *string { return &userResolver.Model.Name } 125
  59. Paralelismo por padrão: user { name } product { title

    comments { message author { name } } } 127
  60. 128

  61. hasComments := fields.RequestedForAt(ctx, productResolver, "comments") hasCommentAuthor := fields.RequestedForAt(ctx, productResolver, "comments.author")

    if hasComments { waitGroup.Add(1) go loadCommentsFor(productResolver.Model) } if hasCommentAuthor { waitGroup.Add(1) go loadCommentAuthorsFor(productResolver.Model) } 131
  62. 132

  63. 134

  64. Ruby é incrível, mas não Ruby é incrível, mas não

    precisa resolver tudo. precisa resolver tudo. Go é só uma das Go é só uma das opções. opções. 142
  65. Os problemas de Os problemas de amanhã serão maiores amanhã

    serão maiores que os de hoje. que os de hoje. Rust está vindo com tudo. Rust está vindo com tudo. 143
  66. Ainda podemos: Ainda podemos: Usar HTTP2 ao invés de HTTP1;

    Usar HTTP2 ao invés de HTTP1; Usar gRPC como protocolo de comunicação; Usar gRPC como protocolo de comunicação; Criar estratégias agressivas de cache; Criar estratégias agressivas de cache; Trabalhar com WebAssembly no navegador. Trabalhar com WebAssembly no navegador. 145
  67. query( $products: ProductSearch, $first: Int, $after: ID ) { search(search:

    $products) { term products(first: $first, after: $after) { edges { node { title } cursor } } } } 147
  68. query( $products: ProductSearch, $users: UserSearch, $first: Int, $after: ID )

    { search(products: $products, users: $users) { term products(first: $first, after: $after) { edges { node { title } cursor } } users(first: $first, after: $after) { edges { node { name } cursor } } } } 148
  69. Estudar novas linguagens abre Estudar novas linguagens abre a sua

    mente e acaba sendo a sua mente e acaba sendo divertido. divertido. Não tenha medo. 149
  70. 150