Em recentes debates sobre tecnologias emergentes – seja Rails, ou NoSQL – argumentos contra a escalabilidade e desempenho das mesmas s\u00e3o bastante frequentes. Se o mito do “Rails n\u00e3o escala” serve para nos ensinar algo, \u00e9 que estes argumentos tendem a se tornar grandes discuss\u00f5es sem muito fundamento, e que a maioria das pessoas, al\u00e9m de n\u00e3o entender bem o conceito de escalabilidade e suas implica\u00e7\u00f5es, faz julgamentos sem sequer ter experimentado as solu\u00e7\u00f5es em quest\u00e3o, ou se baseiam em uma \u00fanica experi\u00eancia desafortunada.<\/p>\n
Observado isso, vamos tentar entender melhor o que \u00e9 – e o que n\u00e3o \u00e9 – escalabilidade e desempenho. Infelizmente, n\u00e3o encontrei nenhuma boa defini\u00e7\u00e3o dos termos em dicion\u00e1rios de portugu\u00eas, ent\u00e3o traduzirei uma defini\u00e7\u00e3o em ingl\u00eas, do Wiktionary:<\/p>\n
* *Desempenho*
\n** O ato de desempenhar, executar uma a\u00e7\u00e3o, executar, alcan\u00e7ar, representar por meio de a\u00e7\u00e3o.
\n** O que \u00e9 desempenhado ou obtido, uma coisa feita ou acompanhada, um feito, um \u00eaxito, especialmente, uma a\u00e7\u00e3o elaborada ou de car\u00e1ter p\u00fablico.
\n** Um show ou concerto ao vivo.
\n** *Na ci\u00eancia da computa\u00e7\u00e3o: A quantidade de trabalho realizado por um sistema de computa\u00e7\u00e3o em rela\u00e7\u00e3o ao tempo e recursos utilizados. Melhor desempenho significa mais trabalho conclu\u00eddo em uma menor quantidade de tempo e\/ou usando menos recursos.*<\/p>\n
Nenhuma grande surpresa aqui. Simplificando, \u00e9 algo r\u00e1pido.<\/p>\n
* *Escalar*
\n** Alterar o tamanho de algo enquanto mantendo sua propor\u00e7\u00e3o, em especial, alterar um processo de forma a produzir uma quantidade muito maior do seu produto final.
\n** Realizar uma escalada.
\n** *Na ci\u00eancia da computa\u00e7\u00e3o: tolerar significantes aumentos de volume de dados ou outros fatores limitadores em potencial.*<\/p>\n
Isto sim pode ser uma surpresa. Escalabilidade n\u00e3o tem a ver com desempenho, tem a ver com propor\u00e7\u00f5es, gradua\u00e7\u00f5es. \u00c9 a medida na qual um sistema pode tolerar grandes aumentos no volume de dados processados e ainda assim manter propor\u00e7\u00e3o \u00e0 quantidade de recursos utilizados.<\/p>\n
Um sistema com desempenho horr\u00edvel – digamos, que demora 40 segundos para processar um request – ainda pode escalar muito bem, se, quando adicionado mais um servidor, ele passe a responder dois requests em 40 segundos.<\/p>\n
Mesmo sendo t\u00e3o diferentes, os dois conceitos possuem uma rela\u00e7\u00e3o no sentido que, se algo possui uma boa performance, voc\u00ea pode nunca precisar escal\u00e1-lo. Um bom exemplo \u00e9 o Tokyo, um banco de dados key-value que possui um desempenho fant\u00e1stico, realizando milh\u00f5es de escritas por segundo. Ele escala muito mal, mas devido ao seu alto desempenho, voc\u00ea vai demorar muito, para realmente precisar se preocupar com isso.<\/p>\n
Outro exemplo cl\u00e1ssico \u00e9 o Rails. Rails escala muit\u00edssimo bem, mas n\u00e3o tem uma boa performance, o que faz com que voc\u00ea precise se preocupar em escal\u00e1-lo quase que imediatamente. A maioria dos desenvolvedores, saindo de solu\u00e7\u00f5es com alto desempenho – como o PHP – nunca precisaram se preocupar com escalabilidade, e esta s\u00fabita preocupa\u00e7\u00e3o causou um choque. Assim nasceu o mito da n\u00e3o-escalabilidade do Rails, que na verdade n\u00e3o \u00e9 sobre escalabilidade =).<\/p>\n
Agora que este conceito est\u00e1 mais claro, podemos entender mais facilmente as descri\u00e7\u00f5es dos bancos de dados que est\u00e3o por vir. Existe um banco em cada extremo da situa\u00e7\u00e3o – alguns com \u00f3tima escalabilidade e p\u00e9ssimo desempenho, outros com o inverso, outros no meio do caminho, e alguns poucos satisfat\u00f3rios em ambos os aspectos. Veremos em breve.<\/p>\n","protected":false},"excerpt":{"rendered":"
Em recentes debates sobre tecnologias emergentes – seja Rails, ou NoSQL – argumentos contra a escalabilidade e desempenho das mesmas s\u00e3o bastante frequentes. Se o mito do “Rails n\u00e3o escala” serve para nos ensinar algo, \u00e9 que estes argumentos tendem…<\/p>\n","protected":false},"author":4445,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_mi_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[16947],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/posts\/402"}],"collection":[{"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/users\/4445"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/comments?post=402"}],"version-history":[{"count":2,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/posts\/402\/revisions"}],"predecessor-version":[{"id":437,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/posts\/402\/revisions\/437"}],"wp:attachment":[{"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/media?parent=402"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/categories?post=402"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.cancaonova.com\/desenvolvimentoti\/wp-json\/wp\/v2\/tags?post=402"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}