录信数软-CSDN博客

原创 Hadoop NameNode性能故障排查，超万亿数据库排查分享

随着国内互联网行业的发展，万亿规模的超大集群虽然已不像几年前那么凤毛麟角，但是也并不多见，尤其是涉及超万亿规模的超大集群性能故障排查的机会就更加稀少。而这次我所进行的超万亿规模的Hadoop NameNode性能故障排查也是在我创业几年以来所遇到的集群规模最大，耗时最长，排查工作量最大，头发掉的最多，最终都不得不求助于大牛的一次经历。因此在问题解决之后，我也第一时间将这次的整个排查过程记录下来进行总结，希望能给看到的各位同学有所帮助。

2021-02-23 17:14:05 2079 5

原创 PostgresSQL分区表不能统计下推的排查

在之前的分享中我们提到过，LXDB本质上是基于PGSQL的一个拓展，相当于更换了PG的底层数据结构。本次的实践就是基于对PG分区表无法进行统计下推的问题进行的排查和解决。下面，开始我们本次的实践分享：一、问题背景近日，出于客户提出的需求，我们在LXDB中加入了分区功能。但是在功能上线之后，我们在测试拓展分区表的时候发现count(＊)与group by这种分组统计并没有将计算下推到LXDB层去计算,而是将所有数据返回给PG层计算。由于数据格式的不同，在LXDB层的统计与将数据抛给PG层进行统计，两者性

2021-11-03 15:42:41 250

原创 2021中国数据库技术大会圆满落幕，录信数软携新产品LXDB亮相大会

2021年10月18日，录信数软创始人兼CTO母延年在2021中国数据库技术大会上分享了“PostgreSQL在OLAP场景实战演练，支撑单节点百亿规模多维检索与统计”的主题演讲，这也是录信数软第二次参加DTCC数据库大会，同时录信数软重点打造的新一代轻量级检索分析型数据库LXDB首次公开亮相技术论坛。下面，我们一起回顾下本次分享内容。本次DTCC大会以“数造未来”为主题，这也是录信数软第二次参加DTCC中国数据库技术大会，在2020年，我们带来了万亿实时数仓LSQL产品实践的主题分享，而在今年的大会中

2021-10-27 14:12:27 591

原创摊牌了，这就是一篇有啥说啥的招聘贴

这是一篇非常平实的招聘贴：因为我们会细致的告知你公司的所有情况，不会有任何套路和隐瞒。我们正在招聘研发总监、销售工程师、数据库研发工程师、运维工程师如果你有意向加入我们，请联系我们。一、我们是一家什么样的公司首先很诚实的告诉各位，我们是一家创业公司，但是我们不画饼，不996，不PUA，不强制团建。我们成立于2018年，目前公司位于南京市江宁区，从事于大数据基础软件（数据库）开发。下面从产品、公司情况、公司氛围/管理、福利待遇和地理位置五个方面介绍一下我们。1.产品情况我们目前有两款数据库产品

2021-08-31 13:59:40 175

原创面对不同数据库类型，如何进行数据库选型

数据库的选型一直是一个困扰着采购人员和DBA的问题，既需要立足于当下，提供高可用的服务，又需要着眼于未来，给予足够的扩展空间以适应项目的发展壮大。针对这个问题，本文尝试着从数据库类型的角度谈一谈数据库选型的最佳实践。一、引言如前所述，为项目进行数据库选型着实是一件头疼的事，不同的角色在选型时可能会有不同的考量。采购人员会更关注于成本及供应商资质，而DBA则会更多考虑数据库本身的性能、稳定性、扩展性等。不可否认的是，很多情况下我们可能会遇到下面这种情境。如果你曾经使用过某类数据库，你可能会说“我只会选择

2021-08-23 14:27:07 850

原创论文领读：Presto: SQL on Everything

本篇论文是Facebook 2019年发表介绍Presto的综述类论文，本篇论文从Presto的使用示例、架构、系统设计等几个方面系统的介绍了Presto的内核和实现原理，对于通识性的了解Presto有一定帮助。注：本篇论文中所介绍的Presto版本是0.211版本，当时Presto还没分裂出PrestoDB和PrestoSQL。一、Presto介绍Presto作为一个分布式查询引擎，于2013年开始就已经在Facebook的生产环境中使用。并且如今已经在Uber、Netflix、Airbnb、Blo

2021-08-11 14:18:33 505

原创 Spark SQL踩坑经验总结及调优分享

写在之前：本篇文章写就时间较早，因此本文所讨论的Spark SQL非最新版本，后续更新版本可能有部分修复和更新。一、Spark内存泄露1.高并发情况下的内存泄露的具体表现首先得很遗憾的告诉各位，Spark在设计之初的架构就不是为了高并发请求而生的，我们尝试在网络条件不好的集群下，进行100并发的查询，在压测3天后发现了内存泄露。在进行大量小SQL的压测过程中发现，有大量的activejob在spark ui上一直处于pending状态，且永远不结束，如下图所示：并且发现driver内存爆满：

2021-08-03 10:29:42 589

原创什么是OLAP？主流八大开源OLAP技术架构对比

随着大数据技术在各行各业的深入应用，对于海量数据的分析需求也愈加凸显，OLAP技术也逐渐走入人们的视野。本文将围绕常见的开源OLAP引擎展开，介绍什么是OLAP以及OLAP的常见操作和分类，并对目前主流的开源OLAP引擎进行对比和特点的总结。一、什么是OLAPOLAP（On-line Analytical Processing，联机分析处理）是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的OLTP（On-line Transaction Processing，联机事务

2021-07-30 15:40:52 10192

原创 B-Tree、B+Tree以及B-link Tree

B+Tree自从发明以来就成为了各种数据库引擎的首选，虽然近些年来LSM-Tree结构的数据库如雨后春笋般涌现，但B+Tree由于其优异性能以及各场景中均衡的性能表现，依然是各数据库的首选项。但B+ Tree也并非毫无缺点，作为一种平衡多叉树结构，其优势是在数据量大时也能保持较低的树高，因而其无论查询或者是更新其代价均较低。但树的一大弊端是在更新时会触发结构调整，这种结构调整最长可能从叶子节点延伸至根节点，而这种树结构的调整会阻塞并发的读写操作，进而导致性能衰退。因此，如何优化B+ Tree在该场景下的并

2021-07-02 10:38:48 447

原创基于Lucene实现万亿级多维检索与实时分析

5月29日，录信数软技术总监郑其华在QCon全球软件开发者大会分享了“基于Lucene实现万亿级多维检索与实时分析”的主题演讲，现场座无虚席，活动在浓烈的技术讨论氛围中圆满结束。下面，我们将分享演讲全文及课件。一、演讲全文1.万亿挑战之一：数据存储第一个关于数据存储。平常我们保存数据很简单，往硬盘里面写就行了。海量数据就没那么简单，会面临很多问题。比如成本问题。是使用SSD固态硬盘还是机械磁盘，是使用100块大磁盘，还是使用1万块小磁盘，在成本上都会造成巨大的差异。其次，数据的安全性也是一个

2021-06-02 15:27:22 467

原创活动预告‖基于Lucene实现万亿级多维检索与实时分析的实践之路

—QCon全球软件开发大会（北京）—Lucene是业界最常用的搜素引擎，我们所熟知的solr和elasticsearch都是基于Lucene所实现。但是随着数据体量的不断增加，当处于万亿数据的场景之下，所有的常规操作都会面临海量数据带来的巨大压力，如何在保留Lucene高效的全文检索能力的情况下应对万亿数据的挑战，同时打破大数据技术栈各组件功能单一，适配复杂的问题。针对于此，我们将会在本次QCon全球软件开发大会上分享我们这些年在实现基于Lucene的万亿数据挑战中所遇到的问题和解...

2021-05-27 10:59:35 150

原创 Hadoop是否会被Spark取代？Hadoop生态组件原理解析

Hadoop和Spark都是目前主流的大数据框架，但是随着Spark在速度和易用性方面表现出的优势，一些国内外专家逐渐推崇Spark技术，并且认为Spark才是大数据的未来。本文将会浅析Hadoop生态的发展历程及其中部分组件的技术原理，最终就Hadoop是否会被Spark取代给出结论。一、Hadoop的核心组件在对Hadoop核心组件进行介绍之前，我们需要先了解Hadoop解决了什么问题。Hadoop主要就是解决了大数据（大到一台计算机无法进行存储，一台计算机无法在要求的时间内进行处理..

2021-04-19 15:30:43 705

原创 NewSQL是伪命题还是真突破？NewSQL系统综述

本文选自Andrew Pavlo（卡内基梅隆大学计算机科学系副教授）和Matthew Aslett（451研究所副总裁）在2016年所发表的论文What’s Really New with NewSQL。以下内容为伴鱼技术团队翻译，录信数软进行了二次整理和编辑。摘要近年来出现了一种称为NewSQL的新型数据库管理系统（DBMS），它们号称有能力扩展现代在线交易处理（on-line transaction processing,OLTP）系统的工作负载，这对于以前的系统来说是无法做到的。鉴于.

2021-04-08 17:36:34 454

原创 ClickHouse的入门、使用和优化

ClickHouse是俄罗斯的重要网络服务门户之一Yandex所开源的一套针对数据仓库场景的多维数据存储与检索工具，一个用于联机分析(OLAP)的列式数据库管理系统(DBMS),它通过针对性的设计力图解决海量多维度数据的查询性能问题。下面，enjoy：一、数据库的行存与列存在传统的行式数据库系统中，数据按顺序存储：处于同一行中的数据总是被物理的存储在一起，常见的行式数据库系统有：MySQL、Postgres和MS SQL Server。在列式数据库系统中，来自不同列的值被单独存储，来自同一列的数

2021-03-26 15:25:53 1174

原创运维进阶，PXE环境下kickstart无人值守批量装机教学

近期在客户现场部署环境时遇到了一个问题，客户有较多的服务器没有安装系统，如果采用传统的光驱部署安装的方式太过繁琐耗时，因此就采用了PXE环境下kickstart批量装机的方式进行。通过PXE环境下kickstart批量装机的方式，在1小时之内部署了超过30台服务器系统，相比于原先的光驱安装节省了接近2个小时，大大提升了系统部署效率。下面我将从相关知识的普及、效率对比和安装教学三个方面分享如何实现PXE环境下kickstart批量装机。下面，enjoy：一、相关知识的梳理1. 批量装机软件介绍：操作系

2021-03-11 16:47:11 350 1

原创 Hadoop 3.2.1‖联邦模式下突破router的性能瓶颈的实践

上期回顾：在第一期（点击可参阅详情）中，我们通过性能故障排查解决了Hadoop2.6.0版本的瓶颈问题；在第二期（点击可参阅详情）中，我们将集群由Hadoop2.6.0版本升级到Hadoop3.2.1版本，且启用联邦模式，解决了Hadoop的第二次瓶颈；本次，我们将分享一下在联邦模式下如何解决router延迟较大的问题。下面，enjoy：一、基于非联邦和联邦模式的测试在成功将Hadoop2.6.0版本升级到Hadoop3.2.1版本，且启用联邦模式后，当前集群等于有了两个Namenode，不仅总

2021-03-02 11:18:57 529 1

原创数据库‖上千节点Hadoop集群升级过程分享

在上一次我进行了超万亿规模的Hadoop NameNode问题的排查，通过为时四天的努力，终于解决了Hadoop2.6.0版本的瓶颈问题，但是生活往往就是墨菲定律，你所极力避免的那些最坏的可能也许终将会发生。为了防止遇到NameNode的第二次瓶颈，我决定将当前集群由Hadoop2.6.0版本升级到Hadoop3.2.1版本，且启用联邦模式。但是在升级之后，我们还是遇到了很多意向不到的问题，虽然最终经过一系列的排查还是解决了这些问题，但是我认为这次集群的升级经验能够帮助一些同学少走弯路。下面，enjoy

2021-02-25 15:29:34 438 2

weixin_52672149的博客