2017-10-16 4 views
2

J'ai une base de données relationnelle Postgresql existante. Quelques tableaux contiennent des blobs très gros, ils seraient beaucoup mieux que des documents NoSQL. Cela allégerait considérablement notre base de données relationnelle. Donc, nous avons pensé à déplacer ces blob-tables dans une solution NoSQL comme CosmosDB ou MongoDB. Cependant, il existe des dépendances de clé étrangère avec des tables purement relationnelles, ce qui complique le déplacement de ces tables dans leur propre base de données.Combiner NoSQL et la base de données relationnelle sur une seule instance Postgresql

J'ai trouvé que PSQL supporte nativement le stockage de documents et peut être distribué. Les solutions que j'ai examinées jusqu'à présent sont CitusData et Postgres XL. Pour ceux qui les ont utilisés, comment se comparent-ils?

Est-ce que quelqu'un a déjà rencontré des situations similaires? Avez-vous séparé dans une base de données NoSQL? Ou est-ce que quelqu'un a partitionné son PSQL en parties relationnelles et NoSQL? Comment ça c'est passé? Que recommanderiez-vous de regarder en arrière avec le recul?

+1

Ce type de question est très large et sollicite l'opinion, sans réponse objective. La façon dont vous accomplissez cela dépend de vous, en ce qui concerne le travail avec plusieurs bases de données (* persistance polyglotte *), vs travailler dans une seule base de données (Postgres dans votre cas). Malheureusement, hors sujet pour StackOverflow. –

+1

Donc, fondamentalement, vous voulez vraiment SQL mais appelez-le nosql? Pourquoi? Avez-vous essayé de tout faire "SQL", ou au moins des objets JSON? Quel était le problème qui devait être résolu par NoSQL? –

Répondre

0

Chaque RDBMS-> migration NoSQL nécessiterait un des deux: 1. intégrer certains de ces documents à charge dans ceux qui sont réellement interrogés par l'utilisateur 2. documents faisant référence à charge par identifiant et ces relations sur inférer lecture .

Très typique, tout le monde le fait tous les jours, n'ayez pas peur. BTW, vous n'avez pas à faire un choix entre Cosmos DB et MongoDB - il suffit d'utiliser Cosmos DB avec MongoDB API.

+0

L'OP ne demande pas de migrer depuis RDBMS-> NoSQL. Et ce n'est pas aussi simple que l'intégration ou le référencement. Généralement, le schéma entier doit être réévalué. –

+0

Mon commentaire portait sur cette ligne de pensée controversée: _ "nous avons pensé à déplacer ces blob-tables dans une solution NoSQL comme CosmosDB ou MongoDB, mais il y a des dépendances de clés étrangères avec des tables purement relationnelles, ce qui complique le déplacement de ces tables. propre base de données. "_ Et oui, c'est RBDMS-> NoSQL. – alekseys

5

(Citus Ingénieur ici)

Postgres est de type colonne JSONB qui est puissant et flexible. Ce que vous pouvez faire est de garder votre table structurelle telle quelle et de mettre une colonne jsonb pour les données blob. Testez-le avec un seul nœud Postgres et si cela fonctionne pour vous, génial! Si vous avez un problème avec l'échelle de vos données, par exemple mémoire ou stockage ou processeur d'une seule machine ne suffit pas pour votre charge de travail et que vous ne pouvez pas agrandir, vous pouvez essayer d'étendre avec Citus ou Postgres-XL .

Je n'ai aucune expérience avec Postgres-XL, mais Citus est assez facile à essayer. Il existe des images docker que vous pouvez utiliser ou vous pouvez créer un compte sur Citus Cloud pour essayer un plan de développement gratuit d'une semaine (il ne serait pas adapté à des fins d'analyse comparative).

-3

Vous n'avez pas besoin de Citus ou de Postgres-XL pour utiliser le type de données de document JSONB de Progres (leur type de données NoSQL). Le standard hors de la boîte Postgres peut le faire par défaut.

Il existe une longue liste de détails entre les deux. Il est important de noter que Postgres-XL n'a pas de support HA ou fail over. Si vous perdez un nœud dans le cluster, vous perdez la base de données entière. Du côté de Citus, soyez prêt à payer des frais d'abonnement annuels à six chiffres extrêmement coûteux et à être obligé de l'utiliser comme un service «cloud». Ils vous soutiennent techniquement en le dirigeant vous-même, mais ils lancent tellement de barrages routiers que ce n'est pas faisable.