查看: 3546|回复: 7
请问内存数据库对底层存储的IO行为一般是怎样的？
论坛徽章:1
既然内存数据库自己维持着大块ram空间作为cache，那么它对底层存储的IO随机性还会那么大么？
请赐教一二。谢谢！
论坛徽章:24
内存数据库所有的数据操作都是在RAM上的，在进行数据操作时与以前传统磁盘数据库对比来说对于磁盘的操作量较少，对于底层存储的IO随机性原则跟传统磁盘数据一样。
论坛徽章:10
拿Timesten来说，和存储打交道之处主要有二个方面：Checkpoint、Log。
Checkpoint: 顺序写
Log: 顺序写
所以，我觉得Timesen的随机IO要比传统数据库少很多。另外，Timesten的内存不应该认为是cache。
论坛徽章:62
底层存储的IO随机性，内存数据库与磁盘大打交道少，所以不大。
论坛徽章:0
你也可以用在线备份软件给你的数据备份
它不仅能好的解决你上面所提到的问题，加之它本身所具有的本地和异地可以同时备份的功能更会让安全简单的进行各种数据的备份。
备份中国的在线备份软件多种操作系统，支持本地和异地备份，还有备份过滤器的功能，可以根据你的需要随心所欲的备份。备份过滤器让您备份需要的过滤掉不需要的，予过滤的文件对他们都有一个待删除的期限，在这个期限内如果想继续保留那些文件可以随时还原到指定的路径
免费下载试用：
& & & & & & & & & & & &
ｐｃ２．０版& & & & & & & & & & & &
& & & & & & & & & & & &
服务器２.０版
同时你也可免费获得两个版本的破解版
论坛徽章:66
和具体情况有关。比如使用TT，而且不使用类似aging这样的机制时，同时你的log buffer又比较大的情况，正常情况下不会出现很随机的IO，只有顺序IO，写checkpoint file和写log.
论坛徽章:0
补充一点，使用内存数据库的时候，如果是高性能的应用的话，对磁盘的要求还是很高的，想想每秒钟要做几万，几十万个事务，每个事务可能又牵涉到10多条sql语句的时候产生的日志还是非常庞大的，所以高性能的应用可能会要求用磁盘阵列的。
论坛徽章:0
为了数据的完整性和事务的一致性，为日志适当投入还是值得滴。。
itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：　广播电视节目制作经营许可证：编号（京）字第1149号1、IT系统的IO结构图
2、应用程序层IO
应用层程序是计算机系统内主动发起IO请求的大户，但是要知道，计算机内不止有应用程序可以向底层存储设备主动发起IO请求，其他的，比如文件系统自身、卷管理层自身、适配器驱动层自身等，都可以主动发起IO。当然，只有应用程序发起的IO才可以修改用户实体数据内容，而其他角色发起的IO一般只是对数据进行移动、重分布、校验、压缩、加密等动作，并不会修改用户层面的实际数据内容。
应用程序在读写数据的时候一般是直接调用操作系统所提供的文件系统API来完成文件数据的读写等操作，有的应用程序可以直接调用卷管理层或者适配器驱动层API从而直接操控底层的卷或者LUN，比如一些数据库程序，他们直接操控卷而不需要使用文件系统提供的功能，它们自己来管理数据在底层卷上的分布。
每个应用程序都会有自己的Buffer用来存取有待处理的数据。 应用程序向文件系统请求读数据之后，文件系统首先将对应的数据从底层卷或磁盘读入文件系统自身的Buffer，然后再将数据复制到对应程序的Buffer中。应用程序也可以选择不适用系统内核缓存，这时FS将IO请求透明的翻译并转发给底层处理，返回的数据将直接由OS放到应用程序Buffer。当应用程序向文件系统请求写入数据时，文件系统会先将应用程序Buffer中对应的数据复制到文件系统Buffer中，然后在适当的时刻将所有FS Buffer内的
Dirty Page写入硬盘。同样如果不使用系统内核缓存，则写入数据经过FS文件一块地址翻译后直接由OS提交给FS下层处理。文件系统的动作是可控的，稍后介绍。
同步IO与异步IO
接下来我们来看IO的概念，同步IO和异步IO这个比较简单；同步的话就是应用程序发出IO请求，然后等待操作系统下层返回给应用程序数据，然后继续执行；而所谓的异步IO，就是应用程序发出IO请求后，不必等待返回数据，直接进行下一步的代码运行。
IO请求发送到OS内核之后到内核将IO请求对应的数据读取或者写入完成这段时间会贡献为OS的IOWait（即为IO等待时间），IOWait指标一旦升高到高于60%左右的百分比，那么就需要考虑后端存储系统所提供的性能是否已经不能满足应用需求了。
同步IO请求如果不加任何参数的话，一般是操作提供的默认调用方式，也是一般的应用程序首选的IO调用方式。一般情况下，如果遇到数据链路速度或者存储介质速度很慢，比如通过低速网络进行IO（Ethernet上的NFS、CIFS等），或者使用低速Flash芯片等，使用异步IO方式是一个很好的选择。第一是因为异步IO调用可以接连发出多个IO请求，一通发向目标，目标在接收到这些IO请求之后可以一并处理，增加速率。比如SATA硬盘的NCQ功能，
要实现与单线程异步IO类似的结果，可以采用另一种方法，即生成多个线程或进程，每个线程或进程各自进行同步IO调用。然而，维护多个线程或进程需要耗费更多的系统资源，而采用单线程异步IO调用虽然需要复杂的代码来实现，其相比于多线程同步IO的方式来说来说仍然更加高效。
在Windows系统中，如果应用程序在打开文件进行读写操作时未指定特殊参数，则文件系统默认是使用自身缓存来加速数据读写操作的。并且，这种情况下异步调用多数情况下会自动变为同步调用，其结果就是IO发出后操作系统不会返回任何消息直到IO完成为止，这段时间内线程处于挂起状态，为什么会这样？有三个原因：
1、预读和Write Back：文件系统缓存的机制可以增加IO读操作的命中率，尤其是小块连续IO操作，命中率几乎是百分之百。在这种情况下，每个读IO操作的响应时间会在微秒级别，所以OS会自动将异步调用转变为同步调用以便节约异步IO所带来的系统开销。
2、尽量保持IO顺序：异步模式下，应用程序可以在单位时间内发出若干IO请求而等待OS批量返回结果。OS对于异步IO结果的返回顺序可能与IO请求所发出的顺序不同，在不使用文件系统缓存的情况下，OS不能缓存底层返回的IO结果以便重新对结果排序，只能够按照底层返回的实际顺序来将数据返回给应用程序，而底层设备比如磁盘在执行IO的时候不一定严格按照顺序执行，因为文件系统之下还有多处缓存，IO在这里可能会被重排，或者有些IO命中了，而有些还需要到存储介质中读取，命中的IO并不一定是先被发送的IO。而应用程序在打开文件的时候如果没有给出特殊参数，默认是使用文件系统缓存的，此时系统内核缓存（也就是文件系统的缓存）便会严格保持IO结果顺序的返回给应用程序，异步调用变为同步模式。
3、系统内核缓存机制和处理容量决定：文件系统一般使用Memory Mapping的方式来进行IO操作，将映射到缓存中一定数量的page，目标文件当需要的数据没有位于对应的page中，便会产生Page Fault，需要将数据从底层介质读入内存，这个过程OS自身会强行使用同步IO模式向下层存储发起IO。而OS内 存在一个专门负责处理page Fault情况的Worker线程池，当多个应用程序单位时间内使用异步IO向OS发送大量请求时，一开始OS还可以应付，接收一批IO，然后对其进行异步处理，随着IO大量到来，系统内核缓存命中率逐渐降低，越来越多的Page
Fault将会发生，诸多的Worker线程将会处理Page Fault，线程池也会很快耗尽，此时OS只能将随后的IO变为同步操作，不再给其回应直到有Worker 线程空闲为止。
导致Windows将异步强行转变为同步的原因不只有系统内核缓存的原因，其他一些原因也可以导致其发生。在Windows系统中，访问NTFS自身压缩文件、访问NTFS自身加密文件、任何扩展文件长度的操作都会导致异步变同步。要实现真正的异步IO效果，最好在打开文件时给出相关参数，不使用内核文件系统缓存。不使用内核文件系统缓存的IO方式一般称为Direct IO或者DIO，异步IO模式又被称为AIO，即Asynchronous IO.
在使用iSCSI/NAS等基于TCP/IP的存储协议时，并且是随机IO环境下，利用Bypass文件系统缓存的纯异步IO模式会大大减少网络传输的开销，因为如果使用文件系统缓存，则OS强制变为同步IO模式，IO一个一个的执行，所以每个IO请求就需要被封装到单独的TCP包和以太网帧中，在IO量巨大的时候，这种浪费是非常惊人的。举个例子纯异步IO模式下抓包数据文件只有120KB，而如果使用FS缓存之后，同样的IO列表，抓包数据变为490KB，开销是前者的4倍，这是个绝对不容忽视的地方。
不管是Windows还是Linux都是：用户程序——OS内核——存储设备 这种架构，用户程序和OS内核之间存在一套IO接口。同样，OS内核与存储设备之间一样存在着IO接口，同样也有同步异步之分。在Windows系统下，OS内核——存储设备 和 &用户进程——OS内核 这两个链接之间的IO行为对应，即上层为同步，则底层也同步。上层为异步底层也是异步（不使用FS缓存时；如果使用，有可能异步的转变为同步的）。 而Linux系统下，上层IO与底层IO不一定是对应关系，
NFS下的缓存和IO机制
同为NAS网络文件访问协议，NFS不管在数据包结构还是在交互逻辑上相比CIFS要简化许多，但是简化的结果就是不如CIFS强大，CIFS之所以复杂是因为CIFS协议中几乎可以透传本地文件系统的所有参数和属性，而NFS携带的信息很有限。简化同样也带来了高效，执行类似的操作，NFS交互的数据包在单个包的大小上和整体发包数量都相对CIFS有很大的降低。
与CIFS不同的是，NFS提供诸多更改的参数来控制操作系统内核底层IO行为。
Linux下的NFS比Windows下的CIFS优异，表现在，前者有明显预读能力，只有在特定情况下游读惩罚，写惩罚一点没。正因为NFS的缓存如此高效，所以在Linux2.6内核中，在mount时并没有提供Direct IO的选项（内核编译时被禁止），但是单个程序在Open()的时候依然可以指定O_DIRECT 参数来对单个文件使用DIO模式。与Windows下CIFS实现方式相同，如果选择使用了DIO模式，那么NFS层就会完全透传程序层的IO请求。
多进程访问下缓存一致性的解决办法：
在缓存一致性方面，NFS相比CIFS来讲要差一些。CIFS使用Oplook机制来充分保证文件的时序一致性；而对于NFS，除了使用字节锁或者干脆使用DIO模式之外，没有其他方法能够在使用缓存的情况下严格保证时序一致性，NFS只是提供了尽力而为的一致性保证，而且这种保证全部由客户端自行实现，NFS服务端在这个过程中不作为，下面我们看一下NFS提供的尽力而为的一致性保证机制。
比如，有两个客户端共同访问同一个NFS服务端上的文件，而且这两个客户端都是用本地NFS缓存，那么客户端A首先单开了文件并且做了预读，且A本地缓存内还有被缓存的写数据，此时客户端B也打开了这个文件，并且做了预读，如果被读入的数据部分恰好是A被缓存的尚未写入的部分，那么此时就发生了时序不一致。而这种情况在CIFS下是不会发生的，因为B打开时，服务端会强制让A来将自己的写入缓存Flush，然后才允许B打开，此时B读入的就是最新的数据。
再回到NFS来，B上某进程打开了这个文件之后，内核会将文件的属性缓存在本地，包括访问时间、创建时间、修改时间、文件长度等信息，任何需要读取文件数据的操作，都会Cache Hit直到这个Attribute Cache（ac）到达失效时间为止，如果ac达到了失效时间，那么内核NFS层会向服务端发起一个GETATTR请求来重新取回文件最新的属性信息并缓存在本地，ac失效计时器被置0，重新开始计时，往复执行这个过程，在ac缓存未超时之前，客户端不会像服务端发起GETATTR请求，除非收到了某个进程的Open()请求。其他诸如stat命令等读取文件属性的操作，不会触发GETATTR。
任何时刻，任何针对NFS文件的Open()操作，内核均会强制触发一个GETATTR请求被发送至服务端以便取回最新的属性数据。这样做是合理的，因为对于Open()操作来说，内核必须提供给这个进程最新的文件数据，所以必须查看最新属性以与ac缓存中的副本对比。如果新取回的属性信息中mtime相对于本地缓存的信息没有变化，则内核会擅自替代NFS服务端来响应程序的Open()，并且随后程序发起的读操作也都首先去碰缓存命中，不命中的话再将请求发给服务端，这一点类似于CIFS下的Batch Oplock；但是如果新取回的数据中对应的mtime比缓存副本晚，那么就证明有其他客户端的进程修改了这个文件，也就意味着本地的缓存不能体现当前最新的文件数据，全部作废，所以此时，内核NFS将会将这个Open()请求透传到服务器端，随后发生的读写数据的过程依旧先Cache
Hit(由于之前缓存作废，所以第一次请求一定是不命中的)，未命中则从服务端读取，随着缓存不断被填充以最新读入的数据，命中率越来越高，而且直到下次出现同样的过程之前这些缓存的文件属性副本很数据副本不会作废。
3、文件系统层IO
IO离开应用层之后，经由OS相关操作被下到了文件系统层进行处理，文件系统最大的任务就是负责在逻辑文件与底层卷或者磁盘之间做映射，并且维护和优化这些映射信息。文件系统还要向上层提供文件IO访问的API接口，比如打开、读、写、属性修改、裁剪、扩充、锁等文件操作。另外，还需要维护缓存，包括预读、Write Back、Write Through、Flush等操作；还需要维护数据一致性，比如Log、FSCK等机制；还需要维护文件权限、Quota等。
可以把一个文件系统分为上部、中部、下部三个部分。访问接口属于上部；缓存管理、文件管理等属于中部；文件映射、一致性保护、底层存储卷适配等属于下部。下面我们分别来看看各个部分的功能：
1、文件系统上部：文件系统对用户的表示层属于上部，比如Linux下的表示法“/root/a.txt”、&/dev/sda1&、“/mnt/nfs”或者Windows下的表示法“D:\a.txt”。。。文件系统表示层给用户提供了一种简洁直观的文件目录，用户无需关心路径对应的具体实体处于底层的哪个位置，处于网络的另一端，还是磁盘的某个磁道扇区。这种FS最顶层的抽象称为Vitrual File
System（VFS）
文件系统访问接口层也位于上部。由于接口层直接接受上层IO，而IO又有14种，文件系统默默接受着这14中IO，包括什么随机、连续，大块，小块什么的读。文件系统一般会自己智能的、自适应的选择是否需要进行预读。以加快处理速度。
2、文件系统中部：缓存位于文件系统中部。预读和Write Back是文件系统的最基本功能，可以参考上文中的示例来理解文件系统预读机制。缓存预读对不通IO类型的优化效果也是不通的。
对于应用程序的写IO操作，文件系统使用Write Back模式提高写IO的响应速度。这种模式下，应用程序的写IO数据会在被复制到系统内核缓存之后而被通告为完成，而此时FS可能尚未将数据写入磁盘，所以此时如果系统当机，那么这块数据将会丢失，对应的应用程序可能并不知道数据已经丢失从而造成错误的逻辑，这种模式在关键领域的应用中是要绝对的杜绝的。比如NTFS文件系统提供了一个参数：FILE_FLAG_WRITE_THROUGH,就是给出这个参数之后，在写数据的时候，IO会先被复制到系统内核缓存，然后立即写入磁盘。最后向应用程序返回完成信号。注意这个参数与FILE_FLAG_NO_BUFFERING不同，后者表示不使用系统内核缓存了，而前者依然使用，只不过是全部写到磁盘后才返回成功信号。
文件系统还使用另外一种IO优化机制，叫做IO Combination。假设T1时刻有某个IO目标地址为LBA0--1023，被FS收到后暂存于IO Queue中；T2时刻，FS尚未处理这个IO，正好这个时候又有一个与前一个IO类型（读/写）的IO被收到，目标地址段位LBA。FS将将这个IO追加到IO Queue末尾。T3时刻，FS准备处理Queue中的IO，FS会扫描Queue中一定数量的IO地址，此时FS发现这两个IO的地址是相邻的，并且都是读或者写类型，则FS会将这两个IO合并为一个目标地址为LBA0--2047的IO。并且向底层存存储发起这个IO。待数据返回之后，FS在将这个大IO的数据按照地址段拆分成两个IO结果并且分别返回给请求者。这样做的目的显而易见，节约后端IO资源，增加IOPS和带宽吞吐量。
3、文件系统下部：文件系统下部包括：文件——块 的映射、Flush机制、日志记录、FSCK以及与底层卷管理接口等相关操作。
位于FS下部的一个重要的机制是文件系统的Flush机制。在WB（write back）模式下，FS会暂存写IO实体数据与文件系统的Metadata。FS当然不会永久地暂存下去而不写入磁盘。文件系统会在适当的条件下将暂存的写IO数据写入磁盘，这个过程叫Flush。触发Flush的条件很多，时间点、应用触发、FS自身为实现某些功能（如快照）等等等都可以触发Flush。
文件系统是系统IO路径的之歌重要角色，文件在系统底层存储卷或者磁盘上的分布算法是重中之重，传统的文件系统只是将底层的卷当做一个连续的扇区空间，并不感知这个连续空间的物理承载设备的类型或者数量等，所以也就不知道自己的不同类型的IO行为会给性能带来身影响。如果我们再FS层对底层的RAID类型和磁盘类型等各种因素做出分析和判断，然后制定对应的策略，让文件能够按照预期的效果有针对性地在RAID组内进行分布。这样就会大大提高系统读写性能。比如，在格式化文件系统时，或者在程序调用时，给出显式参数：尽量保持每个文件存放在一个屋里硬盘中，那么当创建一个文件的时候，文件系统便会根据底层RAID的Stripe边界来计算将哪些扇区地址段分配给这个文件，从而让其物理地只分布到一个此磁盘中，这种文件分布方式在需要并行访问大龄文件时是非常有意义的，因为底层RAID的盲并发度很低，如果在FS层面手动地将每个文件只分布一个磁盘上，那么N个磁盘组成的TAID组理论上就可以并发N个针对文件的读操作，写操作并发值仍相对很低，但是至少可以保证为理论最大值。
总之、文件系统必须与底层完美配合才能获得最大性能。
阅读(...) 评论()内存数据库_IT168
内存数据库
随着技术的发展，近年来企业受到互联网巨大的冲击。这时传统企业开始重塑再造业务。尝试借助IOT改善供应链，也可能借助一些消费者的大数据做对客户的精准营销，对客户画像等。数据在这时代变成大量的、实时的。我们既要处理事务性的交易，还要处理多维分析、数据挖掘。这时，无论商业技术还是开源技术方
分享过去三年在大规模内存数据库领域的技术探索:企业级NoSQL服务JIMDB。Redis协议兼容，精确故障检测，自动故障切换，部分复制(partial replication)，弹性横向扩展，基于docker全自动化维护，Java客户端直连或多语言接入代理，JIMDB从单机房几十台机器发展到多个机房近四千台服务器，成为京东集团无数
国际DBMS领先企业ALTIBASE()宣布，将通过推出新战略产品以及加强与中国国内合作伙伴的合作，进一步巩固在中国市场的优势地位。
现在我们站在各个用例的角度上来考虑哪种系统适合于这些用例。你的意见是？首先，我们要纵览各种数据模型。这些模型的分类方法来自于Emil Eifrem 和 NoSQL databases。
根据甲骨文相关介绍，MySQL集群是NoSQL内存数据库。如今，这些特征在MySQL集群7.4中脱颖而出。大多数人认为MySQL集群是一种分布式的、高性能、高可用性且流行性高的开源数据库。但追溯其根源――早在2003年MySQL数据库确定之前――集群就被称为NDB(网络数据库)，它是主要为电信公司设计的NoSQL架构的内
从概念验证(POC，proof-of-concept)到生产环境部署，客户在迁移到SAP HANA内存数据库平台之前需要考虑许多因素，其中包括硬件选择，备份与恢复计划以及安全性管理等等。但客户究竟该从何入手呢?
作为先行者，各大厂商已经找到令人信服的用例论据。内存内方案的强大实力帮助在线博彩公司Bwin.party的支持能力由每秒12000次下注提升至每秒150000次。下注次数的增加也就意味着其运营收益也将水涨船高。而在零售服务企业Edgenet这边，内存内技术帮助领导者获得了接近实时的产品备货情况反馈，从而使其
微软SQL Server 2014提供了众多激动人心的新功能，但其中最让人期待的特性之一就是代号为” Hekaton”的内存数据库了，内存数据库特性并不是SQL Server的替代，而是适应时代的补充，现在SQL Server具备了将数据表完整存入内存的功能。相比较于Oracle的TimesTen和IBM的SolidDB，Hekaton是完全集成于数据
武毅谈到，现在内存计算的5大趋势：1、数据展现上，时间就是金钱。2、面临着处理海量的数据。3、磁盘IO成为并行计算的瓶颈。4、针对不同行业，应对各种业务需求，需要从不同的维度去处理，分析数据。5、对内存数据库的需求。
对于一个系列的业务应用来说，肯定不可能通过单个数据库来实现的。需要的是一个数据库群。包含核心库、业务应用库，以及各种功能性的库，根据重要性做层级划分。
数据库初创企业 MemSQL 刚刚在 B 轮融资中获得 3500 万美元。MemSQL是一家数据库初创企业，由 Facebook 前员工 Eric Frenkiel(福布斯 2012 年美国技术领域30位未来之星之一，他可是在 Facebook 上市前离开的)和 Nikita Shamgunov 创建于 2012 年，现有员工将近 40 人。
几款主流的内存数据库各有优劣，企业在选择时除了考虑性价比，最重要的还是要适合自己的业务场景。内存数据库是一个不可逆转的趋势，它不仅能够大幅提升数据库的性能，还能够减轻数据库开发和管理人员的调优工作。目前，硬盘数据库仍然是无法取代的，但在不久的将来，相信内存数据库能够取代硬盘数据库
SQL Server内存OLTP中的事务是非常直接的。虽然我们并不会讨论一些可能的优化，但是它的基础设计模式是相当容易理解的，并且能够在其他的项目中重用。SQL Server内存OLTP中的事务依赖于一个类似时间戳的结构，被称为事务ID。一个事务使用两个时间戳，一个用于操作的开始，另一个在提交事务的时候为它分
对帆船运动比较熟悉的朋友肯定听说过这样一种战术，即暂时落后的运动员能够借助领先者带来的前进气流推动自身一举实现超越。而这正是甲骨文公司在内存数据库竞争中所采取的处理方式。甲骨文公司CEO Larry Ellison在上周日的甲骨文OpenWorld大会的主题演讲中公布了Oracle 12c内存解决方案，同时重申了上
在去年11月召开的SQL PASS大会上，我们公布了内存OLTP数据库技术(代号为‘Hekaton’)，旨在为SQL Server的下一个版本做好准备。微软公司技术研究员Dave Campbell在博客中对该技术的预期作用及设计原理做出了阐释，同时总结出四项创建原则：一、优化主内存数据访问;二、加快业务逻辑处理速度;三、提供无
在最近发布的DB2更新版本中，IBM已经加入了一套统称代号为BLU的加速技术，承诺让这个古老的数据库管理系统更适合于运行大型的内存数据分析工作。
在传统的数据库表中，由于磁盘的物理结构限制，表和索引的结构为B-Tree，这就使得该类索引在大并发的OLTP环境中显得非常乏力，虽然有很多办法来解决这类问题，比如说乐观并发控制，应用程序缓存，分布式等。但成本依然会略高。而随着这些年硬件的发展，现在服务器拥有几百G内存并不罕见，此外由于NUMA架
4月18日下午，在内存数据库分会场上，美国麦科捷有限公司(McObject)亚太区高级工程师黄东旭发表了主题为《eXtremeDB内存数据库性能提升方案分享》的精彩演讲。在本次演讲过程中，黄东旭结合eXtremeDB内存数据库技术为大家分享了内存数据库性能提升的方式，并强调了eXtremeDB内存数据库在一些应用领域的
MySQL Cluster在MySQL阵营已经有很悠久的历史了，但相对MySQL的广泛运用来说，它仅仅只是少数人的玩具，在线上的应用非常少，这其中的原因跟它是基于内存从而提高了机器成本有关，也跟在早期版本中它的运维比较困难有关，随着硬件成本的降低，新存储设备的革命以及它自身的改进，大规模的应用已成为可能
如果你是一个资深的SQL Server DBA，那么关于它的每一个功能你应该都会接触过至少一次。事实上，SQL Server发展到现在，它的根基并没有变，一个大树上长出纷繁的枝叶。今天的这篇文章，我将在这些“枝叶”中挑选几个我认为值得关注的，来仔细聊一聊。列存储索引(Columnstore Indexes)和Hekaton内存数据Google开源了一个kv存储的库leveldb | 学习笔记