Maison > Questions et réponses > le corps du texte
微服务架构中，每个服务都有自己的独立数据库。
然而现在有个需求，需要生成一张实时的报表，该报表包含两个服务的数据。
如服务A，服务B。B中仅包含A的主键id作为关联。
而此报表的搜索条件包含A服务实体中的字段也包含B服务实体中的字段。
现有方案
1、如果搜索条件中包含A的条件，则先去服务A中搜索，得到所有结果的主键，在服务B中使用where A.id IN （ids） 再次查询
想法：当A.id数量庞大时，这个查询极其缓慢！ 而A.id数量庞大的情况很多
2、使用搜索引擎
想法：感觉杀鸡用牛刀
请教各位大牛有更好的方案吗
迷茫2017-04-18 10:57:55
Laxatif
S'il s'agit de données commerciales en ligne (OLTP), la première option est la pratique standard des microservices. Si de telles requêtes connexes doivent être effectuées fréquemment en ligne, cela signifie que le couplage des deux services (et de leurs deux bibliothèques) est très sérieux, alors pourquoi s'embêter à les séparer en premier lieu ?
S'il s'agit d'un rapport d'analyse, il relève de la catégorie OLAP. La solution 2 est en effet une solution souhaitable. Si vous pensez que l'utilisation d'un moteur de recherche est excessive, vous pouvez également essayer d'effectuer diverses opérations d'analyse de rapports sur la base de données esclave. Par exemple, la base de données A en ligne et la base de données B sont synchronisées avec une base de données en lecture seule en temps réel, puis. dans la base de données en lecture seule, JOIN se fait en une seule fois.
天蓬老师2017-04-18 10:57:55
L'un des principes de conception des microservices est de séparer les services qui ne sont pas liés à l'entreprise en services distincts. Il y a un chevauchement entre vos activités.
PHP中文网2017-04-18 10:57:55
En fait, ce genre de problème est très courant dans les microservices. Par exemple, vous devez interroger la commande via certaines informations sur le produit. La commande et le produit appartiennent respectivement à deux microservices. ce n'est pas seulement vos deux solutions, mais aussi Oui
Placez l'agrégation de données dans l'entrepôt de données, agrégez les données en A et B en temps réel dans une autre bibliothèque (pas nécessairement mysql, cela peut aussi être Hbase), et les données extraites du rapport sont extraites de l'entrepôt de données Allez sur
Lors de la conception de la table, il convient de redondant certains champs Comme vous l'avez dit, certains champs de A peuvent être redondants de manière prévisible sur B
La méthode 1 présente un défaut très fatal. Une fois la pagination impliquée, cette méthode n'est certainement pas réalisable. La solution à adopter dépend de l'ordre de grandeur de vos données, si la quantité de données correspondante n'est pas très importante, vous. peut utiliser la méthode 1. Si la vitesse est lente, vous pouvez ouvrir quelques threads supplémentaires pour récupérer les données correspondantes par lots (il y a trop d'identifiants, extrayez-les par lots et les requêtes par lots sont des solutions efficaces qui peuvent réduire les délais d'attente et le temps) ; si la quantité de données est très importante. Il est recommandé d'utiliser un entrepôt de données. Le principal avantage de l'utilisation d'un entrepôt de données est qu'il n'exercera pas de pression sur la base de données principale, car la génération de tables agrégées peut être obtenue via. Binlog ; car le rapport appartient toujours à la catégorie des données hors ligne, s'il est vraiment nécessaire. Comme la requête de commande, qui est en temps réel et très efficace, elle est également accompagnée de l'état de la table, et il y a tellement de recherches conditions, le moteur de recherche est donc un bon choix
Vous pouvez donc utiliser la méthode 1 et la méthode 3 en fonction de la situation réelle
黄舟2017-04-18 10:57:55
Des exigences telles que la génération de rapports ne doivent pas être placées dans les systèmes de bases de données d'entreprise. Vous pouvez créer un ensemble de bibliothèques d'agrégation Otter sur le backend pour synchroniser les données de plusieurs services en temps réel. .Comment jouer
