文档章节

五个选择LunarBase的理由

费大虫
 费大虫
发布于 2017/06/14 15:53
字数 2757
阅读 51
收藏 0

导引

当我们视图用一款数据库来建立某种应用的时候,我们会以什么为依据来选择?存储的性能,建模的能力,查询的速度,部署环境的复杂度?毕竟谁都希望多快好省的完成工作。LunarBase能给你什么呢?我们以一个LBS(Location based service)的典型应用来看看实际的生产环境吧。

 

LBS满足这样一个典型的场景:下班前,我饿了,打开手机,查一下附近有什么好吃的。下班了,周末,查一下附近的电影院或者别的啥,让我可以爽爽的..........那就搜索附近呗,2000米以内的,数据库有索引,每个商家和我算一下距离,然后把附近的过滤出来,按距离排个序。但是北京的饭馆,娱乐场所太多了,下班高峰期每个人都在查,多少台服务器才够呢?。

 

 

我当然希望我的应用服务越多的人越好,高峰期毫秒响应,投资人追着投,嚯嚯嚯,想的好美,但是,现实是,这样的应用,应该怎么建立才好呢,我需要投入多少人力来完成?

为了满足类似的查询交互,你的研发需要完成这样几件大事:

1. 设计维护基本的数据结构(无论是sql还是no sql数据库),比如Mysql,店家,服务,我的位置等等,都放在关联的表格里面;

2. 建立索引,用Mysql的列索引也好,用第三方的Lucene也好,索引需要单独的维护,和数据库的同步也是一大问题;

3. 并且用缓存工具把热点商户,热点服务,热点地区等等缓存起来,这样高峰期的大多数热点查询就在内存中完成了,IO的压力减少很多;

4. 于是就有了在多个软件框架的基础上数据的冷热交换,击穿,数据一致性,更新通知等等的研发和维护;

5. 有了Spark,presto,impela等流式分析的工具,在集群上做大规模的关联分析是很快,但并不保证数据实时装载,也就是说瓶颈是搜索的效率;

 

看到这里,你如果维护过这样的一个应用,就能深刻的理解到,仅仅是单机,整体的部署环境和依赖环境就已经非常的复杂。你需要你的研发做很多的东西,配置一堆软件框架,写代码把他们串起来,光是一个缓存和底层数据库的一致性,更新通知等事情,你就需要再引入更多的框架来解决,复杂度又提高了一截。

 

环境越复杂,成本就越高,各方面的成本。

 

一. LunarBase

LunarBase是一个数据库引擎,在github可以下载,但还没完全开源,专门为海量数据的存储和大吞吐量的查询设计的,支持点查询,范围查询,多表JOIN等等,并且内置了全文搜索,当然一键多值木有压力。

 

同时,内部集成了大内存的管理引擎,啥意思嘞?就是说你在部署应用的时候,不用另外再部署一套第三方的缓存系统了,LunarBase都做好了,数据一致性,冷热交换,更新通知啥啥的,都不需要应用来担心,管理员只需要把内存开大大就行,我开了2G的物理内存,无穷的虚拟内存(这很酷,不是操作系统默认的那个,而是给LunarBase指定的某个设备目录,按文档,显然啊,SSD设备做虚拟内存更好),全北京的小店坐标都放得下了,还缓存了一些些的热门评论。冷门地址,冷门评论,自动交换出去啦,这就是内置大内存缓存的好处。待会儿我们看看这么配置。

 

当然它不是内存数据库,掉电了不怕,数据优先都刷到磁盘了。不同于HBase建在内存的LMS树,满256M才刷一次磁盘存起来。LunarBase优先批量进磁盘,然后把数据索引在块设备文件系统内,为查询做准备。

 

 

二. 5个问题的简化解决

回到导引里面的5个问题,第一个,大家都免不了要设计表格和数据结构,我倒不觉得用No sql的方案会简化多少,只是一个研发人员的使用习惯问题。而且结构永远是王道。这是见仁见智的。

 

对于第2个问题,LunarBase根据数据类型,会建立不同的索引,对于范围查询,主要由里面的LunarMax实时计算模块支持,只需要在配置文件中,把实时模式打开就行:

rt_mode = on

 

然后指定LunarBase为每个列索引最多使用多少内存:

rt_virtual_mem_enabled = on

rt_vm_swap = /home/DBTest/Swap

rt_max_memory = 28

 

从上到下,首先打开虚拟内存,然后指定虚存使用的swap空间,用户的服务器环境可能会运行多种服务,每个都在争抢资源,那么LunarBase的这个设计就很贴心,用户可以通过最后的这个rt_max_memory,告诉LunarBase,对每个需要实时查询的列,最多使用多少物理内存,比如256M的物理内存,这就限制住了LunarBase自身的内存消耗。需要更多,就使用交换空间的,通过指定一块(固态)硬盘空间来作为大的虚拟内存使用,比如100GB,一般都是够用了。

 

这一点和操作系统的内存管理一样,LunarBase使用自己的虚拟内存管理系统,这块空间是独占的,不和操作系统争抢。

 

所以,第2个问题对于LunarBase来讲,只是需要设置几个参数就可以,不需要再维护一份索引,也不需要再引入一套数据同步的程序。 后面的性能测试比较可以看到,LunarBase的范围查询性能和Solr差不多。但使用上是简单多了。

 

第3个问题,缓存。缓存的工具有很多,都是独立于底层数据库的,通常这由应用开发端来负责研发,主要的目的就是解决热点数据缓存,一致性,击穿,更新等等。有的缓存软件能够过一段时间就刷一下硬盘,把缓存的数据保存下来,但这不解决以上问题,所以通常使用场景限于缓存本身。

 

在LunarBase里面,如果有大量的热点数据,只需要调大缓存的记录数就行:

cache_records_in_memory = 21

这表明会在内存里面缓存1<<21=200万条数据。在LunarBase的配置文件里面,所有的数字都是偏移值,都需要管理员自己算一下具体值是多少,这一点不大方便,强迫管理员自己算一下,不要设置错误,习惯了就好。

 

 

这样整合的缓存系统,也就解决了第4个问题,应用层的开发,不再担心一致性问题,新的数据也自动装载到缓存,长时间不用的自动淘汰,自然也不存在击穿的问题。

 

对于第5个问题,Spark和Presto这些流式计算框架能够处理数据的实时计算,但数据源不能保证实时装载的话,一样效率不理想。所以,针对实时的要求,把LunarBase有配套的Presto插件,连接了实时分析和实时查询引擎LunarMax,保障了整体的实时性。关于LunarMax,第四节会有介绍,更多的内容参考附录文献,这里不多写了。

 

三. JOIN,查询,更新

 

非关系型的数据库一般原生不支持JOIN,有社区开发了插件,也有借助Presto等查询引擎进行多数据源JOIN的,需要分布到多台机器上进行流式的计算。原生支持JOIN的操作是相对比较耗时的,但也是必须的,要不几张表联查怎么弄?要想在本地完成这样的操作,而不依赖于集群,LunarBase提供了物化视图的方案。

 

例如LBS应用要列出附近的店,按距离,再列出附近热门的餐馆的热门菜(大于85分的菜),这很重要,先找出附近的店,然后取出所有店的所有菜,过滤一遍,只拿出85分以上的返回给客户。这太慢,附近要有100家店,那就是一次查店,加上100次取菜,查询太多了,效率不会高。

 

或许你可以不用这样建模,而是以菜(服务)为主,把每个菜的经纬度作为菜的属性加到service表里面,这样就只查范围和得分score取一下交集AND就OK了,不过service表会有非常大的冗余,一家店的100个菜和你是一个距离的,磁盘便宜比较便宜,这个冗余获得的性能提升也值得。

 

上面的做法就是materialized view,用两张表的数据抽取出来,建立一张冗余表,方便查询。一般关系型数据库软件都提供后台的独立线程来做数据更新同步的事情,不需要用户担心的。例如一个店的地址变了,该店的view里面100个菜的地址需要单独的线程来慢慢更新,最坏的情况,这100个菜都没有存放在一个磁盘块里面,这意味着100次的磁盘访问,这会有点延迟的,如果是一家大店,有2000个商品呢?这类的应用,可以延迟,最终是一致的。

 

用几台集群运行spark或者presto是另一个方案,这个方案能够在最新的数据集上面获得JOIN的结果,但会多消耗机器的资源,如果你的应用在乎即时的更新感知,这种实时JOIN的方案会比较适合。LunarBase配套了Presto的实时查询连接器,把自己的实时查询引擎和Presto的实时分析引擎链接,Presto支持标准sql的分析,在这个场景下,LunarBase则是一个搜索引擎,提供了查询的接口,大吞吐量的提供数据源。

 

<未完待续> 

本文转载自:https://mp.weixin.qq.com/s/M9IcnN2nWeWJ1hJleFrUfw

费大虫

费大虫

粉丝 0
博文 2
码字总数 0
作品 1
朝阳
私信 提问
数据库引擎--LunarBase

LunarBase是专门为海量数据的存储和大吞吐量的查询设计的.用C语言和java开发而成,采用了数据库引擎和搜索引擎的融合设计,这无疑能够大大的简化生产环境,因为不需要为了不同的数据类型专门...

费大虫
2017/06/14
431
0
2018-11-09-今日得到-《电车难题》

今天分享的主题来自得到的每天听本书系列之《电车难题》 关于作者 托马斯·卡斯卡特,毕业于哈佛大学哲学专业,此后进入芝加哥大学研究神学。他的履历丰富,职业多变,从大学教授到临终关怀,...

韬声依旧在路上
2018/11/10
0
0
丢弃 MySQL 的 5 个理由

MySQL仍然是最流行的开源数据库,但因为更好选择的出现在过去几年中它的粉丝不断流失。让我们来看一下换掉Mysql的五个动机。 早在2008年,MySQL还在迅速普及的时候,SUN用十亿美元收购了MyS...

oschina
2013/07/11
2.3K
2
Python--基础练习

1. 在Linux电脑上安装python,ipython,pycharm专业版本软件; 2. 在Windows电脑上安装python3版本,并配置环境变量,确保Dos环境下运行脚本; 3. Linux下有多少种运行python的不同方法,并分析...

無緣
2017/12/27
0
0
外刊IT评论:为什么你要做一名程序员?

本文是从 Why why why why why are you a developer? 这篇文章翻译而来。 做一个程序员很忙,你需要去写代码,去创建meme,去进行测试,以及随时关注最新最热的gem/开源软件技术。最近,我一...

红薯
2011/07/14
2.2K
16

没有更多内容

加载失败,请刷新页面

加载更多

OSChina 周日乱弹 —— 我,小小编辑,食人族酋长

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @宇辰OSC :分享娃娃的单曲《飘洋过海来看你》: #今日歌曲推荐# 《飘洋过海来看你》- 娃娃 手机党少年们想听歌,请使劲儿戳(这里) @宇辰OSC...

小小编辑
今天
699
10
MongoDB系列-- SpringBoot 中对 MongoDB 的 基本操作

SpringBoot 中对 MongoDB 的 基本操作 Database 库的创建 首先 在MongoDB 操作客户端 Robo 3T 中 创建数据库: 增加用户User: 创建 Collections 集合(类似mysql 中的 表): 后面我们大部分都...

TcWong
今天
39
0
spring cloud

一、从面试题入手 1.1、什么事微服务 1.2、微服务之间如何独立通讯的 1.3、springCloud和Dubbo有哪些区别 1.通信机制:DUbbo基于RPC远程过程调用;微服务cloud基于http restFUL API 1.4、spr...

榴莲黑芝麻糊
今天
25
0
Executor线程池原理与源码解读

线程池为线程生命周期的开销和资源不足问题提供了解决方 案。通过对多个任务重用线程,线程创建的开销被分摊到了多个任务上。 线程实现方式 Thread、Runnable、Callable //实现Runnable接口的...

小强的进阶之路
昨天
74
0
maven 环境隔离

解决问题 即 在 resource 文件夹下面 ,新增对应的资源配置文件夹,对应 开发,测试,生产的不同的配置内容 <resources> <resource> <directory>src/main/resources.${deplo......

之渊
昨天
73
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部