Ola, veciños de Khabrovsk. Hoxe comezan as clases do primeiro grupo do curso . Neste sentido, queremos contarvos como se desenvolveu o webinar aberto sobre este curso.
В falamos dos retos aos que se enfrontan as bases de datos SQL na era das nubes e Kubernetes. Ao mesmo tempo, analizamos como as bases de datos SQL se adaptan e mutan baixo a influencia destes desafíos.
Celebrouse o webinar , Google Cloud Practice Delivery Manager en EPAM Systems.
Cando as árbores eran pequenas...
En primeiro lugar, lembremos como comezou a elección do DBMS a finais do século pasado. Non obstante, isto non será difícil, porque a elección dun DBMS naqueles días comezou e rematou oráculo.
A finais dos 90 e principios dos 2, non había esencialmente opción cando se trataba de bases de datos escalables industriais. Si, había IBM DBXNUMX, Sybase e algunhas outras bases de datos que viñan e saíron, pero en xeral non se notaban tanto no contexto de Oracle. En consecuencia, as habilidades dos enxeñeiros daqueles tempos estaban vinculadas dalgún xeito á única opción que existía.
Oracle DBA tiña que ser capaz de:
- instalar Oracle Server desde o kit de distribución;
- configurar Oracle Server:
- init.ora;
- oínte.ora;
- crear:
- espazos de táboa;
- esquemas;
- usuarios;
- realizar copias de seguridade e restauración;
- realizar un seguimento;
- tratar con solicitudes subóptimas.
Ao mesmo tempo, non había ningún requisito especial de Oracle DBA:
- ser capaz de escoller o DBMS óptimo ou outra tecnoloxía para almacenar e procesar datos;
- proporcionar alta dispoñibilidade e escalabilidade horizontal (non sempre foi un problema de DBA);
- bo coñecemento da área temática, infraestrutura, arquitectura de aplicacións, SO;
- cargar e descargar datos, migrar datos entre diferentes DBMS.
En xeral, se falamos da elección naqueles días, aseméllase á elección nunha tenda soviética a finais dos anos 80:
O noso tempo
Desde entón, por suposto, as árbores creceron, o mundo cambiou e pasou a ser algo así:
O mercado de DBMS tamén cambiou, como se pode ver claramente no último informe de Gartner:
E aquí hai que ter en conta que as nubes, cuxa popularidade está crecendo, ocuparon o seu nicho. Se lemos o mesmo informe de Gartner, veremos as seguintes conclusións:
- Moitos clientes están no camiño de mover aplicacións á nube.
- As novas tecnoloxías aparecen por primeira vez na nube e non é un feito que nunca se trasladen a infraestruturas non cloud.
- O modelo de prezos de pago por uso tornouse habitual. Todo o mundo quere pagar só polo que usa, e iso nin sequera é unha tendencia, senón simplemente unha declaración de feito.
Agora qué?
Hoxe estamos todos na nube. E as preguntas que xorden para nós son cuestións de elección. E é enorme, aínda que só falemos da elección das tecnoloxías DBMS no formato local. Tamén temos servizos xestionados e SaaS. Así, a elección só se fai máis difícil cada ano.
Xunto ás preguntas de elección, tamén as hai factores limitantes:
- prezo. Moitas tecnoloxías aínda custan cartos;
- habilidades. Se estamos a falar de software libre, xorde a cuestión das habilidades, xa que o software libre require competencia suficiente das persoas que o despregan e o operan;
- funcional. Non todos os servizos que están dispoñibles na nube e construídos, por exemplo, mesmo no mesmo Postgres, teñen as mesmas funcións que Postgres On-premises. Este é un factor esencial que hai que coñecer e comprender. Ademais, este factor faise máis importante que o coñecemento dalgunhas capacidades ocultas dun único DBMS.
Que se espera de DA/DE agora:
- boa comprensión da área temática e da arquitectura de aplicacións;
- a capacidade de seleccionar correctamente a tecnoloxía DBMS axeitada, tendo en conta a tarefa a realizar;
- a capacidade de seleccionar o método óptimo para implementar a tecnoloxía seleccionada no contexto das limitacións existentes;
- capacidade para realizar transferencia e migración de datos;
- capacidade para implementar e operar solucións seleccionadas.
Abaixo exemplo baseado en GCP demostra como funciona a elección dunha ou outra tecnoloxía para traballar con datos en función da súa estrutura:
Teña en conta que PostgreSQL non está incluído no esquema, e isto é porque está oculto baixo a terminoloxía Cloud SQL. E cando chegamos a Cloud SQL, necesitamos facer unha elección de novo:
Cómpre sinalar que esta elección non sempre está clara, polo que os desenvolvedores de aplicacións adoitan guiarse pola intuición.
Total:
- Canto máis avanzas, máis apremiante se fai a cuestión da elección. E mesmo se miras só a GCP, os servizos xestionados e SaaS, só aparecerá algunha mención de RDBMS no cuarto paso (e alí está Spanner preto). Ademais, a elección de PostgreSQL aparece no paso 4, e xunto a el tamén hai MySQL e SQL Server, é dicir. hai moito de todo, pero hai que escoller.
- Non debemos esquecer as restricións no fondo das tentacións. Basicamente todo o mundo quere unha chave, pero é caro. Como resultado, unha solicitude típica parece algo así: "Por favor, convértenos en Spanner, pero polo prezo de Cloud SQL, sodes profesionais!"
Que debemos facer?
Sen pretender ser a verdade definitiva, digamos o seguinte:
Necesitamos cambiar o noso enfoque de aprendizaxe:
- non ten sentido ensinar como antes se ensinaban os DBA;
- o coñecemento dun produto xa non é suficiente;
- pero coñecer ducias a nivel dun é imposible.
Debes saber non só e non canto é o produto, senón:
- caso de uso da súa aplicación;
- diferentes métodos de implantación;
- vantaxes e inconvenientes de cada método;
- produtos similares e alternativos para facer unha elección informada e óptima e non sempre a favor dun produto familiar.
Tamén debes poder migrar datos e comprender os principios básicos da integración con ETL.
caso real
No pasado recente, era necesario crear un backend para unha aplicación móbil. Cando comezou a traballar nel, o backend xa estaba desenvolvido e estaba listo para a súa implementación, e o equipo de desenvolvemento pasou uns dous anos neste proxecto. Establecéronse as seguintes tarefas:
- construír CI/CD;
- revisar a arquitectura;
- poñelo todo en funcionamento.
A aplicación en si era microservizos e o código Python/Django desenvolveuse desde cero e directamente en GCP. En canto ao público obxectivo, suponse que habería dúas rexións: Estados Unidos e UE, e o tráfico distribuíase a través do equilibrador de carga global. Todas as cargas de traballo e a carga de traballo informática executáronse en Google Kubernetes Engine.
En canto aos datos, había 3 estruturas:
- Almacenamento na nube;
- Almacén de datos;
- Cloud SQL (PostgreSQL).
Un pode preguntarse por que se escolleu Cloud SQL? A verdade, tal pregunta causou algún tipo de pausa incómoda nos últimos anos: hai a sensación de que a xente se volveu tímida sobre as bases de datos relacionais, pero, con todo, seguen usándoas activamente ;-).
En canto ao noso caso, escolleuse Cloud SQL polos seguintes motivos:
- Como se mencionou, a aplicación foi desenvolvida usando Django, e ten un modelo para mapear datos persistentes dunha base de datos SQL a obxectos Python (Django ORM).
- O propio cadro admitía unha lista bastante finita de DBMS:
- PostgreSQL;
- MariaDB;
- MySQL;
- oráculos;
- SQLite.
En consecuencia, PostgreSQL escolleuse desta lista de forma bastante intuitiva (ben, non é Oracle elixir, realmente).
O que faltaba:
- a aplicación despregouse só en 2 rexións, e apareceu unha terceira en planos (Asia);
- A base de datos estaba situada na rexión norteamericana (Iowa);
- por parte do cliente había preocupacións sobre posibles atrasos de acceso de Europa e Asia e interrupcións en servizo en caso de inactividade do DBMS.
A pesar de que o propio Django pode traballar con varias bases de datos en paralelo e dividilos en lectura e escritura, na aplicación non había tanta escritura (máis do 90% está a ler). E en xeral, e en xeral, se foi posible facelo lectura-réplica da base principal en Europa e Asia, esta sería unha solución de compromiso. Ben, que ten de complicado?
A dificultade era que o cliente non quería renunciar ao uso de servizos xestionados e Cloud SQL. E as capacidades de Cloud SQL son limitadas actualmente. Cloud SQL admite a alta dispoñibilidade (HA) e a réplica de lectura (RR), pero o mesmo RR só se admite nunha rexión. Unha vez creada unha base de datos na rexión americana, non podes facer unha réplica de lectura na rexión europea usando Cloud SQL, aínda que o propio Postgres non che impide facelo. A correspondencia cos empregados de Google non levou a ningunha parte e rematou con promesas ao estilo de "coñecemos o problema e estamos a traballar nel, algún día o problema resolverase".
Se enumeramos brevemente as capacidades de Cloud SQL, terá un aspecto así:
1. Alta dispoñibilidade (HA):
- dentro dunha rexión;
- mediante a replicación do disco;
- Non se usan motores PostgreSQL;
- control automático e manual posible - failover/failback;
- Ao cambiar, o DBMS non estará dispoñible durante varios minutos.
2. Ler réplica (RR):
- dentro dunha rexión;
- espera en quente;
- Replicación de streaming PostgreSQL.
Ademais, como é costume, á hora de elixir unha tecnoloxía sempre te atopas ante algunha restricións:
- o cliente non quería crear entidades e usar IaaS, excepto a través de GKE;
- ao cliente non lle gustaría implementar o autoservizo PostgreSQL/MySQL;
- Ben, en xeral, Google Spanner sería bastante axeitado se non fose polo seu prezo, con todo, Django ORM non pode funcionar con el, pero é algo bo.
Tendo en conta a situación, o cliente recibiu unha pregunta de seguimento: "Podes facer algo semellante para que sexa como Google Spanner, pero tamén funcione con Django ORM?"
Opción de solución número 0
O primeiro que se me ocorreu:
- permanecer dentro de CloudSQL;
- non haberá replicación integrada entre rexións de ningunha forma;
- intente anexar unha réplica a un Cloud SQL existente de PostgreSQL;
- inicie unha instancia de PostgreSQL nalgún lugar e dalgún xeito, pero polo menos non toque mestre.
Por desgraza, resultou que isto non se pode facer, porque non hai acceso ao host (está nun proxecto completamente diferente) - pg_hba e así por diante, e tampouco hai acceso baixo superusuario.
Opción de solución número 1
Despois de reflexionar máis e tendo en conta circunstancias anteriores, o pensamento cambiou un pouco:
- Aínda estamos intentando permanecer dentro de CloudSQL, pero estamos cambiando a MySQL, porque Cloud SQL by MySQL ten un mestre externo, que:
— é un proxy para MySQL externo;
- parece unha instancia de MySQL;
- inventado para migrar datos doutras nubes ou On-premises.
Dado que configurar a replicación de MySQL non require acceso ao host, en principio todo funcionou, pero era moi inestable e incómodo. E cando fomos máis lonxe, volveuse completamente asustado, porque despregamos toda a estrutura con terraform, e de súpeto resultou que o mestre externo non estaba apoiado por terraform. Si, Google ten unha CLI, pero por algún motivo todo funcionaba aquí de vez en cando: ás veces créase, ás veces non. Quizais porque a CLI se inventou para a migración de datos externos, e non para as réplicas.
En realidade, neste momento quedou claro que Cloud SQL non é adecuado para nada. Como din, fixemos todo o que puidemos.
Opción de solución número 2
Dado que non foi posible permanecer no marco de Cloud SQL, tentamos formular requisitos para unha solución de compromiso. Os requisitos resultaron ser os seguintes:
- traballo en Kubernetes, máximo aproveitamento dos recursos e capacidades de Kubernetes (DCS,...) e GCP (LB,...);
- falta de lastre dunha morea de cousas innecesarias na nube como o proxy HA;
- a capacidade de executar PostgreSQL ou MySQL na rexión principal de alta disponibilidad; noutras rexións - HA do RR da rexión principal máis a súa copia (para fiabilidade);
- multi master (non quería contactar con el, pero non era moi importante)
.
Como resultado destas demandas, pDBMS e opcións de vinculación adecuadas:
- MySQL Galera;
- CockroachDB;
- Ferramentas PostgreSQL
:
- pgpool-II;
-Patrones.
MySQL Galera
A tecnoloxía MySQL Galera foi desenvolvida por Codership e é un complemento para InnoDB. Peculiaridades:
- multi mestre;
- replicación sincrónica;
- lendo desde calquera nodo;
- gravación en calquera nodo;
- mecanismo HA incorporado;
- Hai un gráfico Helm de Bitnami.
CucarachaDB
Segundo a descrición, a cousa é absolutamente bomba e é un proxecto de código aberto escrito en Go. O principal participante é Cockroach Labs (fundado por persoas de Google). Este DBMS relacional foi orixinalmente deseñado para ser distribuído (con escala horizontal fóra da caixa) e tolerante a fallos. Os seus autores da compañía delinearon o obxectivo de "combinar a riqueza da funcionalidade SQL coa accesibilidade horizontal familiar das solucións NoSQL".
Unha boa vantaxe é o soporte para o protocolo de conexión post-gress.
Pgpool
Este é un complemento para PostgreSQL, de feito, unha nova entidade que se fai cargo de todas as conexións e as procesa. Ten o seu propio equilibrador de carga e analizador, licenciado baixo a licenza BSD. Ofrece moitas oportunidades, pero parece algo asustado, porque a presenza dunha nova entidade podería converterse na fonte dalgunhas aventuras adicionais.
Patroi
Isto é o último no que caeron os meus ollos e, como resultou, non en balde. Patroni é unha utilidade de código aberto, que é esencialmente un daemon de Python que che permite manter automaticamente clústeres PostgreSQL con varios tipos de replicación e cambio automático de roles. A cousa resultou moi interesante, xa que se integra ben co cuber e non introduce novas entidades.
Que escolleches ao final?
A elección non foi doada:
- CucarachaDB - lume, pero escuro;
- MySQL Galera - tampouco está mal, úsase en moitos lugares, pero MySQL;
- Pgpool — moitas entidades innecesarias, integración así coa nube e os K8;
- Patroi - Excelente integración con K8s, sen entidades innecesarias, intégrase ben con GCP LB.
Así, a elección recaeu en Patroni.
Descubrimentos
É hora de resumir brevemente. Si, o mundo das infraestruturas informáticas cambiou significativamente, e isto é só o comezo. E se antes as nubes eran só outro tipo de infraestrutura, agora todo é diferente. Ademais, as innovacións nas nubes aparecen constantemente, aparecerán e, quizais, só aparecerán nas nubes e só entón, grazas aos esforzos das startups, trasladaranse a On-premises.
En canto a SQL, SQL vivirá. Isto significa que necesitas coñecer PostgreSQL e MySQL e poder traballar con eles, pero aínda máis importante é poder utilizalos correctamente.
Fonte: www.habr.com