{"id":69568,"date":"2020-02-20T15:24:23","date_gmt":"2020-02-20T12:24:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/google-cloud-spanner-horoshij-plohoj-zloj"},"modified":"2020-03-03T16:14:50","modified_gmt":"2020-03-03T13:14:50","slug":"google-cloud-spanner-horoshij-plohoj-zloj","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","title":{"rendered":"Google Cloud Spanner: bueno, malo, feo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Hola, hubronianos. Continuamos compartiendo contenido interesante en la antesala del lanzamiento de nuevos cursos. Hoy, especialmente para ustedes, hemos traducido un art\u00edculo sobre Google Cloud Spanner, coincidiendo con el lanzamiento del curso. <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\">\u00abAWS para desarrolladores\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bueno, malo, feo\" src=\"\/wp-content\/uploads\/2020\/02\/b27b8a09543d10b078480c317553ca46.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Publicado originalmente en <noindex><a rel=\"nofollow\" href=\"https:\/\/www.lightspeedhq.com\/blog\/\">el blog de Lightspeed HQ<\/a><\/noindex>.<\/i><\/p>\n<p>Como empresa que ofrece numerosas soluciones POS en la nube para minoristas, restauradores y vendedores en l\u00ednea en todo el mundo, Lightspeed utiliza varios tipos de plataformas de bases de datos para numerosos casos transaccionales, anal\u00edticos y de b\u00fasqueda. Cada una de estas plataformas de bases de datos tiene sus fortalezas y debilidades. Por lo tanto, cuando Google present\u00f3 Cloud Spanner al mercado, una soluci\u00f3n prometedora con caracter\u00edsticas sin precedentes en el mundo de las bases de datos relacionales, como escalabilidad horizontal pr\u00e1cticamente ilimitada y un SLA del 99.999%, \u00a1no pudimos dejar pasar la oportunidad de tenerla en nuestras manos!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nPara ofrecer una visi\u00f3n completa de nuestra experiencia con Cloud Spanner, as\u00ed como de los criterios de evaluaci\u00f3n que utilizamos, abordaremos los siguientes temas:<\/p>\n<ol>\n<li>Nuestros criterios de evaluaci\u00f3n<\/li>\n<li>Cloud Spanner en pocas palabras<\/li>\n<li>Nuestra evaluaci\u00f3n<\/li>\n<li>Nuestras conclusiones<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Google Cloud Spanner: bueno, malo, feo\" src=\"\/wp-content\/uploads\/2020\/02\/29ed599362fb189283faa9215c18297a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>1. Nuestros criterios de evaluaci\u00f3n<\/h2>\n<p>\nAntes de profundizar en las caracter\u00edsticas de Cloud Spanner, sus similitudes y diferencias con otras soluciones en el mercado, primero hablemos sobre los principales casos de uso que consideramos al analizar d\u00f3nde desplegar Cloud Spanner en nuestra infraestructura:<\/p>\n<ul>\n<li>Como sustituto (prevalente) de la soluci\u00f3n tradicional de base de datos SQL<\/li>\n<li>Como soluci\u00f3n OLTP con soporte para OLAP<\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><i><b>Nota:<\/b> Para facilitar la comparaci\u00f3n, este art\u00edculo compara Cloud Spanner con las variantes de MySQL de las familias de soluciones GCP Cloud SQL y Amazon AWS RDS.<\/i><\/p><\/blockquote>\n<p><\/p>\n<h4>Uso de Cloud Spanner como sustituto de una soluci\u00f3n tradicional de base de datos SQL<\/h4>\n<p>\nEn un entorno <i>de bases de datos <\/i>tradicionales, cuando el tiempo de respuesta a las consultas de la base de datos se acerca o incluso supera los umbrales predefinidos de la aplicaci\u00f3n (principalmente debido al aumento del n\u00famero de usuarios y\/o consultas), existen varias formas de reducir el tiempo de respuesta a niveles aceptables. Sin embargo, la mayor\u00eda de estas soluciones implican intervenci\u00f3n manual.<\/p>\n<p>Por ejemplo, el primer paso que hay que tomar es revisar los diferentes par\u00e1metros de la base de datos relacionados con el rendimiento y ajustarlos para que se adapten mejor a los patrones de uso de las aplicaciones. Si esto no es suficiente, se puede optar por escalar la base de datos de forma vertical u horizontal.<\/p>\n<p>La escalabilidad vertical de la aplicaci\u00f3n implica actualizar la instancia del servidor, generalmente agregando m\u00e1s procesadores\/n\u00facleos, mayor memoria RAM, almacenamiento m\u00e1s r\u00e1pido, etc. Agregar m\u00e1s recursos de hardware conduce a un aumento en el rendimiento de la base de datos, medido principalmente en transacciones por segundo y en la latencia de transacciones para sistemas OLTP. Los sistemas de bases de datos relacionales (que utilizan un enfoque multihilo), como MySQL, escalan bien de forma vertical.<\/p>\n<p>Este enfoque tiene varias desventajas, siendo la m\u00e1s obvia el tama\u00f1o m\u00e1ximo del servidor en el mercado. Una vez que se alcanza el l\u00edmite de la instancia m\u00e1s grande del servidor, solo queda una opci\u00f3n: la escalabilidad horizontal.<\/p>\n<p>La escalabilidad horizontal es un enfoque en el que se agregan m\u00e1s servidores al cl\u00faster, idealmente aumentando linealmente el rendimiento con la adici\u00f3n de m\u00e1s servidores. La mayor\u00eda <i>de bases de datos <\/i>de los sistemas de bases de datos escalan mal de forma horizontal o no escalan en absoluto. Por ejemplo, MySQL puede escalar horizontalmente para operaciones de lectura, agregando lectores esclavos, pero no puede escalar horizontalmente para operaciones de escritura.<\/p>\n<p>Por otro lado, debido a su naturaleza, Cloud Spanner puede escalar horizontalmente con facilidad y m\u00ednima intervenci\u00f3n.<\/p>\n<p>Base de datos completamente funcional<i> DBaaS<\/i> debe evaluarse desde diferentes perspectivas. Como base, tomamos la base de datos en la nube m\u00e1s popular: para Google, GCP Cloud SQL y para Amazon, AWS RDS. En nuestra evaluaci\u00f3n, nos centramos en las siguientes categor\u00edas:<\/p>\n<ul>\n<li>Comparaci\u00f3n de caracter\u00edsticas: extensi\u00f3n SQL, DDL, DML; bibliotecas de conexi\u00f3n\/conectores, soporte para transacciones, etc.<\/li>\n<li>Soporte para desarrollo: facilidad de desarrollo y prueba.<\/li>\n<li>Soporte de administraci\u00f3n: gesti\u00f3n de instancias, como escalado hacia arriba\/abajo y actualizaci\u00f3n de instancias; SLA, copias de seguridad y recuperaci\u00f3n; seguridad\/control de acceso.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Uso de Cloud Spanner como soluci\u00f3n OLTP con soporte OLAP<\/h4>\n<p>\nAunque Google no afirma expl\u00edcitamente que Cloud Spanner est\u00e9 dise\u00f1ado para procesamiento anal\u00edtico, comparte algunos atributos con otros mecanismos como Apache Impala &amp; Kudu y YugaByte, que est\u00e1n destinados a cargas de trabajo OLAP.<\/p>\n<p>Incluso si hubiera solo una peque\u00f1a probabilidad de que Cloud Spanner incluyera un motor escalable horizontalmente coherente HTAP (procesamiento transaccional\/anal\u00edtico h\u00edbrido) con un conjunto de funciones OLAP (m\u00e1s o menos) utilizables, creemos que eso merecer\u00eda nuestra atenci\u00f3n.<\/p>\n<p>Teniendo esto en cuenta, hemos revisado las siguientes categor\u00edas:<\/p>\n<ul>\n<li>Carga de datos, \u00edndices y soporte de particionamiento<\/li>\n<li>Rendimiento de consultas y DML<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Cloud Spanner en pocas palabras<\/h2>\n<p>\nGoogle Spanner es un sistema de gesti\u00f3n de bases de datos relacionales (RDBMS) en cl\u00faster que Google utiliza para varios de sus propios servicios. Google lo hizo accesible para los usuarios de Google Cloud Platform a principios de 2017.<\/p>\n<p>Aqu\u00ed hay algunos de los atributos de Cloud Spanner:<\/p>\n<ul>\n<li>Cl\u00faster RDBMS escalable altamente coherente: utiliza sincronizaci\u00f3n de hardware para garantizar la coherencia de los datos.<\/li>\n<li>Soporte para transacciones intertablas: las transacciones pueden abarcar varias tablas, no limit\u00e1ndose a una sola tabla (a diferencia de Apache HBase o Apache Kudu).<\/li>\n<li>Tablas basadas en clave primaria: todas las tablas deben tener una clave primaria (PK) declarada, que puede estar compuesta por varias columnas de la tabla. Los datos tabulares se almacenan en orden PK, lo que los hace muy eficientes y r\u00e1pidos para la b\u00fasqueda por PK. Al igual que otros sistemas basados en PK, la implementaci\u00f3n debe modelarse teniendo en cuenta los casos de uso previamente planificados para lograr <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/docs\/schema-and-data-model\">el mejor rendimiento.<\/a><\/noindex>.<\/li>\n<li>Tablas alternadas: las tablas pueden tener dependencias f\u00edsicas entre s\u00ed. Las filas de la tabla hija pueden estar relacionadas con las filas de la tabla padre. Este enfoque acelera la b\u00fasqueda de relaciones que pueden definirse en la etapa de modelado de datos, por ejemplo, al agrupar clientes y sus facturas.<\/li>\n<li>\u00cdndices: Cloud Spanner soporta \u00edndices secundarios. Un \u00edndice consiste en columnas indexadas y todas las columnas de la clave primaria. Si se desea, el \u00edndice tambi\u00e9n puede contener otras columnas no indexadas. Un \u00edndice puede superponerse a la tabla padre para acelerar las consultas. Se aplican varias restricciones a los \u00edndices, como el n\u00famero m\u00e1ximo de columnas adicionales que se pueden almacenar en el \u00edndice. Adem\u00e1s, las consultas a trav\u00e9s de \u00edndices pueden no ser tan directas como en otros DBMS.<\/li>\n<\/ul>\n<p>\n<i>\u00abCloud Spanner elige el \u00edndice autom\u00e1ticamente solo en raras ocasiones. En particular, Cloud Spanner no selecciona un \u00edndice secundario autom\u00e1ticamente si la consulta solicita columnas que no se almacenan en <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/docs\/secondary-indexes\">el \u00edndice. <\/a><\/noindex>\u00bb.<\/i><\/p>\n<ul>\n<li>Acuerdo de nivel de servicio (SLA): despliegue en una regi\u00f3n con SLA del 99,99%; despliegues multirregionales con SLA del 99,999%. Aunque el propio acuerdo de nivel de servicio es solo un acuerdo, y no ninguna garant\u00eda, creo que los empleados de Google tienen datos precisos para hacer una afirmaci\u00f3n tan seria. (Para referencia, el 99,999% significa 26,3 segundos de indisponibilidad del servicio al mes.)<\/li>\n<li>M\u00e1s: <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/\">https:\/\/cloud.google.com\/spanner\/<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><i><b>Nota:<\/b> El proyecto Apache Tephra a\u00f1ade soporte ampliado para transacciones en Apache HBase (tambi\u00e9n ahora implementado en Apache Phoenix como versi\u00f3n beta).<\/i><\/p><\/blockquote>\n<p><\/p>\n<h2>3. Nuestra evaluaci\u00f3n<\/h2>\n<p>\nAs\u00ed que todos hemos le\u00eddo las declaraciones de Google sobre las ventajas de Cloud Spanner: escalabilidad horizontal pr\u00e1cticamente ilimitada manteniendo alta consistencia y un SLA muy alto. Aunque estos requisitos son extremadamente dif\u00edciles de alcanzar, nuestro objetivo no era refutarlos. En su lugar, centr\u00e9monos en otras cosas que preocupan a la mayor\u00eda de los usuarios de bases de datos: la equidad y la facilidad de uso.<\/p>\n<h4>Hemos evaluado Cloud Spanner como un reemplazo de Sharded MySQL.<\/h4>\n<p>\nGoogle Cloud SQL y Amazon AWS RDS, las dos bases de datos OLTP m\u00e1s populares en el mercado de la nube, cuentan con un conjunto de funciones muy amplio. Sin embargo, para escalar estas bases de datos m\u00e1s all\u00e1 del tama\u00f1o de un solo nodo, es necesario realizar la fragmentaci\u00f3n de aplicaciones. Este enfoque a\u00f1ade complejidad tanto a las aplicaciones como a la administraci\u00f3n. Hemos examinado c\u00f3mo Spanner se integra en el escenario de combinar m\u00faltiples segmentos en una sola instancia y qu\u00e9 funciones (si las hay) podr\u00edan tener que sacrificarse.<\/p>\n<h4>\u00bfSoporte para SQL, DML y DDL, as\u00ed como conector y bibliotecas?<\/h4>\n<p>\nPrimero, al iniciar con cualquier base de datos, es necesario crear un modelo de datos. Si piensas que puedes conectar JDBC Spanner a tu herramienta SQL favorita, descubrir\u00e1s que puedes consultar tus datos con ella, pero no puedes usarla para crear tablas o realizar cambios (DDL) o cualquier operaci\u00f3n de inserci\u00f3n\/actualizaci\u00f3n\/eliminaci\u00f3n (DML). El JDBC oficial de Google no admite ninguno de los dos.<\/p>\n<blockquote><p><i>\u00abActualmente, los controladores no admiten operadores DML o DDL\u00bb.<\/i><br \/>\nDocumentaci\u00f3n de Spanner<\/p><\/blockquote>\n<p>\nLa situaci\u00f3n con la consola de GCP no es mejor: solo puedes enviar consultas SELECT. Afortunadamente, hay un controlador JDBC con soporte para DML y DDL de la comunidad, que incluye transacciones <noindex><a rel=\"nofollow\" href=\"http:\/\/github.com\/olavloite\/spanner-jdbc\">github.com\/olavloite\/spanner-jdbc<\/a><\/noindex>. Aunque este controlador es extremadamente \u00fatil, la falta de un controlador JDBC propio de Google es sorprendente. Afortunadamente, Google ofrece un soporte bastante amplio para bibliotecas de clientes (basadas en gRPC): C#, Go, Java, node.js, PHP, Python y Ruby.<\/p>\n<p>La obligaci\u00f3n casi inevitable de usar APIs personalizadas de Cloud Spanner (debido a la falta de DDL y DML en JDBC) lleva a algunas limitaciones para las \u00e1reas de c\u00f3digo relacionadas, como grupos de conexiones o marcos de vinculaci\u00f3n de bases de datos (por ejemplo, Spring MVC). En general, al usar JDBC puedes elegir libremente tu grupo de conexiones favorito (por ejemplo, HikariCP, DBCP, C3PO, etc.), que ha sido probado y funciona bien. En el caso de las APIs personalizadas de Spanner, debemos confiar en los marcos\/grupos de vinculaci\u00f3n\/sesiones que hemos creado nosotros mismos.<\/p>\n<p>La construcci\u00f3n orientada a la clave primaria (PK) permite a Cloud Spanner ser muy r\u00e1pido al acceder a los datos a trav\u00e9s de la PK, pero tambi\u00e9n provoca algunos problemas con las consultas.<\/p>\n<ul>\n<li>No puede actualizar el valor de la clave principal; primero debe eliminar el registro con la clave principal original y volver a insertarlo con el nuevo valor. (Esto es similar a otras bases de datos \/ mecanismos de almacenamiento orientados a claves).<\/li>\n<li>Cualquier operador UPDATE y DELETE debe especificar la clave principal en WHERE, por lo tanto, no puede haber operadores DELETE vac\u00edos; siempre debe haber una subconsulta, por ejemplo: UPDATE xxx WHERE id IN (SELECT id FROM table1)<\/li>\n<li>Falta la opci\u00f3n de autoincremento o algo similar que establezca una secuencia para el campo de clave principal. Para que esto funcione, el valor correspondiente debe ser creado del lado de la aplicaci\u00f3n.<\/li>\n<\/ul>\n<p><\/p>\n<h4>\u00bf\u00cdndices secundarios?<\/h4>\n<p>\nGoogle Cloud Spanner tiene soporte integrado para \u00edndices secundarios. Esta es una caracter\u00edstica muy agradable que no siempre est\u00e1 presente en otras tecnolog\u00edas. Apache Kudu actualmente no admite \u00edndices secundarios en absoluto, y Apache HBase no soporta \u00edndices directamente, pero puede agregarles a trav\u00e9s de Apache Phoenix.<\/p>\n<p>Los \u00edndices en Kudu y HBase se pueden modelar como una tabla separada con diferentes combinaciones de claves primarias, pero la atomicidad de las operaciones realizadas con la tabla principal y las tablas de \u00edndices relacionadas debe cumplirse a nivel de aplicaci\u00f3n y no es trivial en una implementaci\u00f3n correcta.<\/p>\n<p>Como se mencion\u00f3 en la revisi\u00f3n de Cloud Spanner, sus \u00edndices pueden diferir de los \u00edndices MySQL. Por lo tanto, se debe tener especial cuidado al construir consultas y perfiles para garantizar que se utilice el \u00edndice adecuado donde sea necesario.<\/p>\n<h4>\u00bfVistas?<\/h4>\n<p>\nUn objeto muy popular y \u00fatil en la base de datos son las vistas. Pueden ser \u00fatiles para una gran cantidad de casos de uso; mis dos favoritos son el nivel de abstracci\u00f3n l\u00f3gica y el nivel de seguridad. Desafortunadamente, Cloud Spanner NO admite vistas. Sin embargo, esto solo nos limita parcialmente, ya que para los permisos de acceso no hay detalles a nivel de columna, donde las vistas pueden ser una soluci\u00f3n aceptable.<\/p>\n<p>En la documentaci\u00f3n de Cloud Spanner, en la secci\u00f3n que detalla las cuotas y limitaciones (<noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/quotas\">spanner\/quotas<\/a><\/noindex>), hay una en particular que puede ser problem\u00e1tica para algunas aplicaciones: Cloud Spanner tiene un l\u00edmite predeterminado de un m\u00e1ximo de 100 bases de datos por instancia. Obviamente, esto puede ser un gran obst\u00e1culo para una base de datos que est\u00e1 dise\u00f1ada para escalar a m\u00e1s de 100 bases de datos. Afortunadamente, despu\u00e9s de hablar con nuestro representante t\u00e9cnico de Google, descubrimos que este l\u00edmite puede aumentarse pr\u00e1cticamente a cualquier valor a trav\u00e9s del servicio de atenci\u00f3n al cliente de Google.<\/p>\n<h4>\u00bfSoporte para el desarrollo?<\/h4>\n<p>\nCloud Spanner ofrece un soporte bastante decente para lenguajes de programaci\u00f3n que trabajan con su API. Las bibliotecas oficialmente soportadas est\u00e1n en C#, Go, Java, node.js, PHP, Python y Ruby. La documentaci\u00f3n es bastante detallada, pero, como ocurre con otras tecnolog\u00edas de vanguardia, la comunidad es bastante peque\u00f1a en comparaci\u00f3n con las tecnolog\u00edas de bases de datos m\u00e1s populares, lo que puede llevar a un aumento en el tiempo dedicado a resolver casos de uso o problemas menos comunes.<\/p>\n<h4>\u00bfY qu\u00e9 hay del soporte para el desarrollo local?<\/h4>\n<p>\nNo encontramos una manera de crear una instancia de Cloud Spanner en un entorno local. Lo m\u00e1s cercano que conseguimos fue una imagen de Docker. <noindex><a rel=\"nofollow\" href=\"https:\/\/hub.docker.com\/r\/cockroachdb\/cockroach\">CockroachDB<\/a><\/noindex>, que en principio se parece, pero en la pr\u00e1ctica es bastante diferente. Por ejemplo, CockroachDB puede usar PostgreSQL JDBC. Dado que el entorno de desarrollo debe ser lo m\u00e1s parecido posible al entorno de producci\u00f3n, Cloud Spanner no es ideal, ya que se debe depender de una instancia completa de Spanner. Para economizar costos, puede elegir una instancia de una sola regi\u00f3n.<\/p>\n<h4>\u00bfSoporte de administraci\u00f3n?<\/h4>\n<p>\nCrear una instancia de Cloud Spanner es muy simple. Solo necesitas elegir entre crear una instancia multirregional o de una sola regi\u00f3n, especificar la(s) regi\u00f3n(es) y el n\u00famero de nodos. En menos de un minuto, la instancia estar\u00e1 en funcionamiento y lista para usar.<\/p>\n<p>Varias m\u00e9tricas b\u00e1sicas est\u00e1n disponibles directamente en la p\u00e1gina de Spanner en la consola de Google. Vistas m\u00e1s detalladas est\u00e1n disponibles a trav\u00e9s de Stackdriver, donde tambi\u00e9n puedes establecer umbrales para las m\u00e9tricas y pol\u00edticas de alertas.<\/p>\n<h4>\u00bfAcceso a los recursos?<\/h4>\n<p>\nMySQL ofrece configuraciones de permisos\/roles de usuario amplias y muy detalladas. Es f\u00e1cil configurar el acceso a una tabla espec\u00edfica o incluso a solo un subconjunto de sus columnas. Cloud Spanner utiliza la herramienta de Google Identity &amp; Access Management (IAM), que permite establecer pol\u00edticas y permisos solo a un nivel muy alto. La opci\u00f3n m\u00e1s detallada es el permiso a nivel de base de datos, que no se adapta a la mayor\u00eda de los casos de producci\u00f3n. Esta limitaci\u00f3n te obliga a a\u00f1adir medidas de seguridad adicionales en tu c\u00f3digo, infraestructura o ambos para prevenir el uso no autorizado de los recursos de Spanner.<\/p>\n<h4>\u00bfCopias de seguridad?<\/h4>\n<p>\nHablando en t\u00e9rminos simples, no existen copias de seguridad en Cloud Spanner. Si bien los altos requisitos de SLA de Google pueden garantizar que no pierdas datos debido a fallos de hardware o de la base de datos, no protegen contra errores humanos, defectos de aplicaciones, etc. Todos conocemos la regla: alta disponibilidad no reemplaza una estrategia de copia de seguridad razonable. Hasta ahora, la \u00fanica forma de realizar copias de seguridad de datos es mediante la transmisi\u00f3n program\u00e1tica de estos desde la base de datos a un entorno de almacenamiento separado.<\/p>\n<h4>\u00bfRendimiento de consultas?<\/h4>\n<p>\nPara cargar datos y probar consultas utilizamos el Yahoo! Cloud Serving Benchmark. En la tabla a continuaci\u00f3n se presenta la carga de trabajo B YCSB con una relaci\u00f3n de lectura del 95% y de escritura del 5%.<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bueno, malo, feo\" src=\"\/wp-content\/uploads\/2020\/02\/8fca14875af33c8ed3cd04b602c52b78.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>* La prueba de carga se realiz\u00f3 en un motor computacional (CE) n1-standard-32 (32 vCPU, 120 GB de memoria), y el instancia de prueba nunca fue un cuello de botella en las pruebas.<\/i><br \/>\n<i>** El n\u00famero m\u00e1ximo de hilos en una instancia YCSB es de 400. En total, se necesitaron ejecutar seis instancias paralelas de pruebas YCSB para alcanzar un total de 2400 hilos.<\/i><\/p>\n<p>Al observar los resultados de las pruebas, en particular la combinaci\u00f3n de carga del procesador y TPS, vemos claramente que Cloud Spanner se escala bastante bien. La alta carga generada por una gran cantidad de hilos es compensada por un mayor n\u00famero de nodos en el cl\u00faster de Cloud Spanner. Aunque la latencia parece bastante alta, especialmente al trabajar con 2400 hilos, puede ser necesario volver a realizar pruebas con 6 instancias m\u00e1s peque\u00f1as del motor de c\u00f3mputo para obtener cifras m\u00e1s precisas. Cada instancia ejecutar\u00e1 una prueba YCSB en lugar de una gran instancia CE con 6 pruebas paralelas. De esta manera, ser\u00e1 m\u00e1s f\u00e1cil distinguir entre las latencias de las consultas de Cloud Spanner y las latencias a\u00f1adidas por la conexi\u00f3n de red entre Cloud Spanner y la instancia CE donde se realizan las pruebas.<\/p>\n<h3>\u00bfC\u00f3mo se desempe\u00f1a Cloud Spanner como OLAP?<\/h3>\n<p><\/p>\n<h4>\u00bfParticionamiento?<\/h4>\n<p>\nDividir datos en segmentos f\u00edsicamente y\/o l\u00f3gicamente independientes, llamados particiones, es un concepto muy popular en la mayor\u00eda de los mecanismos OLAP. Las particiones pueden mejorar significativamente el rendimiento de las consultas y la mantenibilidad de la base de datos. Profundizar en las particiones ser\u00eda tema de un art\u00edculo (art\u00edculos) separado, as\u00ed que simplemente mencionemos la importancia de tener un esquema de particionamiento y subtipo de particionamiento. La capacidad de dividir los datos en particiones y a\u00fan m\u00e1s en subparticiones es clave para el rendimiento de las consultas anal\u00edticas.<\/p>\n<p>Cloud Spanner no admite particiones como tales. Divide los datos internamente en lo que se llama <i>split<\/i>-s basados en rangos de claves primarias. La divisi\u00f3n se realiza autom\u00e1ticamente para equilibrar la carga en el cl\u00faster de Cloud Spanner. Una funci\u00f3n muy conveniente de Cloud Spanner es la divisi\u00f3n de la carga base de la tabla principal (la tabla que no se alterna con otra). Spanner determina autom\u00e1ticamente si contiene <i>split <\/i>datos que se leen m\u00e1s a menudo que los datos en otras <i>split<\/i>-s, y puede tomar una decisi\u00f3n sobre una separaci\u00f3n adicional. As\u00ed, pueden estar involucrados m\u00e1s nodos en la consulta, lo que tambi\u00e9n aumenta eficazmente el rendimiento.<\/p>\n<h4>\u00bfCarga de datos?<\/h4>\n<p>\nEl m\u00e9todo Cloud Spanner para grandes vol\u00famenes de datos es el mismo que en una carga convencional. Para lograr el m\u00e1ximo rendimiento, debe seguir algunas recomendaciones, que incluyen:<\/p>\n<ul>\n<li>Ordene sus datos por la clave primaria.<\/li>\n<li>Div\u00eddalos en 10*<i>nodos<\/i> secciones separadas.<\/li>\n<li>Cree un conjunto de tareas que carguen datos en paralelo.<\/li>\n<\/ul>\n<p>\nEn esta carga de datos se utilizan todos los nodos de Cloud Spanner.<\/p>\n<p>Utilizamos la carga de trabajo A YCSB para generar un conjunto de datos de 10M de filas.<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bueno, malo, feo\" src=\"\/wp-content\/uploads\/2020\/02\/89b9c0353716be2d389b3e8da82781ad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>* La prueba de carga se realiz\u00f3 en el motor de computaci\u00f3n n1-standard-32 (32 vCPU, 120 GB de RAM), y la instancia de prueba nunca fue un cuello de botella en las pruebas.<br \/>\n** La configuraci\u00f3n de 1 nodo no se recomienda para ninguna carga de producci\u00f3n.<\/i><\/p>\n<p>Como se mencion\u00f3 anteriormente, Cloud Spanner maneja autom\u00e1ticamente los splits seg\u00fan su carga, por lo que los resultados mejoran despu\u00e9s de varias repeticiones consecutivas de la prueba. Los resultados presentados aqu\u00ed son los mejores que hemos obtenido. Al observar los n\u00fameros anteriores, podemos ver c\u00f3mo Cloud Spanner se escala (bien) con el aumento del n\u00famero de nodos en el cl\u00faster. Los n\u00fameros destacados representan latencias promedio incre\u00edblemente bajas que contrastan con los resultados de cargas de trabajo mixtas (95% de lectura y 5% de escritura), como se describe en la secci\u00f3n anterior.<\/p>\n<h4>\u00bfEscalabilidad?<\/h4>\n<p>\nAumentar y reducir el n\u00famero de nodos en Cloud Spanner es una tarea que se realiza con un solo clic. Si desea cargar datos r\u00e1pidamente, puede considerar aumentar la instancia al m\u00e1ximo (en nuestro caso, fueron 25 nodos en la regi\u00f3n US-EAST), y luego reducir el n\u00famero de nodos adecuado para su carga habitual, una vez que todos los datos est\u00e9n en la base de datos, teniendo en cuenta el l\u00edmite de 2 TB\/nodo.<\/p>\n<p>Nos recordaron este l\u00edmite incluso con una base de datos mucho m\u00e1s peque\u00f1a. Despu\u00e9s de varias ejecuciones de pruebas de carga, nuestra base de datos ten\u00eda un tama\u00f1o de alrededor de 155 GB, y al reducir a una instancia de 1 nodo, recibimos el siguiente error:<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bueno, malo, feo\" src=\"\/wp-content\/uploads\/2020\/02\/4a46c97e7943b5105bf178316dc67433.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPudimos reducir la escala de 25 a 2 instancias, pero nos quedamos atascados en dos nodos.<\/p>\n<p>La expansi\u00f3n y contracci\u00f3n del n\u00famero de nodos en un cl\u00faster de Cloud Spanner se puede automatizar mediante la API REST. Esto puede ser especialmente \u00fatil para reducir la carga del sistema durante las horas pico.<\/p>\n<h4>\u00bfRendimiento de consultas OLAP?<\/h4>\n<p>\nInicialmente, plane\u00e1bamos dedicar un tiempo considerable a nuestra evaluaci\u00f3n de Spanner en esta parte. Despu\u00e9s de varias selecciones COUNT, nos dimos cuenta de inmediato que la prueba ser\u00eda breve y que Spanner NO ser\u00eda adecuado como motor OLAP. Independientemente del n\u00famero de nodos en el cl\u00faster, la simple selecci\u00f3n del n\u00famero de filas en una tabla de 10 millones de filas tard\u00f3 entre 55 y 60 segundos. Adem\u00e1s, cualquier consulta que requiriese m\u00e1s memoria para almacenar resultados intermedios termin\u00f3 con un error OOM.<\/p>\n<p><code>SELECT COUNT(DISTINCT(field0)) FROM usertable; \u2014 (10M valores distintos) -&gt; SpoolingHashAggregateIterator se qued\u00f3 sin memoria durante la nueva fila.<\/code><\/p>\n<p>Algunos n\u00fameros para las consultas TPC-H se pueden encontrar en el art\u00edculo de Todd Lipcon <noindex><a rel=\"nofollow\" href=\"https:\/\/kudu.apache.org\/2017\/10\/23\/nosql-kudu-spanner-slides.html\">Nosql-kudu-spanner-slides.html<\/a><\/noindex>, diapositivas 42 y 43. Estos n\u00fameros son consistentes con nuestros propios resultados (lamentablemente).<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bueno, malo, feo\" src=\"\/wp-content\/uploads\/2020\/02\/d070c839bbc62b1ba1bebbaf64127e93.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>4. Nuestras conclusiones<\/h4>\n<p>\nDado el estado actual de las funciones de Cloud Spanner, es dif\u00edcil imaginarlo como un simple reemplazo de soluciones OLTP existentes, especialmente cuando sus necesidades superen sus capacidades. Ser\u00eda necesario dedicar una cantidad significativa de tiempo para construir una soluci\u00f3n que tenga en cuenta las deficiencias de Cloud Spanner.<\/p>\n<p>Cuando comenzamos a evaluar Cloud Spanner, esper\u00e1bamos que sus caracter\u00edsticas de gesti\u00f3n estar\u00edan a la par o, al menos, no tan lejos de otras soluciones de Google SQL. Pero nos sorprendi\u00f3 la completa ausencia de copias de seguridad y el control de acceso muy limitado a los recursos. Sin mencionar la falta de vistas, la ausencia de un entorno de desarrollo local, secuencias no soportadas, JDBC sin soporte para DML y DDL, y as\u00ed sucesivamente.<\/p>\n<p>Entonces, \u00bfa d\u00f3nde debe acudir alguien que necesita escalar una base de datos transaccional? Parece que en el mercado a\u00fan no hay una soluci\u00f3n \u00fanica que se adapte a todos los casos de uso. Existen numerosas soluciones de c\u00f3digo cerrado y abierto (algunas de las cuales se mencionan en este art\u00edculo), cada una con sus fortalezas y debilidades, pero ninguna de ellas ofrece SaaS con SLA del 99,999% y un alto nivel de consistencia. Si un alto nivel de SLA es su principal objetivo y no tiene intenci\u00f3n de crear su propia soluci\u00f3n para m\u00faltiples entornos en la nube, Cloud Spanner podr\u00eda ser la soluci\u00f3n que est\u00e1 buscando. Pero debe conocer todas sus limitaciones.<\/p>\n<p>A modo de justicia, cabe mencionar que Cloud Spanner fue lanzado al p\u00fablico \u00fanicamente en la primavera de 2017, por lo que es razonable esperar que algunas de sus deficiencias actuales eventualmente desaparezcan (esperemos), y cuando eso ocurra, podr\u00eda cambiar las reglas del juego. Despu\u00e9s de todo, Cloud Spanner no es solo un proyecto externo para Google. Google lo utiliza como base para otros productos de Google. Y cuando Google recientemente reemplaz\u00f3 Megastore en Google Cloud Storage por Cloud Spanner, esto permiti\u00f3 que Google Cloud Storage se volviera estrictamente coherente para listas de objetos a nivel mundial (lo cual a\u00fan no se aplica a <noindex><a rel=\"nofollow\" href=\"https:\/\/cloudplatform.googleblog.com\/2018\/02\/how-Google-Cloud-Storage-offers-strongly-consistent-object-listing-thanks-to-Spanner.html\">Amazon<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/cloudplatform.googleblog.com\/2018\/02\/how-Google-Cloud-Storage-offers-strongly-consistent-object-listing-thanks-to-Spanner.html\">S3<\/a><\/noindex>).<\/p>\n<p>As\u00ed que a\u00fan hay esperanza... seguimos optimistas.<\/p>\n<p>Eso es todo. Al igual que el autor del art\u00edculo, tambi\u00e9n seguimos teniendo esperanzas, \u00bfqu\u00e9 opinas t\u00fa al respecto? Escr\u00edbenos en los comentarios.<\/p>\n<p><b>Invitamos a todos a asistir a nuestro <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\">un webinar gratuito<\/a><\/noindex> donde explicaremos en detalle sobre el curso<noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\"> \u00abAWS para desarrolladores\u00bb<\/a><\/noindex> de OTUS.<\/b><br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/489012\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u0434\u043b\u044f \u0432\u0430\u0441 \u043c\u044b \u043f\u0440\u0435\u0432\u0435\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u043e Google Cloud Spanner, \u043f\u0440\u0438\u0443\u0440\u043e\u0447\u0438\u0432 \u0435\u0435 \u043a \u0437\u0430\u043f\u0443\u0441\u043a\u0443 \u043a\u0443\u0440\u0441\u0430 \u00abAWS \u0434\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432\u00bb. \u041f\u0435\u0440\u0432\u043e\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u043e \u0432 \u0431\u043b\u043e\u0433\u0435 Lightspeed HQ. \u041a\u0430\u043a \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0445 POS-\u0440\u0435\u0448\u0435\u043d\u0438\u0439 \u0434\u043b\u044f \u0440\u043e\u0437\u043d\u0438\u0447\u043d\u044b\u0445 \u0442\u043e\u0440\u0433\u043e\u0432\u0446\u0435\u0432, \u0440\u0435\u0441\u0442\u043e\u0440\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u0440\u043e\u0434\u0430\u0432\u0446\u043e\u0432 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, Lightspeed \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":69569,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-69568","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Google Cloud Spanner: \u0445\u043e\u0440\u043e\u0448\u0438\u0439, \u043f\u043b\u043e\u0445\u043e\u0439, \u0437\u043b\u043e\u0439 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-20T12:24:23+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-03T13:14:50+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Google Cloud Spanner: bueno, malo, feo | ProHoster","description":"Hola, habitantes de Habr. Tradicionalmente, continuamos compartiendo contenido interesante antes del inicio de nuevos cursos.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Google Cloud Spanner: \u0445\u043e\u0440\u043e\u0448\u0438\u0439, \u043f\u043b\u043e\u0445\u043e\u0439, \u0437\u043b\u043e\u0439 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-20T12:24:23+00:00","article:modified_time":"2020-03-03T13:14:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"69568","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:20:25","updated":"2022-09-30 15:10:07","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/69568","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=69568"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/69568\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/69569"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=69568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=69568"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=69568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}