Doctolib a besoin d'une base de données plus puissante. Ok, ... ? (Bertrand Paquet et David Gageot)

Sdílet
Vložit
  • čas přidán 23. 08. 2024
  • Pour rester informé sur l'actualité de Devoxx France, suivez nous sur twitter : / devoxxfr ou consultez notre site web www.devoxx.fr/
    Depuis 8 ans, Doctolib propose des rendez-vous médicaux à plusieurs millions d'utilisateurs en utilisant une base de données unique PostgreSQL.
    Nous ne sommes plus très loin aujourd'hui des limites physiques d'Aurora (PostgreSQL managé par AWS): nous opérons une des plus grosses bases de données transactionnelles d'Europe et pourtant nous prévoyons de grossir encore pour supporter notre croissance. Certes, il serait possible de tronçonner cette énorme base de données (voir d'en mettre certaines parties sur d'autres types de storage). Mais chez Doctolib, nous aimons bien l'approche simple d'avoir une seule base :)
    Dans cette session, nous exposerons:
    - Les limites actuelles, nos besoins immédiats et futurs
    - Les critères d'évaluation que nous avons retenus? Scalabilité, compatibilité du code, coûts, hosting ...
    - Les différentes approches technique de tests
    - Quels sont les solutions que nous avons choisit de tester? Et de ne pas tester?
    - Les résultats de l'évaluation de 3 solutions: Spanner, Yugabyte, Citus
    Plutôt que de rechercher la solution idéale, nous essayerons de mettre en évidence les compromis qui ont été choisis.

Komentáře • 10

  • @JulienBertozzi
    @JulienBertozzi Před 2 lety +1

    "après que 3 ou 4 boîtes nous ait dit que" c'est sur c'était un indice :D
    Merci pour le talk c'était cool

  • @pandaDotDragon
    @pandaDotDragon Před 2 lety +1

    un mot en français, un mot en anglais...

    • @kalakala
      @kalakala Před rokem

      Tu preferes tout en anglais... ?

    • @pandaDotDragon
      @pandaDotDragon Před rokem +1

      @@kalakala tout en anglais ou tout en français. Le mélange des deux n'est rien.

    • @kalakala
      @kalakala Před rokem

      @@pandaDotDragon Je suis pas d'accord.

    • @pandaDotDragon
      @pandaDotDragon Před rokem +1

      @@kalakala Dans le film "Au nom de la rose" lorsque le moine Salvatore mélange latin, espagnol, italien et français dans chacune de ses phrases il y a cette scène entre Sean Connery et Christian Slater:
      - mais quelle langue parle-t-il?
      - toutes... et aucune à la fois.
      Le franglais ce n'est pas l'expression d'un bilinguisme ou d'un professionnalisme. Et oui je sais que certains termes sont difficilement transposable (antialiasing par ex.), je ne vais pas aussi loin que les Québecois. Mais entre utiliser un mot de temps en temps et un mot sur deux...

    • @michelguenin
      @michelguenin Před rokem

      C'est le gros défaut des informaticiens.

  • @oliviera.6850
    @oliviera.6850 Před 2 lety +1

    Sans mettre aucun cout en face ca n'a strictement aucun intérêt votre présentation.

  • @adrienparrot8254
    @adrienparrot8254 Před 2 lety +4

    Bonjour.
    Un grand merci pour cette présentation de qualité.
    Mr David Gageot, je reprends cette phrase : "Chez nous toutes les données médicales sont chiffrées de bout en bout".
    Ne serait-il pas plutôt juste de dire que "seulement les documents (pdf ...) sont chiffrés avec Tanker" ? Les rendez-vous ne sont pas chiffrés avec cette solution. Il y a un chiffrement de repos et en transit "seulement". Le backend voyant les données en clair pour les processer.
    Je rappelle que les données de rendez-vous de santé sont des données de santé. cf www.cnil.fr/sites/default/files/atoms/files/guide-cnom-cnil.pdf
    Adrien

    • @DavidGageot
      @DavidGageot Před 2 lety

      Merci Adrien pour ce retour. Les documents sont en effet chiffrés de bout en bout. C’est également le cas des données de rendez-vous dans Doctolib Médecin (antécédents / traitements…). La date et le lieu des rendez-vous sont eux visibles du backend. Si vous voulez, je peux vous mettre en relation avec notre équipe sécurité pour cerner tous les détails de notre politique de protection des données.