我们是否应该将报告数据仓库放在事务数据库服务器上
我们即将向我们的系统添加一个报告数据仓库。目前我们使用 Oracle 10g 作为我们的事务数据库。我们应该将报告仓库放在物理上不同的硬件上吗？或者我们可以“便宜一点”并共享交易服务器吗？
We are about to add a Reporting Data Warehouse to our system. Currently we are using Oracle 10g for our transaction database. Should we put the Reporting Warehouse on physically different hardware? or can we "go cheap" and share the Transaction Server?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这实际上取决于会影响 OLTP 的仓库操作的时间安排和负载。
例如，如果您的主要数字运算需要占用大量资源，但您在晚上/OLTP 不常使用的时间进行，那么应该没问题。
如果您使用正确的索引并将聚合表放在适当的位置，以便在报告数据检索时不会进行太多处理，那么 OLAP 的资源利用率相当低。
你应该做的最重要的事情就是反规范化、反规范化、反规范化。使报告结构尽可能扁平，然后构建良好的索引结构来支持您的查询。
许多实现已经在 OLAP 和 OLTP 之间共享资源。
只是不要让数豆子妨碍制作豆子，反之亦然，你应该没问题。
It really depends on the timing and load of the warehouse operations that will affect on your OLTP.
For example, if you have major number crunching that takes a lot of resources, but you do it in the night / at a time when the OLTP is not used much, you should be fine.
If you use proper indexing and put aggregate tables in place so that you do not crunch much at report data retrieval time, then the resource utilization of the OLAP is fairly low.
The biggest thing you should do is denormalize, denormalize, denormalize. Make the reporting structures as flat as possible and then build good index structure to support your queries.
A lot of implementations already share resources between OLAP and OLTP.
Just don't let counting beans get in the way of making beans, and vice versa and you should be OK.
如果您有用于 OLTP 的灾难恢复计算机，您也许可以将其用于您的仓库。
另一种选择是在同一硬件上使用两个虚拟机。
您可以使用虚拟机
管理分配最小/最大
内存、CPU 等。
如果一个数据库需要紧急处理
补丁，你不用担心
它会影响其他数据库。
移动也变得更简单
稍后再使用自己的硬件，如果
证明是必要的。
如果您使用不同的服务器，您的存储空间是什么？如果它们来自相同的共享磁盘，即使使用单独的 CPU/内存，它们仍然会相互影响。
If you have a disaster recovery machine for your OLTP, you might be able to use that for your warehouse.
Another option is to go for two virtual machines on the same hardware.
You can use the VM
management to allocate min/max
memory, CPUs etc.
If one database needs an urgent
patch, you don't have to worry about
it affecting the other database.
It also becomes simpler to move one
off to its own hardware later, if it
proves necessary.
If you use a different server, what is your storage ? If they are coming off the same shared disks, they can still impact each other, even with separate CPU/memory.