HANA的空间是怎么计算的

问题：      如果企业要上HANA，企业数据是500G，每年增长50G，怎么计算需要多少hana的内存服务器。预估HANA的内存容量的计算公司是什么。

回答:
      这500G是基础生产数据，按照HANA的建模理论，采用列式存储，datasize可以压缩到1/5，约100G，年增长50G，可压缩到20G以内，这样就是120GB。按内存占用75%计算，需160G。

      其实，HANA建议的是敏捷式建模，如果采用空间换时间策略，内存要求可进一步降低。具体就是预先计算好，并保存在内存中，再把明细数据从内存中卸载。

      以上回答，不知是否满意？收起

你这个问题有点太泛了，HANA的空间计算相对来说是个比较麻烦的问题，要注意以下几点：
1.使用类型，olap or oltp，这两种方式是有着不同的计算方式的，一般来说，oltp推荐1:4，olap1:2，官方说的1:7,1:8不是说到不了，但建议大家悠着点，不可全信，毕竟那是个理论值；
2.真实数据大小，你需要区分出500G数据有多少是索引，多少是真实的数据，理论上来说hana是不需要建索引的，这部分空间是不需要的，（实际上，某些特定场景下需要索引，例如上亿的表，）；
3.至于大家提的数据的相似性影响压缩比的问题，我个人觉得在做sizing的时候，可以不用过多考虑，实际上你也很难考虑好
基于以上原因，建议如下：
1.现在512G与1T市场价格差距并不是特别大，你所在的企业都开始用HANA了，可见并非微小企业了，建议直接购买1T使用（我估摸着1T应该够用了，我们原来1.2T的oracle数据库也是迁移到1T的HANA中）。
2.建议用sap quick-sizing做一次容量评估，以确定HANA最终容量（但别完全指望这玩意，sizing其实并不好做，坑也比较多）收起

简单可以理解为，就是数据重复度约大压缩率越大。一楼说的已经差不多了，除了这些还要估计一下活动数据（你没说用途，这里指较劲时间的数据，时间比较久的历史数据很少查看,建表时记得分区。如果历史数据全表load到内存意义不大，浪费资源）如果说500G里有200G活动数据，按5:1的压缩率导入到HANA活动数据也就是200/5=40几个G（这里仅仅是举例，别太矫汁），除了数据使用内存、计算用内存（没有oracle临时表空间类似，都是内存里计算,比较费）还有操作系统和几个hana服务name service\xsengine\统计服务，你的内存至少是  128左右（最低使用） ，日志卷大小接近128G（高速IO存储设备如ssD）,存储就要按总数据计算约(500+2*50）*3/5 =600G(这个也比较低) ,考虑归档和备份保留适当空间。   这里所说的表在hana里必须是“列表”，这里给的都是比较低的值，如遇到模型设计不合理，大表未分区各种问题可能会经常内存溢出，而不得不重启。买硬件时SAP提供了一个认证的机器列表，都是在里面选品牌、配置。给你的建议是256内存，FIO（日志卷用）卡现在好像不强制了用SSD也行（最好RAID10），磁盘存储1.2~2T。具体的自己拿主意，如果不差钱就整个IT~2T内存的，考虑高可用可用做scale out ,至少3台服务器收起

学习一下。收起

看你原系统是什么类型的数据库、数据分布情况如何，压缩比是不一样的。销售说能达到7:1，实际可能是3
：1，看具体情况。存储至少是3倍的数据大小，内存按1倍大小，日志单独计算（OLAP\OLTP数据更新频率有所不同，一般约等于1倍大小）收起

搭车问大神，公司的hana有20G的数据，hana进程为啥占用了145G内存，按我这个比例，楼主hana100G内存，得买1T内存的机器和license。

另外我们公司hana压缩率只能达到3点几。so，楼主1T内存都不见得够。收起

你还是没说用途，OLTP用途就不需要太大内存128就差不多，OLAT用途256~512比较好，不差钱买最贵的就好了:lol收起

回复 3# peterli


    可以给个具体的示例来说明一下，便于更好的理解。谢谢收起