数据库核心技术学习探究.docx

1引言在进入研究生学习之前，我曾经和小伙伴们共同开发了一款游戏——这款游戏有非常高的实时性，基本要与服务器长连接并不断交换数据。然而，这些实时交换的数据并不是数据库想去记录的——他们是动态数据，可能并不需要保存在数据库里，甚至数据库不需要去知道这些东西。可能在游戏完成后，我仅仅需要保存他的成绩进入数据库即可。但是，我可能又需要了解这些所谓的脏数据，毕竟他可能记载了大部分玩家的行为，作为我来说这是优化游戏，让游戏变得更加好玩的关键点。说到底，就是高并发，高实时性的脏数据。最初，在我构建的游戏服务器grandserver中选择了mysql作为记录所有数据的服务器，包括静态数据和动态数据。起初，一切一帆风顺，所有操作在封装的协议中顺利交互。但是到了游戏制作，也就是数据频繁交互的阶段，我总是比预想中更晚收到我想要的指令，或者说，两者交互时间非常晚。在查询mysql记录时发现，我总是不停的在改一整张表。效率跟不上后，我放弃了mysql，在仔细甄选后，选择了nosql技术中的redis作为数据库缓存服务器。随后我的代码被封装了成了图1-1：在使用该类调用脏数据操作后，通过lua层的简单交互，终于让数据变得正常。但是当时我在做完解决方案后留下了几个问题，还未解决即准备考研。问题如下：nosql盛行的时代，sql存在的意义。nosql甚至可以在增加一个sql语句解释器的情况下完全变为sql数据库，那sql的存在意义到底在哪里。经过将近半年的学习，在了解了双方内部的操作与区别后，我个人认为双方各有所长。本文以sqlite与redis中的数据结构的异同点为出发点，着重分析sql和nosql架构中的区别以及他们不可替代的地方。#pragma once#include stringextern C{#include hiredis.h}using namespace std;class mythRedisKey{public:inttoint();string tostring();mythRedisKey(redisReply* reply);~mythRedisKey();void release();private:redisReply* _reply;//void release();};图1-12内部数据结构2.1 string VS simple dynamic string(sds)在大多数开源关系数据库中并没有对最基本的string进行优化，很多数据库例如sqlite甚至直接使用了const char*来作为基本数据库的string结构作为储存结构。故很多时候在不同系统上更加依赖类似strlen的处理效率。而在Redis没有直接使用 C 语言传统字符串表示（以空字符结尾的字符数组，以下简称 C 字符串），而是自己构建了一种名为简单动态字符串（simple dynamic string，以下简称SDS）的数据结构，并将 SDS 用作Redis的默认字符串表示。在Redis里面，C 字符串只会作为字符串字面量（string literal）用在一些无须对字符串值进行修改的地方，比如打印日志：redisLog(REDIS_WARNING,Redis is now ready to exit, bye bye...);当Redis需要的不仅仅是一个字符串字面量，而是一个可以被修改的字符串值时，Redis就会使用 SDS 来表示字符串值，比如在Redis的数据库里面，包含字符串值的键值对在底层都是由 SDS 实现的。每个sds.h/sdshdr结构表示一个 SDS 值，如图2-1：// 记录buf数组中已使用字节的数量structsdshdr{intlen;// 等于SDS所保存字符串的长度int free;// 记录buf数组中未使用字节的数量char buf[];// 字节数组，用于保存字符串};图2-1如图2-2展示了一个 SDS 示例：图2-2free= 0，表示这个 SDS 没有分配任何未使用空间。len= 5，表示这个 SDS 保存了一个五字节长的字符串。buf属性是一个char类型的数组，也就是普通的c语言string类型数组。他的前五个字节分别保存了R,e,d,i,s五个字符，而最后一个字节则保存了空字符\0。 SDS 遵循 C 字符串以空字符结尾的惯例，保存空字符的1字节空间不计算在SDS 的len属性里面，并且为空字符分配额外的1字节空间，以及添加空字符到字符串末尾等操作，都是由 SDS 函数自动完成的，所以这个空字符对于 SDS 的使用者来说是完全透明的。所以遵循空字符结尾这一惯例的好处是，SDS 可以直接重用一部分 C 字符串函数库里面的函数。这么做的好处非常显而易见，和 C字符串不同，因为 SDS 在len属性中记录了