- 博客(97)
- 资源 (14)
- 收藏
- 关注
RSS订阅原创 一次K8S实操相关的实用笔记，希望能帮助大家填点坑
Sealos 是一个 Go 语言开发的简单干净且轻量的 K8S 集群部署工具，Sealos 能很好的支持在生产环境中部署高可用的 K8S 集群。以上就是我这次去客户现场操作生产环境 K8S 的一点心得和经验，后续有新的内容我还会继续分享。这次的经历再次印证了只有在生产环境下真实的分析和解决问题，才会更深刻的学习知识并积累相关的经验。文章到这里就结束了，最后路漫漫其修远兮，大数据之路还很漫长。
2022-10-26 14:14:10
1814
1
原创 从曾经的一家独大到现在的群雄逐鹿，大数据时代的数据库圈为啥如此之乱？
天下合久必分，分久必合；江山代有人才出，各领风骚数百年这些古语显然也适用于数据库的市场。相对于数据量迅速膨胀这个表象之外，数据类型复杂度的提升以及业务场景的细分才是当今数据库市场百花齐放的根本原因。这也是技术发展的必然，作为程序员的我们必然是痛并快乐着。在技术发展历史的洪流前，我们无力阻挡，只能顺势而为了，活到老学到老看来要真的成为程序员的座右铭了。文章到这里就结束了，最后路漫漫其修远兮，大数据之路还很漫长。
2022-10-10 16:13:33
944
原创 我可能永远也没办法成为全栈工程师了，看看你还差多少？
曾几何时，作者的理想也是做一个全栈工程师。但是十年之后笔者才发现，原来当初刚刚怀揣这个理想的时候竟然是离目标最近的时候。这里面固然有作者水平有限的问题，但是更深层次上的是技术和业务的发展速度已经大大的超出了预期。此一时彼一时，当前的技术广度大大增加，而技术密度却逐渐降低。一招鲜吃遍天下或者一个架构搞定一个行业的时代早已不复存在了。而此时的全栈已经很难和当初的全栈相提并论，能做到细分领域的全栈或者一专多能已经相当不易了。但是理想还是可以有的，能不能实现不重要，能作为前进的动力就好。
2022-09-15 10:30:32
2174
原创 一次logstash的实践解锁了如此多的玩法....
上文就是使用logstash实现整个需求的全过程，可以看到，需求虽小，但是涉及到的问题和内容还是很丰富的，logstash常规的问题基本上都遇到了。但这也是件好事，毕竟这样后续再次使用logstash的时候试错成本就会低很多。只要能正常的用起来，logstash的效率以及稳定性还是比我们手写的软件强很多，更重要的是节省了我们很多的开发以及测试工作量。虽然如此，但是logstash也有自己的缺点。其中最让人诟病的就是logstash耗资源较大，运行占用CPU和内存高。...
2022-08-18 17:20:04
612
原创 位图BitMap不好用？那来看看进化版本的RoaringBitmap，包您满意
到底什么是RBM，这里直接引用网上的定义：从上述的定义可以看出，RBM还是使用到了BM，只是在位图的的基础上进化成了高效压缩位图，从而达到了高性能以及更广泛的使用场景。看到上面的处理逻辑，大家可能会感到疑惑，为什么会选择4096这个阈值呢？其实也很简单，看下面这张图：从上图可以看出 ArrayContainer 和 BitmapContainer 的内存占用随元素个数增加的变化曲线。理论上来说两条线的交点就是整个临界点，在这个点之前 ArrayContainer 占用的内存更少；...
2022-08-11 10:30:12
392
原创 抗战电影中出场率很高的边三轮为什么能在软件界能混的风生水起
从上文可以看出，边车模式其实就是在业务系统这个驾驶员实现业务逻辑的基础上，加了个边车，然后根据需求搭配不同的控制逻辑，从而达到这个业务实现以及服务治理相结合的方式。这样做的好处是在开发以及运维人员之间做了一个很优雅的任务划分，开发人员集中精力完成业务逻辑的开发，运维人员集中精力完成整个的服务治理即可，两方之间只要接口不变，其余都可以做双方无感知的升级与修改，提供了强大的兼容性和扩展性，真正做到研发与运维解耦合，各司其职。......
2022-08-08 09:42:15
731
原创 三十年河东三十年河西，人生如此，大数据处理亦是如此
从上文可以看出，在大数据的世界里，没有什么是一成不变的，每个技术都有自己的生命周期，三十年河东三十年河西的场景在大数据中屡见不鲜。当前炙手可热、众星捧月，可能几年后就销声匿迹，无人问津了。所以，在大数据的世界中想精通一门技术然后躺平是不切实际的。只有不停的学习，不停的进步，吸收先进的技术和思想，才能让自己保持竞争力，才不会在残酷的竞争中被淘汰。大数据的世界中唯一不变的就是变化，拥抱变化才能让自己立于不败之地。这不仅是大数据技术的生存之道，更是大数据从业者的生存之道。httpshttps。...
2022-07-21 15:44:16
459
原创 从中国封建历史的发展来理解云计算、雾计算、边缘计算以及云原生之间的关系
互联网的快速发展，带来了一大批新的名词，这次名词的更新换代的速度也是快的惊人，往往一波未平一波又起，使得大家不能墨守成规，必须不断学习才能赶得上科技和技术的发展潮流。计算机行业更是如此，可能真的要实践活到老学到老的古训了。精通一个技术然后躺着赚钱是不存在的，因为可能几年后这项技术就被淘汰无人问津了。所以千万别再说计算机的高薪如何的不合理。计算机行业只能算门槛不低且付出和产出相对成正比的行业。回到本文的标题，如果问大家这几个名词你听说过吗？大部分人肯定会说：“Yes，I do!”。但是如果让你说清楚他们都是什
2022-07-05 15:26:38
557
原创 磨刀不误砍柴工—ElasticSearch的schema详解
schema即元数据，自从数据库诞生的那一天，这个东西就作为数据库最重要的组成部分而出现了。schema就如同现实世界中的配方或者图纸，被数据库用来生产和管理数据。由于RDS的快速发展以及普及，schema已经成为数据库的标配以及重要的设计部分。好的schema设计以及成为了一套好的数据库系统不可或缺的部分。围绕schema的各种原则和规范也应运而生，如著名的数据库三大范式，都是为了帮助数据库设计者和使用者能更高效的使用和维护数据库。彼时，将schema比喻成是一个数据库的灵魂都不为过。但是，随着NOSQL
2022-06-28 14:26:32
2088
原创 elasticsearch的硬盘存储表现真的惨不忍睹吗？其实没那么糟糕！
ElasticSearch在当今NOSQL中也算独树一帜的存在了，借助于强大的全文搜索能力以及本身具备的多维度搜索以及聚合能力，再加上母公司Elastic公司的良好运作以及ELK体系的普及，使得ElasticSearch在很多场景下都是NOSQL不二的选择。但是所谓人红是非多，再加上NOSQL数据库都有自己的优缺点和适用场景，没办法做到One Stack to Rule Them All，所以ElasticSearch的很多缺点也同样会被大家拿到台面上审视和批评。在这其中除了跨表无法join查询之外，最大的
2022-06-27 15:06:58
1028
原创 要做出高品质的docker镜像，一个靠谱的dockerfile必不可少！
上文简单地梳理了下docker的知识体系，并通过dockerfile了解了docker镜像是如何从0到1的，而本文会在上文的基础上来说明下docker镜像是如何从1到2的。毕竟做出镜像是第一步，而做出高质量的镜像才是我们最终的目的。本文从高质量docker镜像的目标，以及为了达到这些目标，dockerfile都需要做哪些优化两个方面作为切入点，来见证一个高质量的docker镜像是如何诞生的。首先，衡量docker镜像质量的参数主要性能，大小以及安全性三个角度来更快的构建速度更小的Docker镜像大小更少的D
2022-06-23 10:22:50
493
原创 知识点-初识Docker&DockerFile知识点各种整理
前言上周事情比较多，逃了一次更，很是遗憾。不过虽然没更新文章，但是还是思考了下后续如何来记录以及分享知识。其实在很多时候会遇到并解决一些小问题，这些小问题单拿出来写一篇文章可能并不是很合适。但这却是日常解决问题以及知识学习的常态，如果直接放弃掉却又很可惜。再加上很多时候很忙的话，写一篇长文加上画画图可能需要几个小时的时间，这个时间是很难保证的。所以针对上面的情况，我决定后续的记录以及分享通过简单的知识点以及系统的文章两种方式来推进。知识点针对的是散碎的知识的总结，适合利用零散的时间来进行
2022-05-25 10:22:54
271
原创 Kafka的安全性、幂等性以及有序性，这些面试常客你都掌握了吗？
名词解释相信做过数据处理的小伙伴们对于kafka肯定是熟悉的。基础的kafka知识这里就不过多陈述了。今天主要来讲一下kafka的几个特性，下面先简单解释下这几个特性的含义： 安全性：数据从producer中写入到kafka以及consumer从topic中消费数据，数据都不会丢失。 幂等性：数据在kafka的流程中既不会被重新生产，也不会被重复消费。这也是实现exactly-once语义的基础。 有序性：由于kafka是顺序消费，所以kafka的有序性主要体现在生产者写入ka
2022-05-07 10:47:25
998
原创 Elasticsearch这几个很常见却很容易答错的问题，你都能答对吗？
前言elasticsearch发展至今，已经发展到7.X版本了，而其中的小版本更是不胜枚举。而每个版本的发布就会带来新的特性的加入以及旧的特性的修改，这就造成了elasticsearch的配置和使用方法不能一概而论。在这个背景下，很多过时的使用方法以及配置在新版本就不再适用了；另外很多大家在其他NOSQL上习以为常的操作或者想法，也被平行挪到了elasticsearch上，这就造成了很多的谣言以及留言，本文就针对几个比较常见的问题进行下澄清，帮助大家去伪存真，更好的理解和使用elasticsearc
2022-04-29 14:24:53
2891
原创 一个HBase查询问题引发的思考，作为HBase使用者这个问题你知道答案吗?
前言讲解HBase事务的文章很多，这里就不过多赘述了，大家应该都知道是通过MVCC实现的。但是今天这篇文章的背景是一个同事和我讨论一个问题引发的，这个问题使我重新梳理下这块内容并作为记录和大家分享。下面先来看看这个问题：HBase的查询流程是：先查询MemStore，查不到则查询BlockCache，还没有则查询HFile，再将查询到的数据放入BlockCache。请问是不是存在这么一种情况，假如有一条数据id=1，name='张三'，当被查询时，数据被放入blockCache中，后来数据
2022-04-22 16:20:12
3350
原创 大数据组件多租户资源隔离方案
背景为了配合公司产品K8S化，方便产品快速扩展以及部署，需要对当前的大数据组件进行相关的多租户以及资源隔离的配置，组件暂时包含但限于HBase、ElasticSearch、Kafka和Redis。下面将从不同角度对上面提到的四个组件进行多租户以及资源隔离方案的描述，并根据需求选取效果明显且性价比高的方案进行适配与实现。正文目标 实现单集群支持多租户，租户之间相互不影响 能够快速方便的管理单租户的数据 对当前已经存在的产品代码和架构的侵入在可控范围之内尽量的小 方
2022-04-21 10:03:09
2830
原创 漫谈RocksDB(四)存储结构——翩若惊鸿，婉若游龙
前言前面几个章节已经分别说了下RocksDB的基础概念和相关操作，下面来说一说RocksDB的存储结构，根据文件的存储结构再去回过头了解下RocksDB的相关操作。正文文件介绍 *.log: 事务日志用于保存数据操作日志，可用于数据恢复 *.sst: 数据持久换文件（此处的例子没有生成sst文件是因为第一次写数据，数据量小没触发flush操作，数据都在内存的MemoryTable中） MANIFEST：数据库中的 MANIFEST 文件记录数据库状态。Compact
2022-04-13 15:26:04
2329
1
原创 K8S中的学区招生简章和学区房—污点和容忍
前言在刚开始接触到K8S的时候，曾经遇到了一个卡住我两天的一个问题，情况就是我要创建一个三节点的zookeeper，但是创建后发现只有两个节点能够正常调度，有一个节点总是无法调度，如下图所示：当时一直通过日志想了解到底是哪里的问题，结果后来经高人指点才知道是K8S的亲和性以及污点造成的。具体的原因是zookeeper的yaml文件中由于亲和性的配置，导致zookeeper的实例一个节点上只能有一个，而5台机器的K8S集群，有三台机器被打上了污点，导致无法被调度，这就造成了三个zookeeper实
2022-04-02 14:13:22
401
原创 K8S部署方式选择——没有最好的，只有最合适的
前言前面几篇文章讲解了K8S相关的基础知识，但是忘记说了应该怎么去部署K8S的相关组件和服务。今天利用这篇文章补充下。先不考虑K8S的方式，先考虑下在CentOS下我们是如何安装软件的，常规的方式其实就是两种： 下载tar包使用命令：tar -zxvf xxxx.tar来进行解压安装，并配置相关的环境变量，修改相关的系统参数来完成软件的安装。 使用centos自带的yum(rpm)进行安装，当你在使用tar命令进行一顿安装配置的时候，一个yum install xxxx可能会让你感觉
2022-04-01 10:00:43
3326
1
原创 K8S以及Kubesphere离线部署方案
本篇文档描述kubesphere的离线部署过程，kubesphere的版本为3.1.1，kubernetes的版本为1.20.6，其他版本可能过程略有出入。系统要求 系统 最低要求（每个节点） Ubuntu16.04, 18.04 CPU: 2 核，内存：4 G，硬盘：100 G DebianBuster, Stretch CPU: 2 核，内存：4 G，硬盘：100 G CentOS7.x CPU: 2 核，内存：4 G，硬盘...
2022-03-23 16:25:44
3122
1
原创 K8S中service的分类以及各种使用场景详解
前言前面两个章节讲解了K8S的总体入门准备以及全局配置管理的相关内容，正常来说接下来应该将将存储或者组件，但是由于那两部分内容过多且相对偏重细节，所以这一篇先把K8S中的Service先讲解下，帮助大家先理清K8S的整体架构，后续再讲解细节内容的时候可以快速上手，便于理解。正文Service是什么？在说明Service是什么之前先了解下Service的使用场景： 当客户端想要访问K8S集群中的pod时，需要知道pod的ip以及端口，那K8S中如何在不知道pod的地址信息的情况下进行po
2022-02-28 10:20:42
7505
原创 一文弄懂ConfigMap在k8s中的各种玩法以及应用场景
前言在K8S的某些场景下，pod需要依赖各种配置以及配置文件，这些配置不能写死在镜像中，否则会影响到镜像的扩展性。此时ConfigMap作为K8S中提供的配置管理组件登场了。ConfigMap可以将环境变量配置信息和容器镜像解耦，便于应用配置的修改。下文就ConfigMap的使用方法以及使用场景进行下总结，帮助大家在不同场景下能正确的使用ConfigMap。正文上图就是整个ConfigMap的生命周期以及使用方式，下面结合图进行详细讲解。ConfigMap的生命周期ConfigM
2022-02-23 15:18:17
4503
原创 K8S上车必看：亲身排雷，入门基础准备
前言久闻K8S大名，受限于docker知识的欠缺，所以对K8S的探索一直处于逡巡不前的状态，这一拖就是好久，最近这段时间公司准备上K8S集群了，我被安排来负责这件事情的推进。终于有幸可以真正学习下K8S,一睹K8S的芳容了。由于之前缺乏必要的docker相关知识的储备，加上K8S本身内容复杂庞大，所以在学习的过程中费了很大的劲，走了很多弯路才勉强将基本流程搞通，能跑起来一整套服务，下面就根据我的学习以及填坑历程和大家分享下，希望对想入坑K8S的小伙伴们有所帮助，别再走或者少走一些弯路。正文什
2022-02-22 09:43:24
1170
原创 漫谈RocksDB(三)基本操作——动如脱兔，静若处子
前言上一篇文章已经讲述了RocksDB的基础概念，本文趁热打铁，将上文留下的作业以及RocksDB的基本操作集中说明一下，既帮助大家巩固下上文的概念，又为后文的高级操作以及特性打下基础。总体来说，RocksDB的基础操作和LSM tree的基础操作基本相同，但是RocksDB在标准的LSM tree方案的基础上进行了定制化的优化，以支持自身的各种功能，下面就一起来看一下RocksDB的各种基本操作。正文写流程：rocksdb写入时，直接以append方式写到WAL文件以及memtable
2021-09-22 15:45:48
1536
原创 漫谈RocksDB(二)基础讲解——仿佛兮若轻云之蔽月，飘飘兮若流风之回雪
前言古话说得好：“工欲善其事必先利其器”，要做好一件事情之前先把工具或者武器强化一下还是很值当的。所以本文将会把RocksDB的主要概念向大家讲解一下，方便后面具体内容的展开。本文所提到的概念大家仅需要了解和留个印象，如果不是很理解的话不需要纠结，后续的章节中会详细展开。正文RocksDB的概念纷繁复杂，我根据自己的理解将概念分为架构概念、存储概念以及操作概念，分门别类，帮助大家理解。下面就按照这个观其貌、识其物、辩其行的顺序进行讲解。架构概念嵌入式数据库首先RocksDB是一个嵌入
2021-09-15 15:28:08
2435
原创 漫谈RocksDB(一)简介——家有美女初长成，一朝成名天下知
前言最近写文章也有一段时间了，慢慢适应了节奏，经过前段时间的知识整理以及阅读反馈，笔者感觉在未来一段时间内可能会针对某些知识点发布专题。之前的模式可以帮助大家梳理很多知识点，增加大家的知识广度。但是凡事都有两面性，有利就会有弊，大家在了解了很多零散的知识点后，无法将知识点串联起来形成知识链，就无法很好的转化为生产力，所以基于此以后发文会将专题知识群以及散文知识点结合起来共同推进，希望能给大家带来实质帮助。接下来的一段时间内就先拿RocksDB来试试手，看看专题的效果如何。另外每个章节的标题会加一句应景
2021-09-14 16:44:47
880
原创 “不靠谱“的布隆过滤器是怎么成为大数据世界中的韦小宝的？
前言在计算机的世界中，数据计算和处理都是准确无误的，这在大多数人看来是理所当然的，确实也应该是这样的。但是在某些场景下完全的准确无误意味着很高的代价，不管是时间上还是空间上。于是大家都在考虑，能不能有一些方法能在很小的错误率的前提下，能大幅度提高效率减少资源消耗，而对于小概率误判的场景，能通过容错机制将窟窿补上。显然有，在这种背景下，咱们本文的主角，一个“不靠谱”的二愣子Bloom Filter（布隆过滤器）登场了。和偶像剧剧情不同，二愣子没有因为自身的“缺点”而两集就“领盒饭”了，反而通过自己
2021-08-05 09:33:49
289
原创 面试以及大数据处理中的常客BitMap到底是个什么样子的存在？
前言相信大家肯定也都遇到过，在很多的面试中，尤其是5年以下java工作经验的面试中，经常会看到如下的面试题： 在2.5亿个整数中找出不重复的整数，内存不足以容纳这2.5亿个整数。 给40亿个不重复的int型整数(32位)，乱序，然后再给一个数，如何快速判断这个数是否在那40亿个数当中？ 笔者也曾经遇到过，而且很长一段时间内都不知道这种题到底考点是什么，但是那时候年少无知，过了也就过了也没去仔细研究，直到后来开始研究大数据，接触到了今天文章的主角BitMap以及BitMap的衍生技术B
2021-08-02 09:49:50
353
原创 从枪械进化来聊聊大数据计算查询的两把高性能利刃
前言大家好，已经连续写了几篇elasticsearch相关的博文，今天给大家换个口味，写写大数据中数据处理以及数据查询的两大高性能利器。这篇文章我已经酝酿了好久，但是由于底层涉及到的知识点已经包含CPU的结构以及工作机制，所以用了很长时间去理解这里面的知识和逻辑，研究的越深感觉自己需要学的东西越多，痛并快乐着，终于啃下了这块硬骨头，于是总结下干货和大家分享分享。顺便友情提示：文章末尾有福利，文章末尾有福利，文章末尾有福利！！！正文题外话说多了，回归正题，再说这两种高性能利器之前，先说说这两利
2021-07-28 19:05:00
371
原创 数据在Elasticsearch的完整读写流程，掌握到这个程度面试以及生产环境差不多就够用了
前言看到标题以后大家有些人可能感觉有点小题大做，毕竟cilent端几行代码就能解决的问题，没必要兴师动众的来仔细讲一下。其实如果你仅仅想使用一下elasticsearch的功能，并不追求性能以及高可用性，那么这么想无可厚非。但是如果想在生产环境下使用elasticsearch，尤其是高并发高吞吐量的场景下，那么性能优化和高可用性就不可或缺了，要做到上面两点那么数据读写这两个操作的优化是必不可少的。古语有云：“工欲善其事，必先利其器”。想优化这两个操作，必须先了解这两个操作的原理。曾经有一个大神说
2021-07-22 10:08:14
1322
2
原创 众里寻TiDB千百度，蓦然回首，这些填坑记录还在灯火阑珊处
前言 俗话说得好，架构重构一时爽，一直重构一直爽，又到了架构重构的时节；俗话又说了，饱暖思X欲，在产品技术架构稳定运行了好久之后，又迎来了躁动的撩拨，重构之心蠢蠢欲动；俗话最后说了，技术有风险，重构需谨慎，但是遗憾的是，前两句俗话都听了，最后一句却没听，于是就走上了痛并快乐的填坑之旅，而这次的目标就是one stack to rule them all的NewSql数据库TiDB。余下的文章仅对这次技术调研中遇到的问题填过的坑记录下，帮助即将要或者将来要跳坑的各位兄弟姐妹们少走点弯路。...
2021-07-15 20:25:49
805
8
原创 俗话说别在一棵树上吊死，那为什么那么多NOSQL都喜欢在LSM树上吊死呢？
背景 当前的产品使用的数据交换协议是JSON，对于数据量大的客户来说，数据存储成本以及带宽的消耗已经成为整个产品的一大支出。在这种背景下，需要对数据交换协议进行优化，达到减少网络带宽以及存储消耗，如果能顺便提升下数据的序列化与反序列化的效率，那就更完美了。由于公司的产品是端到端的处理流程，且处理语言涉及到java，C以及JavaScript等，所以数据交换协议跨平台也是基础需求之一，在上述场景下对市面上相关的产品进行调研，基本上确认了Protocol Buffer作为潜在的候选目标，下面就会....
2021-07-05 22:57:57
517
2
原创 曾经人见人爱花见花开的zookeeper为啥突然不香了呢
zookeeper是何方神圣 zookeeper（简称zk），顾名思义，为动物园管理员的意思，在Hadoop生态体系这个动物园里，他确实管理着诸如Hadoop（大象），HBase（鲸鱼）等动物；甚至很多动物园之外的用户也在依赖他（如Storm，Kafka）。在分布式场景中，zk的应用非常广泛，如：数据发布/订阅、命名服务、配置中心、分布式锁、集群管理、选主与服务发现等等。下面通过一个故事来说明zookeeper到底是怎么发迹起来以及如何管理其他”动物“的zookeeper的封神之...
2021-06-23 18:57:57
1092
3
原创 端到端轻量化网络通信协议设计方案
背景 当前的产品端到端使用的数据交换协议是JSON，对于数据量大的客户来说，数据存储成本以及带宽的消耗已经成为整个产品的一大支出。在这种背景下，需要对数据交换协议进行优化，达到减少网络带宽以及存储消耗，提升数据传输效率方案 针对上述的背景，可以从两个方向来考虑问题：在当前协议类型不变的前提下进行转码或者数据格式转换，从而达到数据体积缩小的目的 另起炉灶，彻底改变当前JSON的传输方式，改用其他高效率的数据传输协议（如protocolbuffer） 下面...
2021-05-20 18:54:59
445
原创 HBase生产环境从入门到熟练使用，这一篇文章就够了
前言 HBase从发布开源到现在已经走过了十多个年头，一路风雨走来，版本与功能不断完善，版本也从0.9X，1.X直到现在的2.X。作为大数据生态圈的资深老兵，也积累了一众信徒，社区也相当活跃和完善，在某些场景下也是NOSQL数据库的首选。作为2013年入行大数据的老玩家，笔者从HBase0.92版本就开始接触和使用HBase。一路走来，见证过HBase的高光，也见过HBase的落寞，在百花齐放的大数据时代，在CAP原则的限制下，终究不会有大一统的数据库，只能在适合的场景使用合适的数据库，达...
2021-05-17 20:31:38
465
4
原创 HBase读写性能优化
HBase 读取性能优化HBase服务端优化读请求是否均衡如果数据吞吐量较大，且一次查询返回的数据量较大，则Rowkey 必须进行散列化处理，同时建表必须进行预分区处理。对于以get为主的查询场景，则将表进行hash预分区，均匀分布；如果以scan为主，则需要兼顾业务场景设计rowkey，在满足查询需求的前提下尽量对数据打散并进行负载均衡。BlockCache 设置是否合理一个通用的规则就是：如果 JVM 内存配置量小于 20G，BlockCache 策略选择 LRUBlockCache
2021-05-17 20:27:46
658
原创 HBase核心参数优化
背景 HBase作为一个使用方便的数据库，除了必要参数外，基本可以做到安装即可使用。但是随着数据量和并发量的增加，默认配置可能没办法很好地支撑数据和业务的处理，轻则效率低下，重则系统不可用，所以在这种情况下，需要进行性能优化，下面就从几个方面来说说HBase的几个核心参数的优化正文RegionRegion是HBase中的表是根据row key的值水平分割而成的。一个region包含表中所有row key位于region的起始键值和结束键值之间的行，所以Region是HBase中数据存...
2021-05-17 14:11:59
643
原创 一文详解HBase表设计原则和实现
前言 HBase作为一款历史悠久且具有代表性的NOSQL的数据库，其优点与缺点同样的明显，所以在确认了使用场景适合后下一步就是如何用好HBase了，不夸张的说，HBase使用的好与坏可能会造成天差地别，所以当你抱怨HBase如何的差劲不如XXX的时候，一定要先确认下自己是不是真的很好的使用了HBase，让其充分发挥出自己的亮点正文 想要用好HBase，首先要确认自己的业务场景是不是适合使用HBase，这个我在另外一篇博文中已经有所描述HBase的使用场景，大家可以参考...
2021-04-09 19:06:07
1694
原创 elasticsearch开启x-pack后使用curl访问集群样例-亲测可用
标准访问elasticsearch的方式kibana正常情况下，使用kibana访问elasticsearch是最佳的选择，界面化操作加上界面化的显示，能将elasticsearch管理的井井有条，所以有kibana的话直接选kibanacurl刚才说了正常情况，如果某些非正常情况，包含但不限于系统使用客户的共用集群，权限控制，在这些情况下，可能无法访问kibana，这个时候只能使用curl来进行访问了，标准的语句如下：curl -XGET 172.16.43.102:9200/_ca
2021-04-08 17:40:29
966
1
原创 一文详解HBase资源隔离相关的解决方案
背景 易扩展性，准确来说是易横向扩展性，一直是HBase引以为豪的优点之一，所以理论上HBase的集群规模可以做到很大，多个产品和业务的数据可以存在一个HBase中统一管理，节省运维资源和成本。 但是集群规模大了，数据量多了，处理负载变高了，加上各个产品和业务之间优先级不同，负载不同，对不同资源的敏感性也不同，使得简单粗暴的共用一个集群的效果并不是很好，面对这种业务场景早期的HBase版本并没有相关的解决方案，所以更多的就是各自为战，各自用各自的集群，这样不仅使得HBas...
2021-04-07 16:02:46
700
java经典基础编程题（包含代码，详细的注释以及思路的讲解）
2010-06-17
java 经典例题解析（包含答案，分析，代码以及详细的注释）
2009-04-01
shell编程从入门到精通
2009-03-31
高效C++中级编程教程
2009-01-01
Oracle,PLSQL课件详解，适合初学者，配备实例，全英文，在学习数据库之余亦可以提高英语水平
2008-12-31
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人