我应该使用什么策略/技术来进行这种复制？
我目前遇到一个问题，还没有找到好的解决方案，所以希望得到大家的建议。
我的问题如图所示 
核心数据库是所有客户端连接的地方，用于管理实时数据，这些数据非常大且繁忙。时间。
特征数据库不经常使用，但它需要从核心数据库获取部分实时数据（可能是 5%），但向该服务器请求任务将花费较长时间并消耗大量资源。
我当前的解决方案是什么：
我在核心数据库和数据库之间使用了数据库复制。特征数据库，工作正常。但 问题是我浪费了大量的磁盘空间来存储不需要的数据。 （复制数据不适用于我的数据库架构时进行过滤）
使用排队系统不会使数据按时生效，因为对核心数据库有很多请求。
如果您遇到过这种情况，请提出一些想法？
谢谢，
庞
I am currently facing one problem which not yet figure out good solution, so hope to get some advice from you all.
My Problem as in the picture
Core Database is where all the clients connect to for managing live data which is really really big and busy all the time.
Feature Database is not used so often but it need some part of live data (maybe 5%) from the Core Database, But the request task to this server will take longer time and consume much resource.
What is my current solution:
I used database replication between Core Database & Feature Database, it works fine. But
the problem is that I waste a lot of disk space to store unwanted data.
(Filtering while replicate data is not work with my databases schema)Using queueing system will not make data live on time as there are many request to Core Database.
Please suggest some idea if you have met this?
Thanks,
Pang
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您定义的是一个经典的数据集成任务。您可以使用任何数据集成工具从核心数据库中提取数据并将其加载到特色数据库中。您可以实时安排数据集成作业，也可以安排任意时间范围。
我在中型 (10GB) 半科学 PostgreSQL 数据库集成项目中使用了 Talend。效果非常好。
您还可以尝试SQL Server Integration Services (SSIS)。这个工具也非常强大。它适用于所有一流的 RDBMS。
What you define is a classic data integration task. You can use any data integration tool to extract data from your core database and load into featured database. You can schedule your data integration jobs from real-time to any time-frame.
I used Talend in my mid-size (10GB) semi-scientific PostgreSQL database integration project. It worked beautifully.
You can also try SQL Server Integration Services (SSIS). This tool is very powerful as well. It works with all top-notch RDBMSs.
如果您担心的只是磁盘空间，我会坚持使用您现在拥有的解决方案。如今，100GB 的磁盘空间还不到一美元 - 对于这笔钱，您实际上无法承担在系统中引入新解决方案的费用。
从逻辑上讲，还有一个理由将过滤保留在同一个应用程序中 - 保留了解哪些记录在应用程序本身内部相关的责任，而不是在某些神秘的集成层中，这将降低整体解决方案的复杂性。仅当您确实需要时才接受特殊集成层的额外复杂性。
If all you're worrying about is disk space, I would stick with the solution you have right now. 100GB of disk space is less than a dollar, these days - for that money, you can't really afford to bring a new solution into the system.
Logically, there's also a case to be made for keeping the filtering in the same application - keeping the responsibility for knowing which records are relevant inside the app itself, rather than in some mysterious integration layer will reduce overall solution complexity. Only accept the additional complexity of a special integration layer if you really need to.