我有兴趣实现一个具有两个数据库的架构，一个用于读取操作，另一个用于写入操作。我从来没有实现过这样的东西，并且总是构建单一数据库、高度规范化的系统，所以我不太确定从哪里开始。对于这个问题我有几个部分。
1.要了解有关此架构的更多信息，什么是很好的资源？
2.这只是两个相同模式之间复制的问题，还是您的模式会根据操作而有所不同，规范化也会有所不同吗？
3.如何确保写入一个数据库的数据可立即从第二个数据库读取？
任何进一步的帮助、提示、资源将不胜感激。谢谢。
编辑
我发现这篇文章对于那些感兴趣的人来说非常有用。
经过一番研究， codefutures.com/database-sharding/
我发现这篇高可扩展性文章内容非常丰富
I am interested in implementing an architecture that has two databases one for read operations and the other for writes. I have never implemented something like this and have always built single database, highly normalised systems so I am not quite sure where to begin. I have a few parts to this question.
1. What would be a good resource to find out more about this architecture?
2. Is it just a question of replicating between two identical schemas, or would your schemas differ depending on the operations, would normalisation vary too?
3. How do you insure that data written to one database is immediately available for reading from the second?
Any further help, tips, resources would be appreciated. Thanks.
EDIT
After some research I have found this article which I found very informative for those interested..
http://www.codefutures.com/database-sharding/
I found this highscalability article very informative
发布评论
评论（3）
我不是专家，但读/写主数据库和只读从数据库模式是一种“常见”模式，特别是对于主要执行读取访问或数据仓库的大型应用程序：
互联网上有很好的资源。例如：
我不确定 - 我渴望阅读专家的答案 - 但我认为传统复制场景中的模式是相同的（尽管调整可能不同）。也许人们正在做更奇特的事情，但我想知道在这种情况下他们是否依赖数据库复制，这听起来更像是“实时 ETL”。
我想您需要同步复制（这当然比异步慢）。虽然有些数据库确实支持这种模式，但据我所知，并非所有数据库都支持。但看看这个答案或这个用于 SQL服务器。
I'm not a specialist but the read/write master database and read-only slaves pattern is a "common" pattern, especially for big applications doing mostly read accesses or data warehouses:
There are good resources available on the Internet. For example:
I'm not sure - I'm eager to read answers from experts - but I think the schemas are identical in traditional replication scenari (the tuning may be different though). Maybe people are doing more exotic things but I wonder if they rely on database replication in that case, it sounds more like "real-time ETL".
I guess you would need synchronous replication for that (which is of course slower than asynchronous). While some databases do support this mode, not all do AFAIK. But have a look at this answer or this one for SQL Server.
您可能会查找数据仓库。
这些用作“标准化报告”类型数据库，同时您可以保留标准化 OLTP 样式实例以进行数据维护。
我认为“立即”等同的想法不会成为现实。将新数据和更改迁移到其他系统时会出现一些延迟。时间表和范围将是你在这里做出的重大决定。
You might look up data warehouses.
These serve as 'normalized for reporting' type databases, while you can keep a normalized OLTP style instance for the data maintenance.
I don't think the idea of 'immediate' equivalence will be a reality. There will be some delay while the new data and changes are migrated in to the other system. The schedule and scope will be your big decisions here.
关于问题 2：
这实际上取决于您想要通过拥有两个数据库来实现什么目标。如果是出于性能原因（我怀疑可能是这样），我建议您根据性能需要考虑对只读数据库进行非规范化。如果性能不是问题，那么我不会搞乱只读模式。
我曾经在类似的系统上工作过，其中会有一个读/写数据库，仅由管理用户少量使用。然后，该数据库将在夜间过程中复制到只读数据库。
问题3：
我们在这里谈论的有多直接？不到一秒？ 10秒？分钟？
In regards to questions 2:
It really depends on what you are trying to achieve by having two databases. If it is for performance reasons (which i suspect it may be) i would suggest you look into denormalizing the read-only database as needed for performance. If performance isn't an issue then I wouldn't mess with the read-only schema.
I've worked on similar systems where there would be a read/write database that was only lightly used by administrative users. That database would then be replicated to the read only database during a nightly process.
Question 3:
How immediate are we talking here? Less than a second? 10 seconds? Minutes?