精华内容
下载资源
问答
  •  sqlite采用的是变长纪录存储,当你从Sqlite删除数据后,未使用的磁盘空间被添加到一个内在的”空闲列表”中用于存储你下次插入的数据,用于提高效 率,磁盘空间并没有丢失,但也不向操作系统返回磁盘空间,这就...

           讲解开始前,先说明一下这个问题的原因:

                    sqlite采用的是变长纪录存储,当你从Sqlite删除数据后,未使用的磁盘空间被添加到一个内在的”空闲列表”中用于存储你下次插入的数据,用于提高效    率,磁盘空间并没有丢失,但也不向操作系统返回磁盘空间,这就导致删除数据乃至清空整个数据库后,数据文件大小还是没有任何变化,还是很大   

       以上解释是引用第三方的,我这里主要说的是详细操作(windows平台),不讲理论。

       在不使用第三方工具(例如:Navicat Premium)的情况下,你得下载sqlite的原命令行工具(sqlite-tools

     我下的是(sqlite-tools-win32-x86-3190000),下完找个位置解压,直接复制里面的sqlite3.exe 出来用就

     可以了,然后把你要压缩的数据库拷贝到和sqlite3.exe文件的同级目录下:

       1.打开 sqlite3.exe

       2.在弹出的命令行界面内输入: .open  数据库名.db(你的数据库)  后Enter下

       3.接着输入 vacuum;  记得不要漏了后面的 “;”  再Enter下

     现在看下你的数据库是不是小了很多,就这么简单。

     

     如果你有 Navicat Premium 类似这种查看数据库的工具的话,你可以在工具里打开你的数据库:

     1.右击数据库名(不是表名,不是表名,不是表名

     2.选择命令列界面(就是一个命令界面)

     3.接着输入 vacuum;  记得不要漏了后面的 “;”  再Enter下

     大功告成!!!!!!

     

     其中在创建表(仅在创建表)的时候,就可以设置一个与此相关的属性 :PRAGMA auto_vacuum = 0 | 1; (0 默认属性,关闭。1打开自动压缩)

    你可以在上述的命令行界面输入 PRAGMA auto_vacuum 回车后就可以看到创建表时设置的这个值了。

      附上相关的第三方额外知识

      

     

     

     

      

       

    展开全文
  • 数据库压缩技术探索

    千次阅读 2017-06-08 19:48:49
    数据库、高性能计算、分布式、系统架构上都深有造诣。 责编:仲培艺(zhongpy@csdn.net) 本文为《程序员》原创文章,未经允许不得转载,更多精彩文章请订阅《程序员》 作为数据库,在系统资源(CPU、内存、...

    作者:雷鹏,Terark核心技术发明人。曾就职奇虎360,负责搜索引擎核心研发;曾就职Yahoo!北研所负责搜索广告、广告交易(AdExchange)等项目。在数据库、高性能计算、分布式、系统架构上都深有造诣。
    责编:仲培艺(zhongpy@csdn.net
    本文为《程序员》原创文章,未经允许不得转载,更多精彩文章请订阅《程序员》

    作为数据库,在系统资源(CPU、内存、SSD、磁盘等)一定的前提下,我们希望:

    • 存储的数据更多:采用压缩,这个世界上有各种各样的压缩算法;
    • 访问的速度更快:更快的压缩(写)/解压(读)算法、更大的缓存。

    几乎所有压缩算法都严重依赖上下文:

    • 位置相邻的数据,一般情况下相关性更高,内在冗余度更大;
    • 上下文越大,压缩率的上限越大(有极限值)。

    块压缩

    传统数据库中的块压缩技术

    对于普通的以数据块/文件为单位的压缩,传统的(流式)数据压缩算法工作得不错,时间长了,大家也都习惯了这种数据压缩的模式。基于这种模式的数据压缩算法层出不穷,不断有新的算法实现。包括使用最广泛的gzip、bzip2、Google的Snappy、新秀Zstd等。

    • gzip几乎在在所有平台上都有支持,并且也已经成为一个行业标准,压缩率、压缩速度、解压速度都比较均衡;
    • bzip2是基于BWT变换的一种压缩,本质是上对输入分块,每个块单独压缩,优点是压缩率很高,但压缩和解压速度都比较慢;
    • Snappy是Google出品,优点是压缩和解压都很快,缺点是压缩率比较低,适用于对压缩率要求不高的实时压缩场景;
    • LZ4是Snappy一个强有力的竞争对手,速度比Snappy更快,特别是解压速度;
    • Zstd是一个压缩新秀,压缩率比LZ4和Snappy都高不少,压缩和解压速度略低;相比gzip,压缩率不相上下,但压缩/解压速度要高很多。

    对于数据库,在计算机世界的太古代,为I/O优化的Btree一直是不可撼动的,为磁盘优化的Btree block/page size比较大,正好让传统数据压缩算法能得到较大的上下文,于是,基于block/page的压缩也就自然而然地应用到了各种数据库中。在这个蛮荒时代,内存的性能、容量与磁盘的性能、容量泾渭分明,各种应用对性能的需求也比较小,大家都相安无事。

    现在,我们有了SSD、PCIe SSD、3D XPoint等,内存也越来越大,块压缩的缺点也日益突出:

    • 块选小了,压缩率不够;块选大了,性能没法忍;
    • 更致命的是,块压缩节省的只是更大更便宜的磁盘、SSD;
    • 更贵更小的内存不但没有节省,反而更浪费了(双缓存问题)。

    于是,对于很多实时性要求较高的应用,只能关闭压缩。

    块压缩的原理

    使用通用压缩技术(Snappy、LZ4、zip、bzip2、Zstd等),按块/页(block/page)进行压缩(块尺寸通常是4KB~32KB,以压缩率著称的TokuDB块尺寸是2MB~4MB),这个块是逻辑块,而不是内存分页、块设备概念中的那种物理块。

    启用压缩时,随之而来的是访问速度下降,这是因为:

    • 写入时,很多条记录被打包在一起压缩成一个个的块,增大块尺寸,压缩算法可以获得更大的上下文,从而提高压缩率;相反地,减小块尺寸,会降低压缩率。
    • 读取时,即便是读取很短的数据,也需要先把整个块解压,再去读取解压后的数据。这样,块尺寸越大,同一个块内包含的记录数目越多。为读取一条数据,所做的不必要解压就也就越多,性能也就越差。相反地,块尺寸越小,性能也就越好。

    一旦启用压缩,为了缓解以上问题,传统数据库一般都需要比较大的专用缓存,用来缓存解压后的数据,这样可以大幅提高热数据的访问性能,但又引起了双缓存的空间占用问题:一是操作系统缓存中的压缩数据;二是专用缓存(例如RocksDB中的DBCache)中解压后的数据。还有一个同样很严重的问题:专用缓存终归是缓存,当缓存未命中时,仍需要解压整个块,这就是慢Query问题的一个主要来源(慢Query的另一个主要来源是在操作系统缓存未命中时)。

    这些都导致现有传统数据库在访问速度和空间占用上是一个此消彼长、无法彻底解决的问题,只能采取一些折衷。

    RocksDB 的块压缩

    以RocksDB为例,RocksDB中的BlockBasedTable就是一个块压缩的SSTable,使用块压缩,索引只定位到块,块的尺寸在dboption里设定,一个块中包含多条(key,value)数据,例如M条,这样索引的尺寸就减小到了1/M:

    • M越大,索引的尺寸越小;
    • M越大,Block的尺寸越大,压缩算法(gzip、Snappy等)可以获得的上下文也越大,压缩率也就越高。

    创建BlockBasedTable时,Key Value被逐条填入buffer,当buffer尺寸达到预定大小(块尺寸,当然,一般buffer尺寸不会精确地刚好等于预设的块尺寸),就将buffer压缩并写入BlockBasedTable文件,并记录文件偏移和buffer中的第一个Key(创建index要用),如果单条数据太大,比预设的块尺寸还大,这条数据就单独占一个块(单条数据不管多大也不会分割成多个块)。所有Key Value写完以后,根据之前记录的每个块的起始Key和文件偏移,创建一个索引。所以在BlockBasedTable文件中,数据在前,索引在后,文件末尾包含元信息(作用相当于常用的FileHeader,只是位置在文件末尾,所以叫footer)。

    搜索时,先使用searchkey找到searchkey所在的block,然后到DB Cache中搜索这个块,找到后就进一步在块中搜索searchkey,如果找不到,就从磁盘/SSD读取这个块,解压后放入DB Cache。RocksDB中的DB Cache有多种实现,常用的包括LRU Cache,另外还有Clock Cache、Counting Cache(用来统计Cache命中率等),还有其他一些特殊的Cache。

    一般情况下,操作系统会有文件缓存,所以同一份数据可能既在DB Cache中(解压后的数据),又在操作系统Cache中(压缩的数据)。这样会造成内存浪费,所以RocksDB提供了一个折衷:在dboption中设置DIRECT_IO选项,绕过操作系统Cache,这样就只有DB Cache,可以节省一部分内存,但在一定程度上会降低性能。

    传统非主流压缩:FM-Index

    FM-Index的全名是Full Text Matching Index,属于Succinct Data Structure家族,对数据有一定的压缩能力,并且可以直接在压缩的数据上执行搜索和访问。

    FM-Index的功能非常丰富,历史也已经相当悠久,不算是一种新技术,在一些特殊场景下也已经得到了广泛应用,但是因为各种原因,一直不温不火。最近几年,FM-Index开始有些活跃,首先是GitHub上有个大牛实现了全套Succinct算法,其中包括FM-Index,其次Berkeley的Succinct项目也使用了FM-Index。

    FM-Index属于Offline算法(一次性压缩所有数据,压缩好之后不可修改),一般基于BWT变换(BWT变换基于后缀数组),压缩好的FM-Index支持以下两个最主要的操作:

    • data = extract(offset, length)
    • {offset} = search(string) ,返回多个匹配string的位置/偏移(offset)

    FM-Index还支持更多其他操作,感兴趣的朋友可以进一步调研。

    但是,在笔者看来,FM-Index有几个致命的缺点:

    • 实现太复杂(这一点可以被少数大牛们克服,不提也罢);
    • 压缩率不高(比流式压缩例如gzip差太多);
    • 搜索(search)和访问(extract)速度都很慢(在2016年最快的CPU i7-6700K上,单线程吞吐率不超过7MB/sec);
    • 压缩过程又慢又耗内存(Berkeley的Succinct压缩过程内存消耗是源数据的50倍以上);
    • 数据模型是Flat Text,不是数据库的KeyValue模型。

    可以用一种简单的方式把Flat Model转化成KeyValue Model:挑选一个在Key和Value中都不会出现的字符“#”(如果无法找出这样的字符,需要进行转义编码),每个Key前后都插入该字符,Key之后紧邻的就是Value。如此,search(#key#)返回了#key#出现的位置,我们就能很容易地拿到Value了。

    Berkeley的Succinc项目在FM-Index的Flat Text模型上实现了更丰富的行列(Row-Column)模型,付出了巨大的努力,达到了一定的效果,但离实用还相差太远。

    感兴趣的朋友可以仔细调研下FM-Index,以验证笔者的总结与判断。

    Terark的可检索压缩(Searchable Compression)

    Terark公司提出了“可检索压缩(Searchable Compression)”的概念,其核心也是直接在压缩的数据上执行搜索(search)和访问(extract),但数据模型本身就是KeyValue模型,根据其测试报告,速度要比FM-Index快得多(两个数量级),具体阐述:

    • 摒弃传统数据库的块压缩技术,采用全局压缩;
    • 对Key和Value使用不同的全局压缩技术;
    • 对Key使用有搜索功能的全局压缩技术COIndex(对应FM-Index的search);
    • 对Value使用可定点访问的全局压缩技术PA-Zip(对应FM-Index的extract)。

    对Key的压缩:CO-Index

    我们需要对Key进行索引,才能有效地进行搜索,并访问需要的数据。

    普通的索引技术,索引的尺寸相对于索引中原始Key的尺寸要大很多,有些索引使用前缀压缩,能在一定程度上缓解索引的膨胀,但仍然无法解决索引占用内存过大的问题。

    我们提出了CO-Index(Compressed Ordered Index)的概念,并且通过一种叫做Nested Succinct Trie的数据结构实践了这一概念。

    较之传统实现索引的数据结构,Nested Succinct Trie的空间占用小十几倍甚至几十倍。而在保持该压缩率的同时,还支持丰富的搜索功能:

    • 精确搜索;
    • 范围搜索;
    • 顺序遍历;
    • 前缀搜索;
    • 正则表达式搜索(不是逐条遍历)。

    与FM-Index相比,CO-Index也有其优势(假定FM-Index中所有的数据都是Key)。

    图片描述

    表1 FM-Index对比CO-Index

    CO-Index的原理

    实际上我们实现了很多种CO-Index,其中Nested Succinct Trie是适用性最广的一种,在这里对其原理做一个简单介绍:

    Succinct Data Structure介绍

    Succinct Data Structure是一种能够在接近于信息论下限的空间内来表达对象的技术,通常使用位图来表示,用位图上的rank和select来定位。

    虽然能够极大降低内存占用量,但实现起来较为复杂,并且性能低很多(时间复杂度的常数项很大)。目前开源的有SDSL-Lite,我们则使用自己实现的Rank-Select,性能也高于开源实现。

    以二叉树为例

    传统的表现形式是一个结点中包含两个指针:struct Node { Node *left, *right; };

    每个结点占用 2ptr,如果我们对传统方法进行优化,结点指针用最小的bits数来表达,N个结点就需要2*[log2(N)]个bits。

    • 对比传统基本版和传统优化版,假设共有216个结点(包括null结点),传统优化版需要2 bytes,传统基本版需要4/8 bytes。
    • 对比传统优化版和Succinct,假设共有10亿(~230)个结点。
    • 传统优化版每个指针占用[log2(230)]=30bits,总内存占用:($\frac{2*30}{8}$)*230≈ 7.5GB。
    • 使用Succinct,占用:($\frac{2.5}{8}$)*230≈ 312.5MB(每个结点2.5 bits,其中0.5bits是 rank-select 索引占用的空间)。

    Succinct Tree

    Succinct Tree有很多种表达方式,这里列出常见的两种:

    图片描述

    图1 Succinct Tree表达方式示例

    Succinct Trie = Succinct Tree + Trie Label

    Trie可以用来实现Index,图2这个Succinct Trie用的是LOUDS表达方式,其中保存了hat、is、it、a、四个Key。

    Patricia Trie加嵌套

    仅使用Succinct技术,压缩率远远不够,所以又应用了路径压缩和嵌套。这样一来,压缩率就上了一个新台阶。

    把上面这些技术综合到一起,就是我们的Nest Succinct Trie。

    对Value的压缩: PA-Zip

    我们研发了一种叫做PA-Zip (Point Accessible Zip)的压缩技术:每条数据关联一个ID,数据压缩好之后,就可以用相应的ID访问那条数据。这里,ID就是那个Point,所以叫做Point Accessible Zip。

    PA-Zip对整个数据库中的所有Value(KeyValue数据库中所有Value的集合)进行全局压缩,而不是按block/page进行压缩。这是针对数据库的需求(KeyValue 模型),专门设计的一个压缩算法,用来解决传统数据库压缩的问题:

    压缩率更高,没有双缓存的问题,只要把压缩后的数据装进内存,不需要专用缓存,可以按ID直接读取单条数据,如果把这种读取单条数据看作是一种解压,那么:

    • 按ID顺序解压时,解压速度(Throughput)一般在500MB每秒(单线程),最高达到约7GB/s,适合离线分析性需求,传统数据库压缩也能做到这一点;
    • 按ID随机解压时,解压速度一般在300MB每秒(单线程),最高达到约3GB/s,适合在线服务需求,这一点完胜传统数据库压缩:按随机解压300MB/s算,如果每条记录平均长度1K,相当于QPS = 30万;如果每条记录平均长度300个字节,相当于QPS = 100万;
    • 预热(warmup),在某些特殊场景下,数据库可能需要预热。因为去掉了专用缓存,TerarkDB的预热相对简单高效,只要把mmap的内存预热一下(避免Page Fault即可),数据库加载成功后就是预热好的,这个预热的Throughput就是SSD连续读的IO性能(较新的SSD读性能超过3GB/s)。

    与FM-Index相比,PA-Zip解决的是FM-Index的extract操作,但性能和压缩率都要好得多:

    图片描述

    表2 FM-Index对比PA-Zip

    结合Key与Value

    Key以全局压缩的形式保存在CO-Index中,Value以全局压缩的形式保存在 PA-Zip中。搜索一个Key,会得到一个内部ID,根据这个ID,去PA-Zip中定点访问该ID对应的Value,整个过程中只触碰需要的数据,不需要触碰其他数据。

    如此无需专用缓存(例如RocksDB中的DBCache),仅使用mmap,完美配合文件系统缓存,整个DB只有mmap的文件系统缓存这一层缓存,再加上超高的压缩率,大幅降低了内存用量,并且极大简化了系统的复杂性,最终完成数据库性能的大幅提升,从而同时实现了超高的压缩率和超高的随机读性能。

    从更高的哲学层面看,我们的存储引擎很像是用构造法推导出来的,因为CO-Index和PA-Zip紧密配合,完美匹配KeyValue模型,功能上“刚好够用”,性能上压榨硬件极限,压缩率逼近信息论的下限。相比其他方案:

    • 传统块压缩是从通用的流式压缩衍生而来,流式压缩的功能非常有限,只有压缩和解压两个操作,对太小的数据块没有压缩效果,也无法压缩数据块之间的冗余。把它用到数据库上,需要大量的工程努力,就像给汽车装上飞机机翼,然后要让它飞起来。
    • 相比FM-Index,情况则相反,FM-Index的功能非常丰富,它就必然要为此付出一些代价——压缩率和性能。而在KeyValue模型中,我们只需要它那些丰富功能的一个非常小的子集(还要经过适配和转化),其他更多的功能毫无用武之地,却仍然要付出那些代价,就像我们花了很高的代价造了一架飞机,却把它按在地上,只用轮子跑,当汽车用。

    图片描述

    图2 用LOUDS方式表达的Succinct Tree

    图片描述

    图3 路径压缩与嵌套

    附录

    压缩率&性能测试比较

    数据集:Amazon movie data

    Amazon movie data (~8 million reviews),数据集的总大小约为9GB, 记录数大约为800万条,平均每条数据长度大约1K。

    Benchmark代码开源:参见Github仓库

    • 压缩率(见图4)

    图片描述

    图4 压缩率对比

    • 随机读(见图5)

    图片描述

    图5 随机读性能对比

    这是在内存足够的情况下,各个存储引擎的性能。

    • 延迟曲线(见图6)

    图片描述

    图6 延迟曲线对比

    数据集:Wikipedia英文版

    Wikipedia英文版的所有文本数据,109G,压缩到23G。

    数据集:TPC-H

    在TPC-H的lineitem数据上,使用TerarkDB和原版RocksDB(BlockBasedTable)进行对比测试:

    图片描述

    表3 TerarkDB与原版RocksDB对比测试

    API 接口

    TerarkDB = Terark SSTable + RocksDB

    RocksDB最初是Facebook对Google的LevelDB的一个fork,编程接口上兼容LevelDB,并增加了很多改进。

    RocksDB对我们有用的地方在于其SSTable可以plugin,所以我们实现了一个RocksDB的SSTable,将我们的技术优势通过RocksDB发挥出来。

    虽然RocksDB提供了一个相对完整的KeyValueDB框架,但要完全适配我们特有的技术,仍有一些欠缺,所以需要对RocksDB本身也做一些修改。将来可能有一天我们会将自己的修改提交到RocksDB官方版。

    Github链接:TerarkDBhttps://github.com/Terark/terarkdb),TerarkDB包括两部分:

    为了更好的兼容性,TerarkDB对RocksDB的API没有做任何修改,为了进一步方便用户使用TerarkDB,我们甚至提供了一种方式:程序无需重新编译,只需要替换 librocksdb.so并设置几个环境变量,就能体验TerarkDB。

    如果用户需要更精细的控制,可以使用C++ API详细配置TerarkDB的各种选项。

    目前大家可以免费试用,可以做性能评测,但是不能用于production,因为试用版会随机删掉0.1%的数据。

    Terark命令行工具集

    我们提供了一组命令行工具,这些工具可以将输入数据压缩成不同的形式,压缩后的文件可以使用Terark API或(该工具集中的)其他命令行工具解压或定点访问。

    详情参见Terark wiki中文版https://github.com/Terark/terark-wiki-zh_cn)。


    订阅《程序员》(含iOS、Android及印刷版)请访问 http://dingyue.programmer.com.cn
    图片描述

    展开全文
  • Domino的压缩数据库的Load Compact命令

    千次阅读 2015-01-20 18:17:10
    以下各表描述了完成 Compact 服务器任务可以使用的选项。第一列列出了在 Domino Administrator 中使用“任务”“开始”工具或“文件”附签运行 Compact 显示的选项。第二列列出了等价的命令行选项,可以在使用...
    以下各表描述了完成 Compact 服务器任务时可以使用的选项。第一列列出了在 Domino Administrator 中使用“任务”“开始”工具或“文件”附签运行 Compact 时显示的选项。第二列列出了等价的命令行选项,可以在使用控制台命令或使用“程序”文档运行 Compact 时使用。 
    
    一、压缩 -- 基本
    选项
    等价命令行
    描述
    仅压缩该数据库和文件夹
    (要使用“文件”附签指定要压缩的数据库,请在文件窗格中选择数据库)
    数据库路径
    在数据库路径后指定任何附加选项。
    要压缩 Domino 数据文件夹中的数据库,请输入文件名,例如,SALES.NSF。要压缩数据文件夹所包含的文件夹中的数据库,请指定相对于数据文件夹的数据库路径。例如,要压缩文件夹 DATA\SALES 中的所有数据库,请指定 SALES。
    如果选择“压缩所有数据库”(或在命令行中不指定数据库路径),Compact 将压缩数据文件夹及数据文件夹所包含的文件夹中的所有数据库。
    有关“数据库路径”的详细信息,请参阅 使用控制台命令运行 Compact
     
    二、压缩 -- 选项
    选项
    等价命令行
    描述
    只在未使用的空间超过百分之 x 时才压缩数据库
    -S 百分比
    压缩具有指定的未使用空间百分比的所有数据库。例如,如果指定 10,将压缩未使用空间百分比等于或大于 10% 的数据库。请注意,未使用空间的计算方法并不能完全可靠地测量未使用空间。
    废弃所有已构建的视图索引
    -D
    废弃已构建的视图索引。仅在将数据库存储到磁带上之前使用此选项压缩数据库。进行拷贝样式压缩。
    保留或将数据库转换回先前的格式
    -R
    压缩数据库,但不将它转换成存储数据库的服务器的当前版本文件格式,或将当前版本文件格式的数据库转换回前一版本的文件格式。例如,在 Domino 6 服务器上,使用此选项可以压缩 Domino 5 数据库但不将其转换为Domino 6 文件格式,也可以将 Domino 6 数据库转换为 Domino 5 文件格式。此选项使用拷贝样式压缩。

    三、压缩 -- 样式
    选项
    等价命令行
    描述
    现场(推荐)
    -b
    使用现场压缩并恢复未使用空间,但不减小文件大小(除非尚有未完成的数据库结构更改,在这种情况下,将进行拷贝样式压缩)。这是推荐的压缩方法。
    现场,减小文件大小
    -B
    使用现场压缩,恢复未使用空间同时减小文件大小(除非尚有未完成的数据库结构更改,在这种情况下,将进行拷贝样式压缩)。如果使用事务记录,压缩完成后应进行数据库的完整备份。
    拷贝样式
    -c
    使用拷贝样式压缩。例如,使用该选项解决数据库损坏问题。
    拷贝样式:压缩时可以访问
    -L
    压缩时允许用户继续访问数据库。如果用户在压缩时编辑数据库,压缩将取消。此选项仅适用于拷贝样式压缩。
    拷贝样式:压缩过程中忽略错误
    -i
    即使遇到错误(如文档损坏),压缩仍然继续。仅适用于拷贝样式压缩。

    四、压缩 -- 高级
    不能通过 Domino Administrator 的“文件”附签中的“压缩”工具来使用高级压缩选项。
    选项*
    等价命令行
    描述
    优化文档表格位图:关闭
    -f
    禁用“优化文档表格位图”数据库属性。进行拷贝样式压缩。
    优化文档表格位图:打开
    -F
    启用“优化文档表格位图”数据库属性。进行拷贝样式压缩。
    不支持指定的答复层次:关闭
    -h
    禁用“不支持指定的答复层次”数据库属性;也就是支持指定的答复层次。进行拷贝样式压缩。
    不支持指定的答复层次:打开
    -H
    启用“不支持指定的答复层次”数据库属性;也就是不支持指定的答复层次。进行拷贝样式压缩。
    启用事务记录:关闭
    -t
    禁用事务记录。
    启用事务记录:打开
    -T
    启用事务记录。
    不保留未读标记:关闭
    -u
    禁用“不保留未读标记”数据库属性;也就是保留未读标记。
    不保留未读标记:打开
    -U
    启用“不保留未读标记”数据库属性;也就是不保留未读标记。
    * 在启用或禁用这些属性前,应先选择“设置高级属性”。
     
    五、压缩 -- 归档
    当使用文档归档工具归档和删除数据库中的文档时,如果数据库在服务器上,并且选择了高级归档选项“在服务器上自动归档”,就可使用以下 Compact 选项归档文档。
    选项*
    等价命令行
    描述
    仅归档
    -A
    归档并从数据库中删除文档,但不压缩数据库。
    归档然后压缩
    -a
    归档并从数据库中删除文档,然后压缩数据。
    删除然后归档
    -j
    从数据库中删除文档然后压缩数据库。
    * Domino Administrator“文件”附签中的“压缩”工具只提供“归档数据库”选项;此选项先归档,然后压缩。

     转发链接:http://freemanluo.blog.51cto.com/636588/197414

    展开全文
  • 介绍了Mysql数据库的增加和删除,同时详细介绍了存储引擎。

    声明:本文内容参考书籍《MySql入门很简单》

    目录

    1 创建数据库

    2 删除数据库

    3 数据库存储引擎

    3.1 InnoDB

    3.2 MyISAM

    3.3 MEMORY

    3.4 存储引擎的选择


    首先数据库是指长期存储在计算机内、有组织的和可共享的数据集合。简而言之,数据库就是一个存储数据的地方。只是,其存储方式有特定的规律。这样就可以方便的处理数据。数据库的操作包括创建数据库和删除数据库。这些操作都是数据库管理的基础。

    同时MySql中提到了存储引擎的概念。简而言之,存储引擎就是指表的类型。数据库的存储引擎决定了表在计算机中的存储方式。

    1 创建数据库

    创建数据库用到的SQL语句为 CREATE DATABSE,语法形式如下:

    CREATE DATABASE 数据库名;

    例如创建一个名为test的数据库

    如上,创建数据库之后我们可以用SHOW DATABASES语句来查看当前有哪些数据库。

    2 删除数据库

    删除数据库通过语句DROP DATABASE实现,其语法形式如下:

    DROP DATABSASE 数据库名;

    3 数据库存储引擎

    通过:

    SHOW ENGINES \g;

    可以查看MySql数据库支持的存储引擎。\g和;的含义一样,只不过会让显示更美观。显示如下:

    其中,Engine是存储引擎名称,Support表示表明Mysql是否支持此数据存储引擎,Comment是对该引擎的评论,Transactions表示此存储引擎是否支持事务处理,XA表示是否满足分布式交易处理的XA规范,Savepoints表示是否支持保存点,以便回滚到保存点。

    InnoDB是MySql默认的存储引擎。接下来将详细介绍InnoDB、MyISAM和MEMORY存储引擎。

    3.1 InnoDB

    InnoDB给MySql的表提供了事务、回滚、崩溃修复能力和多版本并发控制的事务安全。InnoDB是MySql中第一个提供外键约束的表引擎。而且InnoDB对事物处理的能立,也是其他存储引擎无法进行比拟的。

    InnoDB支持自动增长列AUTO_INCREMENT。自动增长列的值不能为空,且值必须是唯一。MySql中规定,自增长的列必须为主键。在插入值时,如果自增长的列不输入值,则插入的值为自动增长后的值;如果输入的值为0或NULL,则插入的值也为自动增长后的值;如果插入的是某个确定的值,且这个值在前面没有出现过,则可以直接插入。

    InnoDB支持外键。外键所在的表为子表,外键所依赖的表为父表。父表中子表外键关联的字段必须为主键。当删除、更新父表中的某条信息时,子表也必须有相应的改变。

    InnoDB存储引擎中,创建的表的表结构存储在.frm文件当中。数据和索引存储在innodb_data_home和innodb_data_file_path定义的表空间中。

    InnoDB存储引擎的优势在于提供了良好的事务管理、崩溃修复能立和并发控制。缺点是其读写效率较差,占用的数据空间相对较大。

    3.2 MyISAM

    MyISAM存储引擎说MySql中最常见的存储引擎,曾经室MySql的默认引擎。MyISAM是基于ISAM存储引擎发展起来的,并对其增加了很多有用的扩展。

    MyISAM存储引擎的表存储成三个文件。文件的名字与表名相同。扩展名包括frm、MYD和MYI。其中frm为扩展名的文件存储表的结构;MYD为扩展名的文件存储数据,MYI为扩展名的文件存储索引。

    基于MyISAM存储引擎支持三种不同的存储格式。包括静态型、动态型和压缩型。其中,静态型为MyISAM的默认存储格式,其字段是固定长度的;动态型包含变长字段,记录的长度不是固定的;压缩型需要使用myisampack工具进行创建,占用的磁盘空间较小。

    MyISAM存储引擎的优势在于占用空间小、处理速度快。缺点是不支持事务的完整性和并发性。

    3.3 MEMORY

    这是一种特殊的存储引擎,其使用存储在内存中的内容来创建表,而且数据也存放在内存当中。这些特性都与前两个存储引擎不同。

    每个基于MEMORY存储引擎的表事件对应一个磁盘文件。该文件的文件名与表明相同,类型为frm类型。该文件中只存储表的结构,而数据都是文件,都是存在内存当中。这样有利于数据的快速处理,提高整个表的处理效率。需要注意的是,服务器必须要有足够的内存来维持MEMORY存储引擎的表的使用。如果不需要使用了,可以释放这些内存,甚至可以删除不需要的表。

    MEMEORY存储引擎默认使用的是hash索引。其速度要比B型树索引快。

    MEMORY的表的大小是受限制的。表的大小主要取决于两个参数,分别是max_rows和max_help_table_size,max_rows可以在创建表时指定:max_help_table_size的大小默认为16MB,并且可以按需进行扩大。因此,其存于内存中的特性,这类表的处理速度非常快。但是数据极易丢失。生命周期短,因此选择这个引擎要特别小心。

    3.4 存储引擎的选择

    在实际工作中,选择一个合适的存储引擎是一个非常复杂的问题。每个引擎都有各自的优势。下面从几个方面将这三种引擎做了一个比较。

    • InnoDB存储引擎,支持事务处理,支持外键。同时支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高,要求实现并发控制那么就选择此存储引擎。如果需要频繁的进行更新、删除操作的数据库,也可以选择此存储引擎,因为该类引擎可以实现事务的提交和回滚。
    • MyISAM存储引擎的插入数据快,空间和内存使用比较低。如果表主要是用于插入新记录和读出记录,那么可以选择MyISAM存储引擎。如果完整性、并发性要求很低,也可以选择此引擎。
    • MEMORY存储引擎的所有数据都存在于内存当中。数据的处理速度快,但是安全性不高。如果需要很快的读写速度,对数据的安全性要求低,可以选择此存储引擎。同时,因为此引擎对表的大小有要求,不能建立太大的表。所以这类数据库只适用于相对较小的数据库表。
    展开全文
  • 作者简介作者:熊中哲,现任才云科技工程VP,负责产品和研发工作。曾就职于阿里巴巴、沃趣科技、美团。超过12年数据库领域的工作经历,目前对云原生,机器学习和异构计算也很感兴趣。“摩尔定律失...
  • 存储引擎是MySQL的特点,是一种插入式的存储引擎的概念。 MySQL中提到的存储引擎,通俗点讲指的是表的类型,不同类型的存储引擎决定了表在计算机中...我们首先来看一下InnoDB存储引擎下数据库的文件类型 .opt...
  • 作者为ScaleFlux系统团队郑宁,王欢、许树堃。1●数据库中的写放大在数据库的使用过程(包括其它多种应用)中,我们通常会关注一些系统指标,比如CPU的使用率,内存的占用量,或者I...
  • 数据库架构设计及结合计算型存储的思考数据库系统面临的瓶颈如何解决这些问题数据库架构设计角度计算和存储分离日志下推日志和数据分离嵌入底层存储引擎应用计算型存储底层技术数据库存储原子写计算型存储压缩...
  • 摘要:目前,物联网、工业互联网、车联网等智能互联技术在各个行业场景下快速普及应用,导致联网传感器、智能设备数量急剧增加,随之而来的海量时序监控数据存储、处理问题,也为时序数据库高效压缩存储数据能力...
  • Android图片压缩(质量压缩和尺寸压缩) 在做项目中遇到一个头疼的问题,读取...2、处理过的图片存储本地和sqlite数据库  先看1:图片有三种存在形式:硬盘上是file,网络传输是stream,内存中是stream或bi
  • mysql数据库存储类型及存储引擎分析

    千次阅读 2017-09-20 16:25:56
    今天我突发奇想,我们一直在用的关系型数据库mysql,它到底能存多少数据呢, 又是怎样存储,怎样分布在数据库里面的呢? 于是我到网上搜索了一些相关资料,做了如下总结: 1.MySQL本身无任何限制,但是会受到操作...
  • 在测试,Sysbench先向数据库中写入200GB数据,在此基础上依次进行insert、update-non-index和update index的操作,并记录每种情况下主机端的数据写入量以及NAND的实际写入数据量(在普通SSD下这两个数据写入量基本...
  • 一、备份数据库 1、打开SQL企业管理器,在控制台根目录中依次点开Microsoft SQL Server 2、SQL Server组-->双击打开你的服务器-->双击打开数据库目录 3、选择你的数据库名称(如论坛数据库Forum)-->然后点上面菜单...
  • MySQL - 常见的三种数据库存储引擎

    万次阅读 多人点赞 2018-01-15 16:55:29
    数据库存储引擎:是数据库底层软件组织,数据库管理系统(DBMS)使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能,使用不同的存储引擎,还可以获得特定的...
  • 找不到数据源Macrosoft Access odbc问题 问题 在学习web开发遇到的问题:未能在自己的电脑上找到数据源
  • 当应用程序需要极高的性能,企业经常会使用内存数据库或键值存储(缓存层)来满足这一需求。然而,内存数据库的总体拥有成本高企,并且在可扩展性方面具有硬限制,如果超出内存限制,则会出现可靠性问题和重启延迟...
  • MySQL基础知识一、存储引擎的相关知识和命令二、三个比较重要的数据库存储引擎1、`InonoDB`存储引擎:2、`MyISAM`存储引擎3、`MEMEORY`存储引擎三、存储引擎的比较 一、存储引擎的相关知识和命令 MySQL中有关于存储...
  • MyISAM存储引擎 InnoDB存储引擎 MEMORY存储引擎 MERGE存储引擎 指定存储引擎的脚本:在创建表的脚本的结束前加engine=innodb ...支持三种不同的存储结构:静态表、动态表、压缩表。 静态表:表中的字段都是...
  • 因为在关系数据库中,数据是以表的形式存储的,所以存储引擎简而言之就是指表的类型,数据库存储引擎决定了表在计算机中的存储方式。在Oracle和SQL Server等数据库中只有一种存储引擎,所有数据存储管理机制都是...
  • 数据库压缩备份

    2013-05-24 15:02:00
    当我们浏览 SQL Server 2008的新特性,我们发现由一个叫做数据库备份压缩的特性,可以用它来显著地降低备份和恢复操作。  数据库压缩是SQL Server 2008的一个新特性,它可以显著地降低备份和恢复操作。默认情况...
  • # 创建新表将使用的默认存储引擎 default-storage-engine=INNODB **注意最新版的MySQL里面是没有data这个文件夹的,要自己新建一个 四、安装环境 以管理员身份运行命令提示符(cmd),将目录切换到你的...
  • 关系数据库与非关系型数据库一、数据库概述1、关系型数据库2、非关系型数据库二、数据库区别1、数据存储方式不同2、扩展方式不同3、对事务性的支持不同三、非关系型数据库产生背景四、Redis简介1、Redis 优点五、...
  • Mysql数据库和InnoDB存储引擎中有各种不同类型的文件,这些文件在mysql中起着至关重要的作用,了解他们的功能对学习mysql的原理有很大的帮助。 参数文件 日志文件 socket文件 pid文件 MySQL表结构文件 存储引擎...
  • MyISAM:读取速度优越,常用于高读取的应用场景数据库,支持三种不同类型的存储结构:静态型、动态型、压缩型。不支持事务和外键。 MyISAM与InnoDB的区别与选择 区别: InnoDB支持事务,My
  • 简介:目前,物联网、工业互联网、车联网等智能互联技术在各个行业场景下快速普及应用,导致联网传感器、智能设备数量急剧增加,随之而来的海量时序监控数据存储、处理问题,也为时序数据库高效压缩存储数据能力...
  • 1. 数据库存储引擎概念: 数据库存储引擎是数据库底层软件组织,数据库管理系统(DBMS)使用数据引擎进行创建、查询、更新和删除数据。 不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能,使用不同的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 78,679
精华内容 31,471
关键字:

压缩数据库时关闭了存储