本文回顾了作者在使用HANA数据库过程中遇到的性能瓶颈，尤其是在处理大量数据和高频写入时。作者强调了代码重构和需求导向对于抵抗熵增的重要性，并表示硬件升级并非终极解决方案。
好久没有写博客了，最近趁着兔年年尾总结一下今年碰到的有意思的事情。
前言
随着S4的一脚油门踢走了R3，但是提走的同时也是陈旧的硬盘数据库，迎来了新的内存级别数据库HANA，初尝HANA威力的我感觉无所不能，但是我也终于找到了他的瓶颈了，再快的HANA也终究有他的极限。
场景重现
随着HANA使用的第6个年头，很多东西迎来了熵增，我们有多个十亿级别的数据表，并且每天有超过千万级别的写入和覆盖，在如此的重负下hana也到达了他的资源极限，但是我知道这只是我们硬件的极限并不是他的极限，只要再加内存在2的64方之前都是硬件极限并不是理论极限。只要硬件能不断拓展，HANA还是能无所不能。
抵抗熵增
不过作为短期到达了极限的角度来说，需要有人站出来抵抗熵增，熵增是由于开发时的技术水平限制，过多的使用资源，代码的重构才能解决这一系列的问题，而代码时服务于现实世界的实际需求，如何锚定需求，卸除不合理的开发资源浪费抵抗熵增。
如果有开阔您的眼界，可以请笔者喝杯咖啡
扫一扫
326
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
