SSD应该是近几年来硬件技术最nb的革命，困扰计算机性能的最短木板－－磁盘IO终于有了巨大的突破。而且SSD在未来的几年中会快速普及（我还琢磨着给我笔记本换SSD）。 前一段cm同学也想做一个MVCC支持的k-v数据库 ，现有的数据库都是根据几年前的硬件水平（小内存、无NUMA、机械磁盘）进行的设计的，不可能针对SSD专门优化，SSD上的MySQL性能提升应该是只用了SSD IOPS超高这一个特性。在SSD未来几年应该能广泛普及的前提下，针对SSD的数据库优化是必须的。集中查了查资料，聊聊想法，有不对的地方欢迎各位补充。

昨天下午的技术讨论会上说到了数据库的按时间点的进行实时备份和归档，当时的讨论都是基于日志如何来做。 这个问题需要做到以下几点： 因备份而引起的中断数据库服务的时间尽可能短; 能够迅速的让数据库使用备份的数据rollback; 归档的备份数据能在专门的备份机统一保存，方便本机失效后的处理; 如果可能，归档备份的数据能做到增量备份，以节省备份机的磁盘空间，同时方便快速传输。 从数据库本身解决这个问题，可能受困于已有的数据库设计和代码，不非常容易。换个思路，可以基于fs的snapshot来做。 在*nix系统下功能最强的snapshot首推zfs，本身支持文件系统快照，支持增量备份，并内置了zfs send工具能直接把备份快照、或增量备份快照发送到另外一台物理机器上（也必须是zfs）。但必须使用FreeBSD 8以上或者是 OpenSolaris。但是由于公司的机器都是GNU/Linux的，退而求其次选择LVM。 在家里的E8200 + Debian 6.0.0 i386系统上做了测试，首先是使用lvm创建分区，创建了一个名为main的60GB大小的Volume Group，同时在里面建立了一个名为main0的10GB的Logical Volume挂载“/”，并格式化为ext3。 拷入6GB的数据文件，然后创建snapshot： # lvcreate -s -L 7G -n snap-`date +%Y%m%d%H` /dev/main/main0 这一步消耗时间只有0.5s左右，而且测试了拷入20GB的数据文件，snapshot时间基本无变化，详细看截图： 然后在/dev/main/下新加入了snap-`date +%Y%m%d%H` LVM逻辑卷，可以挂载此snapshot分区： # mount /dev/main/snap-`date +%Y%m%d%H` ~/backup 随后就可以tar成gzip包，然后rsync集中保存了。 删除snapshot: # umount -f ~/backup# lvremove /dev/main/snap-`date +%Y%m%d%H` 对于数据库的操作来说，拿MySQL举例： # mysql –uroot –p -h localhost mysql> flush […]

收集下已知的NoSQL自由软件/开源软件项目：