IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:拓扑

共 2 篇相关文章

IT 累计浏览 2,720

趣题:能否把三维空间分成无穷个圆?

这篇讲的是一个看似简单却暗藏玄机的几何趣题:我们能不能用无数个彼此绝不“触碰”的圆形,把整个三维空间严丝合缝地填满?作者从这个经典的二维平面问题出发,探讨将其推广到三维世界时会遇到的根本性挑战。 核心冲突在于,圆是一个二维图形,而空间是三维的。这意味着,无论这些圆如何排列,它们必然需要“悬浮”在不同的高度或角度上。问题的关键变成了,这些悬浮的圆所占据的空间体积,能否恰好填满整个三维空间而不留空隙,也不相互重叠。作者引导读者思考圆的几何定义及其在三维中可能呈现的形态。 经过分析,结论是这实际上无法实现。因为圆在三维中无论怎么摆放,其本质仍是二维的,无法真正具有“体积”来填充三维空间。任何一个空间点,要么在某个圆的平面上,要么就不在。要完全覆盖三维空间,需要的是具有体积的三维实体,而非平面图形。这个看似巧妙的设想,最终揭示了维度差异带来的根本限制。

IT 累计浏览 2,053

ORACLE系统搭建的一般拓扑

这篇讲的是Oracle系统搭建中一个常见的认知偏差:技术团队往往被“百分百高可用”的期望所困扰,但实际上,系统拓扑的复杂度与冗余设计,并不单纯由投资预算或口头承诺决定。 作者从一个非常现实的管理矛盾出发:老板投入重金,自然期望系统坚不可摧;而工程师面临的却是资源有限、应用各异的技术约束。文章直指核心——系统究竟能达到何种可用性与性能水平,根本上取决于承载的业务应用特性。一个OLTP交易系统与一个OLAP分析报表系统,其理想的拓扑结构、数据流向与高可用方案必然大相径庭。 因此,这篇文章并非泛泛介绍“如何搭建Oracle”,而是引导读者在动手之前先厘清思路:你的应用到底需要什么?是低延迟的高并发读写,还是大批量的数据处理?明确了应用画像,才能反向推导出合适的硬件选型、网络拓扑、数据复制与备份策略。最终,一个健康的系统,其架构是“长”在应用需求之上的,而非堆砌在老板的期望之中。