SnappyData企业版中off-heap功能及与on-heap功能的对比

目录:

    • 1、SnappyData OSS的功能介绍
    • 2、SnappyData企业版的额外功能
    • 3、企业版off-heap功能的对比与测试
    • 4、结论
    • 5、参考

1、SnappyData OSS的功能介绍

OSS是Open Source SnappyData Community Edition的简称,其是一个基于Apache 2.0的开源的分布式数据库产品,包含了如下的功能:

  • 多种数据模型,同时支持行表与列表,且都具有可变性(DML)。同时支持结构化查询语言:标准SQL-92和Spark SQL
  • 100%兼容Apache Spark,允许用户在单个集群中,既可以存储数据同时进行数据计算
  • 支持shared nothing存储,即每个server具有独立的存储,通过数据复制技术(redundancy)实现高可用性
  • 支持REST API方式提交spark job并提供容错功能
  • 支持两种访问方式:JDBC和Spark API
  • 提供了命令行工具,来实现备份、恢复和数据的导出
  • 扩展了Spark Console以提供集群的额外信息
  • 一个完整的统计库和一个可用于在线和离线分析系统性能和行为的可视化统计查看器(DashBoard)
  • 行表上支持事务以及索引
  • 流处理上扩展了Stream SQL

2、SnappyData企业版的额外功能

企业版包含了所有OSS版本的功能,除此之外还提供了一些额外的功能。但是在将企业版投入生产前,需要获取授权。但是可以试用并评测企业版的功能。

以下是企业版提供的额外功能:

  • 提供采样表,允许用户设置一定的精度损失比例,以达到用近似精确的结果换来更低的查询延迟的目的
  • 支持ODBC driver
  • 对于列表而言,支持off-heap配置,这样的好处是可以减少垃圾的生成、降低gc调优复杂性以及提供更好的性能
  • 可以对 Microsoft SQL Server提供实时的数据导入功能
  • 提供了GemFire(Apache Geode)的连接器
  • 通过LDAP实现了对用户的安全认证与接口

3、企业版off-heap功能的对比与测试

SnappyData支持on-heap存储,同时企业版中支持off-heap存储。官方建议在列表上使用off-heap功能,而行表只支持on-heap。

可以通过在server上对memory-size和heap-size来分别设置off-heap的大小以及on-heap的大小。

如果配置了off-heap功能,那么列表上的存储与部分计算,都会使用off-heap池。但是on-heap池同样需要设置,因为会有以下几种情况用到on-heap池:

  • external connector使用时的中间结果,会用到on-heap池,例如从外部表导入数据时,比如parquet、CSV文件以及MySQL等数据库
  • 行表上的存储与计算
  • 列表上的HashJoin与HashAggregate操作会用到on-heap,不过社区会在以后的版本中调整到off-heap中

与on-heap池一样,off-heap池也会把内存分为2个部分:存储区与计算区。

得益于Spark中的动态内存调整功能,两个区域在各自不足时,可以在一定条件下互相借用对方的空间,以实现动态分配:

SnappyData企业版中off-heap功能及与on-heap功能的对比_第1张图片

同时得益于off-heap的精确分配,在其上分配的内存空间总是精确的。

一个简单的配置off-heap的例子如下:

-heap-size=50g -memory-size=50g -critical-heap-percentage=90 -eviction-heap-percentage=81

通过在测试环境测试的off-heap功能,发现列表上的存储确实存于off-heap,但是对列表上进行SQL查询还是用到了on-heap。

就像在上面提到的列表上的HashJoin与HashAggregate操作依然会使用on-heap池,因此,即使配置了off-heap池,也一定要给on-heap留出足够的空间进行诸如HashJoin和HashAggregate操作。

除此之外,我们的测试全部是定期的(1分钟或5分钟)批量join update与批量的join insert操作,在观察on-heap区的gc时,可以看到大部分old代在一次cms gc时还是可以回收不少空间的。

同时,我们也发现off-heap在自动优化方面,好像并不如描述的性能那么高,通过DashBoard可以看到其off-heap的memory使用量已经超出列表存储不少空间了,也就是说在垃圾的产生以及自动回收方面,并没有想象的那么好。

SnappyData企业版中off-heap功能及与on-heap功能的对比_第2张图片

4、结论

  • 1、如果使用off-heap功能,那么一定要给on-heap留出足够的空间,因为列表上的HashJoin操作和HashAggregate操作以及外部表的导入和行表的使用都会用到on-heap。

  • 2、off-heap的在垃圾产生和自动回收方面,并没有很好的效果且用户不可控。

5、参考

Configuring the Cluster-Configuration
Best Practices-Memory Management

你可能感兴趣的:(sql与plsql,大数据,HTAP)