{"id":8,"date":"2009-08-09T11:21:00","date_gmt":"2009-08-09T09:21:00","guid":{"rendered":"http:\/\/beta.expertosenti.com\/2009\/08\/escalar-la-base-de-datos-sharding\/"},"modified":"2017-04-24T16:48:52","modified_gmt":"2017-04-24T14:48:52","slug":"escalar-la-base-de-datos-sharding","status":"publish","type":"post","link":"https:\/\/www.xpnti.net\/es\/escalar-la-base-de-datos-sharding\/","title":{"rendered":"Escalar la base de datos. Sharding"},"content":{"rendered":"<div style=\"text-align: justify;\">En los entornos Web 2.0, tenemos b\u00e1sicamente el modelo de <span style=\"font-weight: bold;\">embarazadas<\/span>, donde cada petici\u00f3n es independiente de las otras. Jugamos con la escala, cada petici\u00f3n HTTP en el fondo la podr\u00edamos tratar en un servidor diferente y si nuestro servidor<span style=\"font-weight: bold;\"> HTTP <\/span>tipo responde en 1 segundo, pues nuestro pico m\u00e1ximo de peticiones por segundo ser\u00eda el de n\u00famero de servidores Web\/HTTP disponibles.<br \/>Hasta aqu\u00ed todo bien, voy buscando dinero y comprando servidores. Pero es muy raro no tener persistencia, gesti\u00f3n de usuarios, contenidos, etc&#8230;, y como tener todos los servidores sincronizados es muy complicado (y m\u00e1s si tenemos <span style=\"font-weight: bold;\">UGC (user generated content)<\/span>), seguramente tendremos en alg\u00fan lugar una base de datos con nuestros usuarios, perfiles,comentarios,contenidos, todos ellos con muchas modificaciones constantes, recordad UGC&#8230; (el causante de todos los males&#8230;).<\/p>\n<p>Para seguir con la analog\u00eda de las embarazadas, si solo tenemos una base de datos es como si todas quisieran ir al mismo <span style=\"font-weight: bold;\">ginec\u00f3logo<\/span> y claro llega un momento que se satura la base de datos (solo puede asistir\/visitar a una embarazada en el mismo momento).<\/p>\n<p>Por tanto una opci\u00f3n puede ser tener m\u00e1s instancias de <span style=\"font-weight: bold;\">ginec\u00f3logo\/base de datos <\/span>y derivar la petici\u00f3n a la base de datos adecuada donde tendremos toda la informaci\u00f3n que tipicamente pueda necesitar. Esto lo que implica es que habr\u00e1n muchos datos repetidos de los que tendremos que hacernos cargo a nivel de c\u00f3digo, con los que vulneramos parte de las <a href=\"http:\/\/es.wikipedia.org\/wiki\/Normalizaci%C3%B3n_de_bases_de_datos#Formas_Normales\">formas normales<\/a> de las bases de datos, as\u00ed que mucho cuidado, no romp\u00e1is nada.<br \/>Este particionado de peticiones a diferentes grupos <span style=\"font-weight: bold;\">disjuntos<\/span> de base de datos se denomina Sharding (o romper en piezas). La principal ventaja que aporta si se hace bien es que volvemos a tener un modelo de escalabilidad casi lineal con los costes. Vas metiendo servidores y vas aguantando la carga.<br \/>El gran problema del <a href=\"http:\/\/en.wikipedia.org\/wiki\/Shard_%28database_architecture%29\"><span style=\"font-weight: bold;\">Sharding<\/span><\/a> es que puede requerir un re-dise\u00f1o de toda la aplicaci\u00f3n, y la mayor\u00eda de Start-ups se lo plantean cuando llegan a los limites de su tecnolog\u00eda (2 o 4 sockets en Intel\/AMD?) y est\u00e1n perdiendo ingresos (o p\u00e9rdidas :)) por falta de rendimiento. Y claro son muchas horas de no dormir e introducir bugs y dem\u00e1s&#8230;<br \/>As\u00ed que si te estas planteando desarrollar el siguiente Facebook, Youtube, Flick, Twitter o hasta cierto punto Amazon, considera estos consejos y haz lo que creas oportuno:<\/div>\n<ul style=\"text-align: justify;\">\n<li>Empieza desde ya con 2 instancias independientes de servidor HTTP, sea <a href=\"http:\/\/tomcat.apache.org\/\">Tomcat<\/a>, <a href=\"http:\/\/mongrel.rubyforge.org\/\">Mongrel<\/a>, <a href=\"http:\/\/httpd.apache.org\/\">Apache<\/a>, <a href=\"http:\/\/www.iis.net\/\">IIS<\/a>, <a href=\"http:\/\/www.jboss.org\/\">JBoss<\/a>. As\u00ed comprobaras todos los problemas que te puede provocar la escalabilidad horizontal en HTTP.<\/li>\n<li>Empieza ya con dos instancias (como minimo) de base de datos y accede a ellas con nombres diferentes (mysqlPares.midominio.com y mysqlNones.midominio.com), as\u00ed cuando excedas la capacidad de 1 servidor los podr\u00e1s separar con solo un simple cambio de fichero Hosts\/DNS.<\/li>\n<li>Decide por qu\u00e9 clave quieres romper la base de datos y piensa que las consultas inter base de datos seran muy costosas. Para implementar buscadores, mejor tener una instancia independiente con <a href=\"http:\/\/lucene.apache.org\/\">Lucene<\/a>, <a href=\"http:\/\/tokyocabinet.sourceforge.net\/dystopiadoc\/\">Tokyo Dystopia<\/a>, <a href=\"http:\/\/www.htdig.org\/\">htdig<\/a>, lo que sea, que vaya indexando los contenidos.<\/li>\n<li>Todas las consultas a BD deber\u00edan incluir la clave para conocer a qu\u00e9 <span style=\"font-weight: bold;\">shard<\/span> est\u00e1 tal o cual dato.<\/li>\n<li>Implementa una clase\/script por el que te sea f\u00e1cil mover algo de un <span style=\"font-weight: bold;\">shard<\/span> a otro o subdividir shards.<\/li>\n<li>Testear y monitorizar qu\u00e9 pasa cuando algo se cae, en un entorno monol\u00edtico si se cae todo el mundo se entera porque afecta al 100%, pero si tenemos 4 BD para el Shard i 10 servidores HTTP puedes afectar al 25% de usuarios y pensar que es culpa de Telef\u00f3nica&#8230;<\/li>\n<\/ul>\n<div style=\"text-align: justify;\">Y aqu\u00ed se acaba el post de hoy, que mi fijaci\u00f3n por las embarazadas y ginec\u00f3logos viene por algo (o algo que viene :)) y me requieren.<\/p>\n<p>Saludos!<\/div>\n","protected":false},"excerpt":{"rendered":"<p>En los entornos Web 2.0, tenemos b\u00e1sicamente el modelo de embarazadas, donde cada petici\u00f3n es independiente de las otras. Jugamos con la escala, cada petici\u00f3n HTTP en el fondo la podr\u00edamos tratar en un servidor diferente y si nuestro servidor HTTP tipo responde en 1 segundo, pues nuestro pico m\u00e1ximo de peticiones por segundo ser\u00eda<a href=\"https:\/\/www.xpnti.net\/es\/escalar-la-base-de-datos-sharding\/\">[&#8230;]<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[8,9,10],"tags":[],"_links":{"self":[{"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/posts\/8"}],"collection":[{"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/comments?post=8"}],"version-history":[{"count":1,"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/posts\/8\/revisions"}],"predecessor-version":[{"id":1971,"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/posts\/8\/revisions\/1971"}],"wp:attachment":[{"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/media?parent=8"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/categories?post=8"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.xpnti.net\/es\/wp-json\/wp\/v2\/tags?post=8"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}