{"id":1774,"date":"2014-12-16T18:33:46","date_gmt":"2014-12-16T18:33:46","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=1774"},"modified":"2017-05-03T11:53:29","modified_gmt":"2017-05-03T18:53:29","slug":"scaling-data-los-angeles-cloudcamp","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/scaling-data-los-angeles-cloudcamp\/","title":{"rendered":"escalado de datos en el CloudCamp de Los \u00c1ngeles"},"content":{"rendered":"

Hace poco m\u00e1s de una semana, pero me lo pas\u00e9 bien y aprend\u00ed algunas cosas tanto de la sesi\u00f3n como de los debates en el CloudCamp de Los \u00c1ngeles. Propuse, y finalmente dirig\u00ed, una sesi\u00f3n sobre escalado de datos. En realidad, la propuse como \"Scaling Your Data: Tanto antes como despu\u00e9s de necesitarlos\".<\/p>\n

Parte de la raz\u00f3n por la que lo propuse es que hubo una discusi\u00f3n sobre el teorema CAP durante la propuesta de sesiones, y lo que se dijo estaba un poco fuera de lugar. CAP se discute bien en muchos sitios, (un buen blog es de Jonathan Gray, CTO y cofundador de Streamy<\/a>. CAP son las siglas de Consistencia, Disponibilidad y tolerancia a<\/span> Partici\u00f3n de red. Curiosamente, mucha gente sigui\u00f3 intentando hacer de la \u00faltima P rendimiento o introducir rendimiento en la mezcla. El rendimiento (o al menos las ventajas y desventajas que conlleva) se tratan mejor en otro conjunto de letras W+R>N. En las instalaciones de Microsoft en el centro de Los \u00c1ngeles hab\u00eda una sala dedicada principalmente al escalado de datos. La primera sesi\u00f3n corri\u00f3 a cargo de .... y trat\u00f3 sobre el teorema CAP. Al principio fue un poco pol\u00e9mico, ya que hab\u00eda algunas afirmaciones de que se pod\u00edan obtener los tres con un uso juicioso de la tecnolog\u00eda de Microsoft, pero a trav\u00e9s de la discusi\u00f3n en la sala terminamos en el lugar correcto y de acuerdo unos con otros. La sesi\u00f3n fue dirigida por Abhijit Gadkari, de ZimbaTech. A continuaci\u00f3n, el propio SoCalDevGal<\/a> (Lynn Langit) hizo una presentaci\u00f3n sobre SQL Azure<\/a>. Desde luego, aprend\u00ed un poco sobre lo que ofrece Microsoft y lo que piden sus desarrolladores. Incluso aprend\u00ed algunos nuevos acr\u00f3nimos de tres letras :) SQL Azure es la base de datos relacional alojada como servicio de Microsoft. De la presentaci\u00f3n, qued\u00f3 claro que inicialmente Microsoft no estaba planeando un almac\u00e9n de datos alojado compatible con SQL (lo que los har\u00eda m\u00e1s como SimpleDB de Amazon o BigTable de Google como se accede a trav\u00e9s de Google App Engine). Al final, los comentarios de los clientes les llevaron a proporcionar todo el SQL posible, incluida la integraci\u00f3n con todas las herramientas para desarrolladores de Microsoft. Curiosamente, Microsoft sugiere la fragmentaci\u00f3n de datos a escala. Esto se debe en parte a que el producto inicial est\u00e1 limitado a bases de datos de 10 GB. SoCalDevGal dej\u00f3 muy claro que se trataba de una limitaci\u00f3n inicial y que hab\u00eda que ceder en algunos aspectos para poder cumplir el calendario. La otra parte realmente interesante sobre SQL Azure, que me pareci\u00f3 pertinente dado el resto de la discusi\u00f3n, fue la aparente decisi\u00f3n de hacer de SQL Azure un sistema CA, en lo que respecta a CAP. Incluso ped\u00ed que se verificara, y esa era de hecho la intenci\u00f3n. La raz\u00f3n por la que esto es tan importante para m\u00ed es que la decisi\u00f3n de dise\u00f1o aqu\u00ed, junto con la replicaci\u00f3n a trav\u00e9s de centros de datos, significa que la \u00fanica manera de hacer esto correctamente es desconectar el sistema (o una parte de su seguridad) en el caso de que un centro de datos se corte de la 'red. Dado que todos los datos est\u00e1n en al menos dos centros de datos, y no se sabe cu\u00e1les, es posible que los centros de datos sean m\u00e1s que \"pares\", lo que significa que una partici\u00f3n completa de un solo centro de datos podr\u00eda significar una interrupci\u00f3n de al menos dos, y tal vez m\u00e1s. Esto es bueno para sus usuarios en el sentido de que es completamente compatible con sus aplicaciones, pero tambi\u00e9n significa que podr\u00eda haber un \"momento CNN\" alg\u00fan d\u00eda, lo que significa que un par de fallos de telco dejar\u00e1n fuera de l\u00ednea a un gran n\u00famero de clientes de SQL Azure. Para que no se malinterprete, esto no es una cr\u00edtica a la tecnolog\u00eda de Microsoft o alguna deficiencia que deber\u00edan haber superado. Simplemente fue una decisi\u00f3n de dise\u00f1o tomada por el equipo de SQL Azure. Aqu\u00ed es donde est\u00e1 la \"ingenier\u00eda\" en nuestra disciplina... hay compensaciones en cualquier dise\u00f1o. La \u00faltima sesi\u00f3n de la tarde en la sala acab\u00f3 siendo la m\u00eda. Hice una r\u00e1pida presentaci\u00f3n de m\u00ed mismo y una r\u00e1pida evaluaci\u00f3n de qui\u00e9n hab\u00eda siquiera mirado en cosas como memcached, gearman, Haoop HBase, Cassandra y similares. Result\u00f3 que casi nadie hab\u00eda pensado en esto. Creo que esto se debe, en parte, a que Microsoft hizo un gran trabajo a la hora de colocar a los asistentes en los asientos para este evento. Debido a la experiencia del p\u00fablico con este tipo de cosas, dirig\u00ed la sesi\u00f3n como un ejercicio un poco cerebral para entender por qu\u00e9<\/em> alguien puede querer buscar diferentes formas de almacenar datos. Estoy seguro de que no lo he cubierto todo, pero he afirmado algunas razones:<\/p>\n