我为什么选择innodb

以下分析内容，仅针对MYSQL

以下分析资料，仅本人观点

如有错误或疑问敬请发送到：tc-ql@163.com，非常感谢

 

 

 

这里所提到的存储引擎（STORAGE ENGINE）或数据库，可以理解为不同的表，某种类型的表。

 

 

 

OLTP DATABASE

 

ARCHIVE：

         归档存储引擎，用于存储归档信息，压缩算法将数据压缩下降到20%的原始大小，因此存储大量数据特性最为突出，但是数据只能读取，不能改变（可更新删除和替换）。不支持索引，支持序列，不支持崩溃恢复。

 

适合的应用场景：

1.       小型（GB级的表或1000亿行一下的单表）数据仓库

2.       Web2.0日志应用。

3.       数据审计

 

优点

缺点

没有存储量的限制

不支持事务

存储成本最小的存储引擎

仅支持序列，不支持索引

写入速度最快的基于磁盘的引擎

不支持崩溃恢复

严格保护UPDATE/DELETE操作

不支持在线热备

基于大表的全表查询速度快于MYISAM

不支持外键

行级锁

不支持UPDATE/DELETE操作

MVCC多版本读取支持

不支持内存缓冲技术

 

 

 

Blackhole（除DBA外，无任何用途）：

         Blackhole存储引擎接收传入数据，但不保存数据，开启日志状态下会计入日志。主要功能进行数据复制起到安全或者特殊中转作用。不支持事务。

         无任何目的的存储引擎，同时在复制中转架构中也需要慎用。

 

CSV：

         支持读取CSV数据结构的文件，可以使用SQL语言进行分析。日志可以写成CSV结构的，用数据库分析，我就那么干的。

 

Memory：

         内存表，数据完全存储在内存，崩溃或重启数据丢失。很少有实用价值。

 

Merge：

         针对MYISAM，可以将相同MYISAM表结构的表组织成一个单表。这是一个稳定的存储引擎，它不支持事务。只对MYISAM有用。

 

 

MYISAM：

         MYISMA在5.5之前一直是默认存储引擎，快速的装载数据和读取数据，不支持事务和自动灾难恢复。不支持访问频繁，数据库设计中又存在耗时的SQL的设计或场景。

 

适合的应用场景：

1.       Web2.0

2.       小型数据仓库

3.       嵌入式应用

4.       硬件设备

5.       博客

6.       日志

7.       认证系统

 

 

优点

缺点

没有存储限制，依赖于文件系统限制

不支持事务

存储小号低

表级锁

支持BTREE和空间索引，全文索引

不支持崩溃恢复

非常快的写入性能

不支持在线热备

非常快的查询性能

不支持外键

SELECT COUNT(*)最快，永远是０秒

耗时的ＳＱＬ会阻塞其他ＳＱＬ

支持前缀索引

 

 

 

IBM DB2I：

         MYSQL DBA都会管理操作DB2，原因就是他们两完全兼容相同的。

         由于IBM 平台昂贵的价格这里无视之。

 

 

 

InnoDB STORAGE ENGINE:

 

       Innodb存储引擎是由INNOBASE开发公司所拥有，目前隶属于甲骨文公司。Innodb存储引擎是用来处理交易型应用的，拥有自动崩溃恢复功能，保持数据的完整性，高并发控制和良好的响应时间。Innodb是完全开源的自由软件，其提供GPL许可同意任何人对其进行修改和重新分配。

       2008年4月，一种新的插件版本的innodb存储引擎正式发布，该版本具有新的数据压缩行的格式和更快的创建索引的能力。

       截止我整理这篇文章为止，mysql版本为5.5.14，其INNODB存储引擎已经支持快速的创建索引，更好的并发机制，这是在5.5之前没有的。

 

适合的应用场景：

1.     Web2.0事务交易应用

2.     电子商务应用

3.     财政金融应用

4.     医疗应用

5.     零售应用

6.     嵌入式事务交易应用

 

已经应用在：

1.     金融证券

2.     电子商务

3.     教育

4.     能源

5.     国防部

6.     医疗

7.     制造业

8.     传播媒体

9.     零售业

10.  技术工业

11.  电信业

12.  旅游业

13.  Web2.0 等

 

优点

缺点

ACID事务支持

在线备份工具增加成本

支持数据自动崩溃恢复

不支持全文索引和空间索引

数据存储限制64TB/表空间

 

支持外键

 

行级锁

 

MVCC多版本读取支持

 

在线热备

 

支持数据缓存

 

支持聚集索引

 

 

 

 

 

分布式数据库：

       Mysql cluster是一种真正的分布式应用数据库，无单点高可用，是为对系统崩溃恢复支持要求极其严格的应用而设计的。无共享存储格式，内存采用同步复制技术，以提供高达99.999%的可用性，数据主要存放在内存中，为查询和数据处理提供快速的反应时间。

 

适合的应用场景：

1.     电信系统

2.     Web2.0

3.     Web session系统

4.     嵌入式事务系统

5.     搜索引擎

6.     贸易和投资管理交互系统

7.     在线游戏

 

已经应用于：

1.     电信行业

2.     互联网

3.     电子商务

4.     贸易投资

5.     零售业

 

优点

缺点

ACID事务支持

不支持事务

无共享存储

表级锁

分布式数据存储支持

索引只能存放在内存中

快速的自动恢复数据

不支持外键

支持数据自动崩溃恢复

不支持全文索引和空间索引

内存级数据库性能

 

支持BTREE和HASH索引

 

行级锁

 

快速的基于主键的查询速度

 

直接使用专用API访问数据性能更高

 

 

 

 

 

以下数据库请勿考虑：

       Maria：这玩意儿是一个未来计划，谢谢，请在未来去使用。

 

 

       PBXT：可选架构只有复制，他的复制设计的不好，复制需要改进，等改进后使用，innodb仍然可替代他。

 

 

Falcon:存储容量限制，支持并发，但最好不好出现并发，并发能力不行。Innodb可以直接替代他。

 

 

Federated:分布式表定义，允许远程表访问MYSQL服务器结构相同的表，类似于oracle DBLINK。目前为止最好不要应用于生产系统，其质量和性能均存在问题。

 

 

Scale：它是迄今为止，相当完美的一个数据库，简单的说与ORACLE RAC一样，支持关系型数据模型的几乎全部理论，并且支持大型WEB应用，拥有强大的云计算能力。至今仍是一个梦想，还在开发测试。并且他不是开源的。

 

 

 

 

 

DATA WAREHOUSE/BI OLAP

 

Calpont:

       它是一个多线程，扩展的，分布式的数据库，专门为分析数据仓库设计。可以部署在单台服务器上火部署在多机的网格体系结构中，使其良好的向外扩展的能力，与能够真正具有运行大规模并行处理（MPP系统）的能力。采用列导向存储架构，大大降低的I/O解析查询。

 

应用于：

1.     数据仓库

2.     历史数据分析报表

 

优点

 

 

 

 

 

 

 

 

 

 

 

 

个人首选，网格计算，多机并行。

 

 

Infobright-brighthouse:

       我其实已经在使用，数据压缩比10:1，也是列式存储，没有上面的数据库好。

       实际上TB级数据他就不是很好了，与传说中的50TB相差甚远。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25379809/viewspace-703993/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25379809/viewspace-703993/