Bases de données sur HighLoad ++ 2019

Travailler avec une base de données est ce qui affecte considérablement les performances de tout service Web. Si vous essayez , vous pouvez organiser une charge élevée sans aucune charge.

Et si vous faites tout à bon escient, il s’agira de traiter les demandes de plusieurs milliers d’utilisateurs. Par conséquent, la planification HighLoad ++ comporte traditionnellement de nombreux rapports sur les bases de données. Nous avons des pistes sur PostgreSQL, MySQL et ClickHouse, il y a plusieurs rapports sur MongoDB (dans la meilleure tradition, le locuteur est ingénieur de performance en MongoDB). De plus, il y a des discours sur la comparaison de différentes approches ou sur la considération de solutions spécialisées. Et pour la généralité, ajoutons Tarantool et en mémoire ici. Au total, 33 rapports sont directement liés à la section «Bases de données et systèmes de stockage» et au moins 10 indirectement. Et cela ne compte pas les mitaps , qui ne sont pas moins de dix, et de nouveaux seront ajoutés en cours de route.

Nous essaierons de vous aider à naviguer dans toute sa diversité et à ne pas manquer des rapports vraiment uniques. Pour des raisons de fiabilité, nous demandons l'avis du membre du comité de programme responsable de cette section, Nikolay Samokhvalov. Et ne regardez pas que Nikolai est le fondateur de Postgres.ai et généralement des postgresmen - il connaît bien le monde des bases de données, il connaît des histoires et des tendances intéressantes dans les coulisses.

La revue est organisée le plus simplement possible: nous avons ouvert la liste des rapports et nous sommes allés de haut en bas, en nous attardant sur les sujets auxquels il fallait prêter attention.

ClickHouse Query Profiler

Le profileur de requêtes dans les bases de données analytiques est une chose très intéressante. L'approche doit être très différente des bases de données OLTP, car, en règle générale, les requêtes sont effectuées dans des bases de données analytiques pendant une longue période. Si dans PostgreSQL le plan d'exécution des requêtes est statique, alors il est logique de surveiller presque une requête.

Dans ce rapport, Nikita Lapkov parlera de la conception d'un tel profileur de demande ClickHouse, qui vous permet de déterminer quelle section du code ralentit pour une demande particulière . Et prenez les mesures appropriées pour mettre en œuvre le fameux «ClickHouse ne ralentit pas».

Sauvegarde dans une infrastructure moderne

Ce rapport est juste de la série «à côté de la base de données», il examine le problème du système, mais la majeure partie est consacrée à la question des sauvegardes dans MySQL. L'histoire d'Anton Turetsky sera certainement intéressante, car c'est l'expérience Badoo, c'est-à-dire qu'il s'agit d'un grand nombre de serveurs . À une telle échelle, sauvegarder et, surtout, tout vérifier est une tâche non triviale. De plus, ils ont réussi à se faire des amis des tendances et des paradigmes modernes de conception de systèmes avec sauvegarde afin de ne pas perdre la confiance que les données nécessaires peuvent être obtenues dans n'importe quel cas, même le plus critique.

NB: Les sauvegardes sans vérification automatique ne sont pas des sauvegardes.

Passer à ClickHouse: 3 ans plus tard

ClickHouse conquiert sa position en toute confiance, mais peu de développeurs tiers ont réussi à accumuler une solide expérience en travaillant avec elle. Alexander Zaitsev et Altinity sont des pionniers de l'utilisation de ClickHouse, il y a 3 ans, ils ont parlé sur HighLoad ++ de la migration du système d'analyse multi-pétaoctets vers ClickHouse.

Qu'est-ce qui a changé depuis? Alexander partagera son expérience et son savoir-faire, qui ne se trouvent pas dans la documentation.

MongoDB vs. Repères Postgres

Deux invités parleront de MongoDB dans HighLoad ++. Le rapport Álvaro Hernández a un contexte intéressant, voire scandaleux. Quand Alvaro a fait et introduit des benchmarks comparant MongoDB et PostgreSQL, une escarmouche a éclaté sur Internet. MongoDB a ensuite présenté ses références.

En conséquence, chacun des mondes a simplement sa propre philosophie. Les adhérents de PostgreSQL ont du mal à accepter une telle attitude floue envers les données, mais les solutions MongoDB sont en demande sur le marché. Les comparer directement est presque impossible, ce qui rend le rapport d'Alvaro très excitant. Il est facile d'adhérer aveuglément à un point de vue, mais il est préférable de connaître et de comprendre les deux.

C'est un fait amusant pour tout le monde - Michael Stonebreaker a participé. Il a attiré l'attention sur le différend entre Postgres et Mongo et a publié plusieurs articles sur les problèmes de ce modèle. C'est-à-dire que le fondateur de Postgres, qui à une époque a déclaré qu'une taille unique ne convenait pas à tout le monde, et a donc lancé la création de bases de données spécialisées, y compris NoSQL, revient essentiellement à Postgres. Il écrit quels problèmes il y a, suggère de marier des modèles de données et dit généralement que tout va bien avec Postgres. Il est très intéressant de regarder ce cycle de vingt ans.

MongoDB a réparti les transactions de haut en bas

Le deuxième rapport sur MongoDB sera réalisé par Henrik Ingo, l'architecte de la solution MongoDB, spécialisé dans l'amélioration des performances de MongoDB et la haute disponibilité. Mais Henrik, avant MongoDB, a travaillé dans le monde MySQL pendant de nombreuses années, il connaît donc exactement les arguments des différents camps.

Chez HighLoad ++, Henrik vous expliquera comment effectuer des transactions dans une base de données NoSQL distribuée pour satisfaire ACID, et pourquoi vous pourriez en avoir besoin.

Feuille de route Odyssey: que voulons-nous d'autre de l'extracteur de connexion

Il y a trois semaines, la principale limitation de PgBouncer, que les entreprises rencontrent souvent, a été supprimée, mais elle a déjà réussi à déranger tout le monde. Par exemple, parce qu'il était impossible d'apporter des améliorations à l'open source - les correctifs Yandex et Avito n'ont pas été acceptés depuis des années.

Yandex n'a pas attendu ces changements et a fait leur extracteur de connexion - Odyssey. Il est multi-thread, il a des puces supplémentaires, et Andrei Borodin le dira plus en détail dans son rapport . De plus, il sera possible de discuter de la feuille de route - quelles fonctionnalités de l'extracteur aimeraient voir dans les nouvelles versions de la communauté.

Bot DBA Joe. Soulage la douleur du développement backend

Avec ce rapport, Postgres.ai propose de changer fondamentalement l'approche du développement backend. Au lieu de vérifier le code et les requêtes sur les petites bases de données, vérifiez les grandes bases de données et voyez immédiatement le résultat. Cela semble logique - si la demande est lente, elle sera détectée immédiatement. Une autre chose est de savoir quoi faire pour cela, par exemple, des copies à part entière de la base de données de combat sont très gênantes. C'est là que le bot artificiel DBA Joe vient à la rescousse

Joe peut écrire une demande ou demander de créer un index, et il effectuera toutes les actions sur une copie pleine taille de la base de données de combat. À tout moment, vous pouvez recommencer, annuler toutes les modifications en quelques secondes, supprimer les caches du système d'exploitation et du SGBD. Et pour le travail de dix développeurs n'ont pas besoin d'espace disque x10. Comment cette magie fonctionne-t-elle et à partir de quels composants open source vous pouvez essayer de la collecter vous-même, Anatoly Stansler vous le dira .

Cher DELETE. Erreurs typiques lors de l'exécution d'opérations massives dans des bases de données PostgreSQL hautement chargées

Et s'il semble à quelqu'un qu'il n'y a rien de mal à supprimer plusieurs millions de lignes avec un SUPPRIMER, lorsque la condition est connue et qu'il existe un index approprié, alors vous devez écouter le rapport de Nikolai Samokhvalov. Si vous essayez d'effectuer une opération dans de telles conditions, le service tombera très probablement, et il y a beaucoup de raisons pour cela immédiatement: DBA n'a pas fonctionné, les développeurs ne se sont pas comportés correctement et l'approche organisationnelle était erronée.

Nikolay montrera comment Postgres.ai aide à résoudre ces problèmes et comment configurer la protection sans l'utiliser et toujours agir de manière fiable sans abandonner le prod. Tout cela est basé sur une expérience réelle de la douleur et d'énormes pertes financières . Parce qu'il semble clair que vous ne pouvez pas supprimer immédiatement, mais, par exemple, marquer d'abord les données pour suppression, mais les opérations de blocage sur un million de lignes sont toutes rencontrées.

Patroni sur GitLab.com

GitLab utilise PostgreSQL au complet, MySQL récemment abandonné, et pour s'assurer que HA est passé de REPMGR à Patroni. Patroni a été développé par Zalando, sa tâche est de basculer automatiquement si quelque chose est arrivé à l'assistant, et d'assurer la disponibilité du service.

Maintenant, Patroni est la norme de facto , et GitLab l'a implémentée sur sa solution cloud - pour une seconde, 25 000 000 d'opérations pull git par jour - et prépare une solution pour vérifier les installations. Jose Cores Finotto partagera cette expérience super intéressante sur HighLoad ++ le 7 novembre.

StackGres: PostgreSQL natif du cloud sur Kubernetes

Álvaro Hernández, en comparaison avec PostgreSQL et MongoDB, présentera également le produit StackGres - essentiellement un remplacement pour RDS. Mais cela permet de déployer RDS dans Kubernetes beaucoup moins cher, d'obtenir des sauvegardes configurées avec un minimum d'effort avec une remorque, Patroni pour le basculement automatique, un bilan de santé et un tas d'outils différents.

Il s'agit d'une entreprise prometteuse dans une direction similaire à l'histoire de Linux. Il existe un noyau Linux et de nombreux assemblages différents autour de lui. Nous voyons la même chose en ce qui concerne PostgreSQL, qui peut être considéré comme le noyau d'un SGBD, et des assemblages apparaîtront autour de lui. StackGres a de bonnes chances de gagner en popularité, car il y a une équipe animée et des clients où vous pouvez prendre vos décisions.

Verrous PostgreSQL

Les verrous sont fondamentalement un sujet que tous ceux qui travaillent avec PostgreSQL devraient écouter. De plus, Yegor Rogov, qui s'est imposé comme un conférencier décédé, en parlera. Il connaît profondément le matériel et vous aidera à comprendre les types de verrous et à comprendre comment lire pg_locks et pg_stat_activity et éviter un certain nombre d'erreurs dans la conception du système. Le rapport d'Egor sur HighLoad ++ est une excellente occasion non seulement d'écouter, mais de parler avec un expert, de lui poser vos questions et éventuellement de discuter de problèmes complètement différents.

Sauvegarde du SGBD chargé

Andrey Borodin et Georgy Rylov travaillent chez Yandex et développent WAL-G, un outil de sauvegarde open source.

Initialement, WAL-G est un outil pour PostgreSQL développé par Citus (il est curieux que Microsoft ait récemment absorbé Citus, c'est-à-dire, en fait, acheté un morceau de PostgreSQL). Mais il s'est avéré que l'idée d'organiser le travail avec WAL-G est bien adaptée à d'autres bases de données. Andrew et George ne feront que parler des fonctionnalités de MySQL, Redis, MongoDB et des perspectives qui s'ouvrent à cet égard.

Vitess: évoluer sans peur dans le cloud

Sugu Sougoumarane est le fondateur de PlanetScale. Vous n'avez peut-être pas encore entendu parler de cette entreprise, mais récemment, elle a reçu un financement de 25 millions de dollars pour développer son produit Vitess ouvert. Vous n'avez peut-être pas entendu parler de Vitess non plus. Donc, Vitess est un système de partitionnement MySQL , et vous connaissez certainement plus d'une grande entreprise qui utilise Vitess pour des bases de données très chargées.

Tout a commencé avec YouTube. C'est là que Sugu et son équipe ont créé ce qui est devenu plus tard le système open source Vitess. Au fait, ils ont choisi le Go - une langue très jeune à l'époque. Sugu peut raconter de nombreuses histoires intéressantes sur les premières années de Go et sur son développement en général - sur Google, son équipe est devenue le premier grand utilisateur de la langue.

Eh bien, maintenant, en plus de YouTube, Vitess est utilisé par des sociétés telles que GitHub, Pinterest, Slack, Square. Après avoir quitté Google, Sugu a fondé PlanetScale et continue de développer Vitess, en gardant le code ouvert. Venez entendre parler du sharding à l'échelle planétaire et de l'utilisation de Go en Real Highload. Et n'oubliez pas de poser des questions sur les plans de la version Postgres de Vitess - Sugu aime beaucoup cette question.

Histoires d'échecs de Patroni ou comment planter votre cluster PostgreSQL

C'est drôle que nous écoutions le principal responsable de Patroni sur un sujet différent , car il nous a déjà parlé de Patroni. Mais Aleksey Lesovsky peut dire comment Patroni est exploité en dehors de Zalando et quels cônes sont rembourrés. Parce que ces cônes peuvent être très différents, et Alex promet de partager les détails des vrais crash-cases . Nous allons apprendre du rapport quels problèmes il y a, quelles leçons ont été apprises dans Data Egret et comment configurer correctement Patroni (et, éventuellement, PostgreSQL). Et, bien sûr, nous avons une idée de la façon d'identifier rapidement les problèmes émergents et de les résoudre rapidement.

SQL / JSON: nous implémentons le standard et ne nous arrêtons pas là

Récemment, la frontière entre les SGBD relationnels et orientés document a été floue. Le standard SQL a des fonctions pour travailler avec JSON, et PostgreSQL est un pionnier de la prise en charge JSON efficace parmi les SGBD relationnels . En grande partie grâce à Postgres Professional, la norme a déjà été partiellement mise en œuvre.

Le rapport d' Alexander Korotkov est un compte rendu de première main de l'implémentation SQL / JSON et de son «cœur» jsonpath dans PostgreSQL. C'est l'occasion d'en apprendre davantage sur les fonctionnalités internes, l'expérience d'exploitation et les plans pour l'avenir.

PostgreSQL sur K8 à Zalando: deux ans de bataille

Alexander Kukushkin est co-auteur de Patroni, mais cette année, il parlera d'un autre développement intéressant de Zalando. Il y a deux ans, ils ont commencé à développer Postgres-Operator et à l'heure actuelle, avec son aide, les opérateurs DBA desservent plus de 1000 clusters Postgres fonctionnant sur Kubernetes.

Alors que certains doutent encore que des bases de données soient possibles dans Kubernetes, les grandes entreprises travaillent déjà avec tout cela. Ce serait cool d'apprendre à connaître et d'apprendre ailleurs.

L'entreprise appelle Postgres

Les grandes entreprises utilisent de plus en plus PostgreSQL, en attendant très souvent ce à quoi elles sont habituées dans l'entreprise. Un exemple typique - nous avons besoin de solutions pour la réplication logique - nous nous tournons vers le fournisseur. Et certains fournisseurs ont même fourni un tel support - il y avait Oracle, maintenant PostgreSQL est apparu. Mais nous commençons à comprendre, et il s'avère que beaucoup de choses fonctionnent différemment.

Nous assistons à la collision des mondes de l'open source et de l'entreprise. Andreessen Horowitz a récemment publié une étude indiquant que l'intérêt des investisseurs pour l'open source a considérablement augmenté et continuera de croître. Par conséquent, les fournisseurs doivent passer à l'open source et à de nouveaux modèles de monétisation - ce sera mieux pour un certain nombre de raisons.

Ivan Panchenko vous dira quelles sont les difficultés de migration vers PostgreSQL pour les entreprises qui sont subjectives et appartiennent au type des «mains tordues», et quand sont ces défis importants auxquels PostgreSQL doit faire face pendant son développement. Les résumés promettent la discussion de ces sujets: facteurs d'échelle (tailles de table, nombre d'objets, mémoire, connexions, réplication), fonctionnalités de stockage (tas, stockages enfichables), tables temporaires, vide, interaction avec le système d'exploitation.

Et sur cette note - l' avenir est open source - nous terminerons une étude détaillée des rapports. Malheureusement, dans les coulisses, MySQL a été presque complètement laissé pour compte. Si tel est votre sujet, consultez Vittorio Cioe et Alkin Tezuysal .

ClickHouse est également représenté dans un plus grand nombre de rapports, et comme toujours, un mitap est d' une valeur particulière, où vous pouvez poser des questions sur ClickHouse, avec les développeurs trouver une solution aux problèmes, discuter des opportunités et des plans.

Nous n'avons pas non plus touché Tarantool, car il s'agit d'une base de données et d'un serveur d'applications dans une seule bouteille. Et les rapports du programme HighLoad ++ 2019 se concentrent sur cette multifonctionnalité. Vasily Tyubek parlera de Tarantool Kubernetes Operator pour exécuter une base de données à Kubernetes, Yaroslav Dynnikov montrera la commodité de construire des systèmes distribués à l'aide de Tarantool. Et ne manquez pas l'occasion de clarifier tous les détails avec les développeurs eux-mêmes - c'est beaucoup plus productif et intéressant que de lire la documentation.

En général, nous considérons les questions aux conférenciers, les discussions dans les coulisses et le réseautage - une partie très, sinon la plus importante de la conférence. Par conséquent, nous créons toutes les conditions pour une communication informelle et essayons de passer un bon moment.

Les 7 et 8 novembre, HighLoad ++ remplira SKOLKOVO à ras bord et en jaillira . À Novossibirsk et à Saint-Pétersbourg, il y aura leurs succursales HighLoad ++ avec une téléconférence au hall principal et tous les avantages du réseautage lors de la conférence. Sur youtube, nous lancerons une diffusion vidéo ouverte des reportages les plus attendus et du HighLoad ++ Award , et sur la chaîne télégramme nous lancerons des agents de traduction de texte selon une trajectoire différente. En bref, même si vous n'allez pas à HighLoad ++ (en vain - vous pouvez toujours changer d'avis, obtenir un billet et décoller), vous pouvez toujours obtenir beaucoup de bien et de plaisir à travers nos réseaux.