🧘🏻 🏈 🤹🏿 ¿Qué pasa con la popularidad de MySQL y PostgreSQL? Discusión Mitap 👩 ➗ 👩🏿‍🤝‍👩🏾

El 24 de abril, organizamos el mitap en línea MySQL @ Scale sobre problemas de escalabilidad de MySQL . Participaron oradores de Avito, Badoo y ECOMMPAY: Andrey Aksenov (autor de Sphinx, líder de la infraestructura de búsqueda), Evgeny Kuzovlev (CIO ECOMMPAY), Vladimir Fedorkov (experto en MySQL / DBA en ECOMMPAY) y Nikolai Korolev (experto en MySQL / DBA en Badoo).

Mitap salió mucho tiempo, así que decidimos publicarlo en partes, y comenzar desde el final, con una discusión muy interesante en nuestra opinión sobre la popularidad de MySQL y PostgreSQL, las razones de la popularidad de PostgreSQL, ORM, la falta de coincidencia de impedancia, los índices fractales, la ira, la negación, la negociación y la configuración del autovacío. y otros problemas de elegir un DBMS por los desarrolladores de libros de visitas en NodeJS. ¡Atención! No hay vocabulario muy censurado, se han reemplazado varias generalizaciones incorrectas, y cualquier coincidencia es aleatoria y de ninguna manera es de naturaleza ofensiva.

Alexey Rybak : Tome MySQL vs PostgreSQL, no solo un holivar, sino algo bastante medible y visible. Hay análisis, miré no solo un indicador. Ahora recuerdo dos cosas en mi cabeza. Tenemos un grupo de Facebook sobre gestión y desarrollo de grandes proyectos. Hay varios miles de personas. Hice una encuesta en PostgreSQL o MySQL, incluido quién es la nube, los usos que no son de la nube, porque este también es un tema muy nuevo, muy candente en los últimos años.

Y resultó que Postgres está (ligeramente) por delante de MySQL, y para mí fue básicamente una especie de historia nueva, porque parecía que la proporción debería ser diferente. Y hay encuestas que se realizan en las conferencias de HighLoad, se publicaron. No tengo una comparación sistemática directa año tras año, pero demostró claramente que Postgres en algún momento en términos de la cantidad de respuestas a la pregunta "¿cuál es su base de datos principal?" Alcanzó y superó a MySQL.

Tuve una conversación con Petya Zaitsev. Hace bastante tiempo, tal vez hace dos años, vino a Moscú. Esto es básicamente todo el pensamiento de Petya. Los pensamientos son tales que, en primer lugar, se ha hecho mucho para introducir varios tipos de soluciones de gestión u operadores en la historia de la nube. Y la brecha inicial entre la elección de MySQL o Postgres, parecía nivelada, en el sentido de que si todo era más simple con MySQL, tomó y funcionó, entonces Postgres tuvo que tener muchos bailes con panderetas primero para que esto sanara . Y en el entorno de la nube tienes algo: haz clic en un botón, todo apareció. Es decir, por un lado, se eliminó esta brecha. Entonces, una cierta percepción general en términos de licencias, propietarias, no propietarias, bla, bla, bla, también se vio afectada. En términos generales, si lo simplifica por completo, si no me importa hacerlo con un botón, elegiré qué es más gratis, bueno,o dicen que es gratis. De hecho, no está claro, pero no obstante. Lo que está empaquetado en una caja ideológicamente más correcta. Esta es una historia.

Y la segunda historia es que es específicamente para Rusia, ya que confío en los datos, después de todo, no en el mundo, sino en Rusia, tal vez en el mundo la historia es un poco diferente. Hubo tal historia que en algún momento los congresistas posteriores se unieron con bastante fuerza y comenzaron a trabajar mucho en relaciones públicas. Y crearon grupos de trabajo y conferencias, y durante varios años ha habido una compañía que realmente hace la solución empresarial rusa.

En primer lugar, ¿qué crees que, en Rusia, en el mundo, es este reequilibrio entre MySQL y Postgres, y si es así, cuáles son sus razones, cuántas de las razones que he indicado son racionales, razonables, tal vez hay otras causas?

Evgeny Kuzovlev: Para ser sincero, nunca pensé que la nube parecía suavizar todas las diferencias, probablemente porque tengo todo en las instalaciones. Para mí, las nubes son cosas que, digamos allí, algo en el Amazonas, poblamos rápidamente, luego son nubes para mí. Por lo tanto, de este lado, de alguna manera nunca lo consideré. Pero aquí, de hecho, la complejidad se reduce.

Anteriormente, condicionalmente, hace unos ocho años, para que Postgres trabajara solo para usted, era necesario bailar tanto con una pandereta que en este momento la madre no se aflige. Y sacaste MySQL de la caja y funcionó para ti. Tal vez no ocho, tal vez hace 10-12 años. De hecho, esta complejidad en Postgres se ha reducido considerablemente, y el punto de entrada es operativo y de desarrollo, se comparó con MySQL de alguna manera.

Pero yo, por ejemplo, por nosotros mismos, resolvimos ese problema, traté de acercarme e intenté acercarme lo más distante posible. Necesitamos, cuando comenzamos DWH, seleccionar el motor para la tabla desnormalizada. Al mismo tiempo, no hay análisis allí, los análisis están en un nivel ligeramente diferente. Es solo puro almacenamiento. Se necesitaba un DBMS revolucionario para proporcionar, respectivamente, un análisis de comparación de datos.

Y abordamos esta pregunta MySQL o Postgres, y a pesar del hecho de que los recursos operativos están bastante calificados, elegimos. Y yo, por ejemplo, tuve la impresión de que Postgres, él es, ya sabes, académico. Como está escrito en el libro de texto, así funcionará. Y MySQL, de alguna manera es bastante ligero y con un montón de hacks. Pero al mismo tiempo, estos hacks funcionan en el 99% de los casos. Y no importa cuántos chicos de Postgres den puntos de referencia sintéticos, en situaciones reales, que cubren el 99% del uso real de las bases de datos, MySQL gana a los usuarios comunes.

Y la ventaja, realmente, maldita sea, es solo una gran ventaja de MySQL, que no tiene vacío automático. Porque configurar esto en Postgres, no todos pueden hacerlo. Y tan pronto como los usuarios ...

Vladimir Fedorkov: Suena mal (en relación con los ingenieros - aprox. AR ).

Evgeny Kuzovlev: Y tan pronto como los usuarios se encuentran con la aspiradora automática, comienzan a experimentar los problemas más salvajes. Es decir, así, para obtener una degradación del sistema del 60 por ciento, eso es para usted, esto es ...

Alexei Rybak: No, acabo de entrar en la carta de triunfo.

Evgeny Kuzovlev: Bueno, lo siento. Inmediatamente dispuesto como sobre una mesa. Sin embargo, sé que, por supuesto, tenemos Postgres. Tenemos mucho de eso. Tenemos problemas con la aspiradora automática, gracias a Dios, no. Pero en mi carrera pasé por todos estos casos: enojo, negación, negociación y ajuste de vacío automático. Pero esta es una sensación tan dolorosa, te lo diré. MySQL no causa tanto dolor.

Al mismo tiempo, estoy muy furioso porque en MySQL no tengo la oportunidad ... quiero, pero aquí tengo un índice B-tree y eso es todo. ¡Y aunque te rompas! No sé, no puedo simplemente construir ...

Alexey Rybak: Hay índices hash.

Evgeny Kuzovlev: Sí. Pero, comparemos el número de índices que tenemos en MySQL y el número de índices que tenemos en Postgres. Esto es incomparable. Al mismo tiempo, lo mismo puede decirse de los motores de mesa. En MySQL tenemos un motor de tabla, quieres, no sé, irás, tomarás un poco de TokuDB, y disfrutarás en el uno por ciento de los casos y en el 99% de los casos no entiendes por qué lo tomaste ...

Andrey Aksyonov: frotis con fractales.

Alexey Rybak:Bueno, espera, con los motores, esto también es un engaño. Anteriormente, cuando se inventó, parecía algo genial. Pero, de hecho, nada realmente echó raíces.

Andrey Aksyonov: ¿Por qué no echó raíces? InnoDB ha echado raíces.

Alexey Rybak: No, quiero decir, además de InnoDB. Es decir, InnoDB se ha convertido en un estándar. Y todas las otras historias con piezas de columna, con algunas piezas más específicas, como Toku. Tienes razón, ni siquiera sé dónde está este porcentaje. Es decir, los motores resultaron ser tan dudosos.

Evgeny Kuzovlev: Sabes, psicología humana, es tal que a veces la posibilidad misma de elección es más importante que la elección misma. MySQL lo da.

Alexei Rybak: La gente no elige MySQL contra Postgres, porque hay diferentes motores. Creo que este es el último ...

Vladimir Fedorkov: Porque cuando la gente elige MySQL contra Postgres, si hay al menos alguien en la compañía que está detrás de Postgres, será elegido porque es una religión.

Alexey Rybak: MySQL también es una religión.

Vladimir Fedorkov: No, de ninguna manera.

Andrey Aksyonov:Nadie arrojó otro punto importante, llamado "contingente ha crecido". Los requisitos han crecido naturalmente en una determinada capa. La pregunta inicial es por qué el porcentaje de Postgres está creciendo, el porcentaje de esta falsa miserable llamada MySQL está disminuyendo constantemente. Y, por supuesto, al final, En principio, el planeta es el mismo, los dinosaurios pisotearán y MongoDB derrotará a todos, pero es en el futuro, pero la escala web sigue siendo importante, porque los requisitos que hacen las aplicaciones cambian en el tiempo, una vez y en un momento Postgres por su parte, y el conjunto de requisitos de los desarrolladores ha crecido para ellos.

Alexei Rybak: Escucha, no lo creo, perdóname. Dime, digamos específicamente ...

Andrey Aksyonov: Vamos específicamente. Mira, 1995 ...

Alexey Rybak:Las compañías que originalmente lanzaron productos de escala web que están diseñados para los mismos tipos ... Dios, ¡salí de mi cabeza! Acabo de llamar ... Ahora, aquí está quién derrotará a todos ...

Andrey Aksyonov: Mongo ganará.

Alexey Rybak: Mongo, sí, sí, sí, lo siento, sí. Entonces, Mongo inicialmente tenía dos cosas. Primero, el almacén de objetos, no piense, en resumen, ORM, solo escriba, guarde y no necesite nada, SQL no necesita saber, en resumen, eso es todo. Esto llevó a algunos tipos, sus requisitos no han cambiado, son simples: sí, pero era posible, no se podía enseñar SQL, ¡guau! ¡Que guay! Simplemente dijo: ¡guarda el objeto y me dejó en algún lugar, clase! Este es el primero.

Segundo que? No piense en la tolerancia a fallos, inicialmente podemos hacerlo en varios DC y así sucesivamente. Al principio fue una mierda de marketing. Luego torcieron algo y, en principio, según tengo entendido, en las últimas versiones ahora (funciona y) mucho donde realmente se usa Mongo en grandes instalaciones.

Quiero decir, este es un buen ejemplo cuando entras en el mercado, otro mercado, después de haber sentido estas dos posibilidades, que, en primer lugar, las personas que crecieron en el paradigma de programación en lenguajes de objetos, en general, este desajuste de impedancia, Esta es una historia fundamental. Es más fácil para ellos usar herramientas que dicen: "solo sálvame", haré todo por ti. Y al mismo tiempo, fuera de la caja, esas cosas asociadas con la cola, y algo más.
Aquí lo entendería, a pesar del hecho de que vuelvo a decir, troll, lo pones como algún tipo de caso hiperbólico, relativamente hablando, algún tipo de ficción. Sin embargo, este caso, dice exactamente al respecto, es que puedes salir con ese producto, encontrar ese nicho, y él volará, pisoteará, explotará. No entiendo qué sugirió Postgres o cómo cambiaron y qué requisitos de repente, según su lógica, Postgres se volvió tan atractivo.

Andrey Aksyonov: Repito una vez más. Brotes en ambos lados; Postgres en ciertos parámetros, por un lado, y desarrolladores en ciertos parámetros, por el otro. Una vez más, 1995. Eres un desarrollador Te sientas en B ... ( Atyrau ), ganas $ 15, y este es un año. Y escribes c ***** ( sin valor) libro de visitas en Perl. Y luego comienza el proceso de selección: qué base de datos elegir. Sorprendentemente, tanto MySQL como Postgres ya existen. Y si no lo son, aparecerán en 1996. ¡Pero tú, s *** (mujer de la familia canina) , el desarrollador del libro de visitas de Perl in B ... ( Syzran )! Tienes una tarea de esta magnitud, las resuelves.

El único punto de referencia en el que puede pensar es en cuántas solicitudes "por círculo" por segundo apestará. Y "en el círculo" de solicitudes por segundo en este momento, Postgres atrae cuatro veces y media menos. Solo así, solo porque te jodan. Después de eso, busca: bueno, sí, pero en las transacciones de Postgres y en MySQL 3.23 MyISAM. Pero para ser honesto, las transacciones de mi libro de visitas son nulas para mí (en absoluto)Innecesario. Elija firmemente MySQL.

Ahora ha pasado un poco de tiempo, 25 años. En principio, todavía vives en B ... ( Tuymazy ), ya no escribes en Perl, pero en NodeJS, tu salario ha sido indexado, porque es solo una inflación en dólares, y ahora son 15 dólares, multiplicado por la inflación, - 45, y este es un mes Tiene los mismos problemas, más 100,500 paquetes en NodeJS. Y estos paquetes 100500 NodeJS necesitan almacenar su estado completo en algún lugar, solicitudes complejas sobre el administrador de paquetes, etc.

Y de repente tienes tus requisitos, que muerdes en la base de datos, han crecido un poco. Por ejemplo, por alguna razón no puede vivir y no quiere vivir sin transacciones. ¡Qué sorprendente coincidencia! Aún necesitas uniones. Aquí hay algunos índices extraños que comienzan a pensar, y no solo un árbol B automático, como: ¡oh, maldición! Pero sería bueno tener un índice geográfico, un árbol R o, digamos, Dios nos salve, árboles fractales.

Esto ha cambiado el conjunto de requisitos de los desarrolladores, veces. Y, por otro lado, Postgres, que en los años de los antiguos, naturalmente, simplemente disminuía encantadoramente en simples "círculos" ( solicitudes), que eran tontos y necesarios para todos, mejoró enormemente en el último corto período de 25 años, por su parte. Y entonces se conocieron de repente, y cada vez más personas se sorprenden al encontrar eso, ¡op! Te ves! Pero resulta que Postgres no es tan malo. Y es algo mejor para mis requisitos. Mi hipótesis es exactamente tal que, en términos generales, al comienzo de MySQL ...

Alexey Rybak: Escucha, pero no entiendo dónde es mejor. ¿Qué es mejor? Entiendo que son iguales en algo, pero lo que es mejor, no lo entiendo.

Andrey Aksyonov: Entonces ambos son peores.

Alexey Rybak: Than Mongo?

Andrey Aksyonov:Por supuesto, que, entre comillas, "Mongo". Pero este es un tema para una conversación completamente separada, y un hilo de conversación completamente separado llamado "dónde está el futuro brillante".

Vladimir Fedorkov: No hay un futuro brillante. La base de datos es malvada. Tan pronto como seleccione una base de datos, se firma una sentencia de muerte. No use bases de datos. Escribir archivos

Alexey Rybak: / dev / null! Escriba a / dev / null, amigos, dev / null es escala web.

Andrey Aksyonov: Sí. Bueno, está bien, también puedes encontrar / dev / null en principio en rendimiento, nosotros podemos.

Alexey Rybak: Está bien, amigos. Probablemente todos estén muy cansados. Llevamos más de dos horas hablando.

Andrey Aksyonov: Pero no se han planteado preguntas realmente interesantes.

Nikolay Korolev:Acabo de empezar.

Alexey Rybak: ¿En serio? ¿Quieres continuar?

Andrey Aksyonov: tampoco he vertido whisky.

Alexey Rybak: Pero esta es una gran pregunta por qué no lo hiciste.

Andrei Aksyonov: No me preparé , por supuesto ...

Vladimir Fedorkov: Entonces dijeron que transmitir, transmitir, nada es imposible, no puedes jurar, no puedes engordar.

Alexey Rybak: ¡Ah! ¡Amigos! Todos los que estaban viendo la transmisión, muchas gracias por estar con nosotros. Comenzamos la parte no oficial, dónde se apaga ... Ahora ... elimino la transmisión en vivo. Muchas gracias a todos, gracias a nuestros invitados: Vladimir, Andrey, Eugene, Nikolai. Salga, adiós, hasta luego.

(fin de la grabación)

El registro completo del mitap se puede ver en youtube:

En un futuro cercano, también publicaremos otras partes en la infraestructura, los patrones de escala / tolerancia a fallas y el estado del ecosistema MySQL.

Si te gusta este formato, este viernes habrá otro rally dedicado a la infraestructura de contenedores, todavía hay lugares para ello . Participantes: Yevgeny Potapov (CEO de ITSumma), Dmitry Stolyarov (CTO Flant), Denis Remchukov (también conocido como Eric Oldmann, COO argotech.io, ex - RAO UES de Rusia), Andrey Fedorovsky (CTO News360.com) y Ivan Kruglov (ingeniero de sistemas, ex - Booking.com). Hablemos de las herramientas, problemas y perspectivas de los contenedores y Kubernetes en una infraestructura moderna.

También tenemos el mencionado grupo de Facebook "Gestión y desarrollo de grandes proyectos de TI" , el canal @feedmeto con publicaciones interesantes de blogs de tecnología corporativos (en su mayoría extranjeros) y el canal del autor @rybakalexey sobre gestión del desarrollo en empresas de alimentos.

¿Qué pasa con la popularidad de MySQL y PostgreSQL? Discusión Mitap

More articles: