边肖将与您分享一个hbase寻址机制的示例分析。相信大部分人都不太了解，所以分享这篇文章给大家参考。希望你看完这篇文章会有很多收获。我们一起来看看吧！
hbase寻址机制的详细说明
系统如何找到某一行键(或某一行键范围)所在的区域大表？使用三层B-tree类结构来存储区域位置。
第一层是将文件保存在zookeeper中，zookeeper保存了根区域的位置。
第二级根区域是。META。的其他区域的位置。存储了META.z表。通过根区域，我们可以访问的数据。META。桌子。META。是第三层，它是一个特殊的表，保存着hbase中所有数据表的位置信息。
//见图
描述：
1根区域永远不会被分割，这确保了定位任何区域最多需要三次跳转。
2.2.META. table保存每一行中一个区域的位置信息，行键由表名表的最后一个代码编码。
3为了加快访问速度，所有地区的。META。表存储在内存中。
假设一行。META。表占用内存约1KB。并且每个区域限制为128MB。
那么上述三层结构可以存储的区域数量为：
(128 MB/1KB)*(128 MB/1KB)=2(34)个区域
4客户端将查询到的位置信息保存在缓存中，缓存不会主动失效。因此，如果客户端上的缓存完全失效，需要六次网络往返才能定位到正确的区域(其中三次查找缓存失效，三次获取位置信息)。
从上面的路径中，我们可以看到用户需要3个请求才能到达用户的Table的真实位置，这导致了某些程序的性能下降。在0.96之前使用3层设计的主要原因是考虑到元数据可能需要很多。但是在实际的集群操作中，元数据的大小其实很容易计算。在BigTable的论文中，METADATA数据每行的存储大小约为1KB。根据一个128M的Region的计算，三层设计可以支持的区域数为2.34，两层设计可以支持的区域数为2.17 (131072)。然后，在2层设计的情况下，一个集群可以存储4P数据。这只是该地区仅有1.28亿人的一个例子。如果是10G呢？因此，通过计算，其实双层设计可以满足集群的需求。因此，在0.96版本之后，删除了-ROOT-表。
提示：有不同的版本，分为老寻址方式和新寻址方式。
以上就是文章《hbase寻址机制实例分析》的全部内容。感谢阅读！相信大家都有一定的了解，希望分享的内容对大家有所帮助。想了解更多知识，请关注行业资讯频道！
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/138995.html