微服务架构中，每个服务都有自己的独立数据库。
然而现在有个需求，需要生成一张实时的报表，该报表包含两个服务的数据。
如服务A，服务B。B中仅包含A的主键id作为关联。
而此报表的搜索条件包含A服务实体中的字段也包含B服务实体中的字段。
现有方案
1、如果搜索条件中包含A的条件，则先去服务A中搜索，得到所有结果的主键，在服务B中使用where A.id IN （ids） 再次查询
想法：当A.id数量庞大时，这个查询极其缓慢！ 而A.id数量庞大的情况很多
2、使用搜索引擎
想法：感觉杀鸡用牛刀
请教各位大牛有更好的方案吗
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Laksatif
Jika data perniagaan dalam talian (OLTP), maka pilihan satu ialah amalan standard perkhidmatan mikro. Jika pertanyaan berkaitan sedemikian perlu dilakukan dengan kerap dalam talian, ini bermakna gandingan kedua-dua perkhidmatan (dan dua perpustakaan mereka) adalah sangat serius, jadi mengapa perlu bersusah payah untuk memisahkannya dari awal?
Jika ia adalah laporan analisis, ia termasuk dalam kategori OLAP Penyelesaian 2 sememangnya penyelesaian yang diingini. Jika anda merasakan bahawa menggunakan enjin carian adalah berlebihan, anda juga boleh cuba melakukan pelbagai operasi analisis laporan pada pangkalan data hamba Contohnya, pangkalan data A dalam talian dan pangkalan data B disegerakkan ke pangkalan data baca sahaja dalam masa nyata, dan kemudian dalam pangkalan data baca sahaja JOIN dilakukan sekali gus.
Salah satu prinsip reka bentuk perkhidmatan mikro ialah mengasingkan perkhidmatan yang tidak berkaitan dengan perniagaan kepada perkhidmatan berasingan Terdapat pertindihan antara perniagaan anda.
Malah, masalah seperti ini sangat biasa dalam perkhidmatan mikro Contohnya, anda perlu menanyakan pesanan melalui beberapa maklumat mengenai produk masing-masing kepunyaan dua perkhidmatan mikro bukan sahaja dua penyelesaian anda sendiri, tetapi juga Ya
Masukkan pengagregatan data ke dalam gudang data, agregat data dalam A dan B dalam masa nyata ke dalam pangkalan data lain (tidak semestinya mysql, ia juga boleh menjadi Hbase), dan data yang ditarik dalam laporan akan ditarik daripada gudang data Pergi ke
Apabila mereka bentuk jadual, adalah wajar untuk melebihkan beberapa medan Seperti yang anda katakan, sesetengah medan A boleh diramalkan berlebihan pada B
Kaedah 1 mempunyai kelemahan yang sangat fatal Setelah paging terlibat, kaedah ini pasti tidak boleh digunakan bergantung pada susunan magnitud yang sepadan dengan data anda. anda boleh menggunakan kaedah 1. Jika kelajuan perlahan, anda boleh membuka beberapa utas lagi untuk mendapatkan semula data yang sepadan dalam kelompok (terdapat terlalu banyak id, tarik mereka dalam kelompok dan pertanyaan kelompok adalah penyelesaian yang berkesan yang boleh mengurangkan masa tamat dan masa ); jika jumlah data adalah sangat besar Adalah disyorkan untuk menggunakan gudang data Manfaat utama menggunakan gudang data ialah ia tidak akan memberi tekanan kepada pangkalan data utama, kerana penjanaan jadual agregat. melalui Binlog; kerana laporan masih tergolong dalam kategori data luar talian, jika ia benar-benar diperlukan Seperti pertanyaan pesanan, yang masa nyata dan sangat cekap, ia juga disertai dengan status jadual, dan terdapat begitu banyak syarat carian, jadi enjin carian adalah pilihan yang baik
Jadi, anda boleh menggunakan kaedah 1 dan kaedah 3 mengikut situasi sebenar
Keperluan seperti menjana laporan tidak boleh diletakkan dalam sistem pangkalan data perniagaan Anda boleh membuat satu set perpustakaan pengagregatan otter di bahagian belakang untuk menyegerakkan data daripada berbilang perkhidmatan dalam masa nyata . Cara bermain