Category: MySQL


Oracle收购了Sun,这无疑是最近业内的头等大事。Oracle从Sun那里得到了Solaris、Java、NetBeans等一批优秀的产品,当然也包括MySQL。于是担忧就来了,尽管作为最广泛使用的开源数据库,MySQL一直表现良好,但是Oracle无论如何也不会允许MySQL来和它既有的数据库产品竞争。许多人发帖子表示,MySQL将亡,更多的甚至预言,MySQL的死亡将带走PHP。业界形成了Microsoft、Oracle和IBM的三大阵营的格局。严重缺乏底层应用支撑的PHP与被Oracle遗弃的MySQL将被挤出历史舞台。

不过我认为事情没有想象的那么糟糕。一直以来,PHP和MySQL都是依赖开源社区的力量在发展,缺乏商业支持不可能导致这些产品终结。另外,MySQL一直占有中小型企业网站市场,本来就没有成为Oracle等数据库的正面竞争对手,Oracle未必会打压MySQL的发展。相反,他可能还会继续支持MySQL以利用他占领低端市场。

开源产品从来都是供那些愿意花时间精力但不愿意花钱的人玩的,经营开源产品的公司从来又是从愿意花钱不愿意花时间精力的人手里赚利润的。也就是说,Oracle完全可以让MySQL依赖社区自由发展,然后将不愿意投入时间和人力成本,希望付费购买支持的客户转化为Oracle的客户。当然这种设想有理想主义的成分,毕竟Oracle的定价策略决定了它面向中高端客户,可是从MySQL支持本身盈利也不是什么不可能的事情——原来Sun就是这么做的。

尝试驾驭Archive存储引擎

截止作者撰写本文的时候,MySQL5.0还仅在Max版本中支持Archive存储引擎。想了解您的MySQL支持何种存储引擎,您可以在MySQL客户端中输入SHOW ENGINES命令。

mysql> show engines;+------------+---------+----------------------------------------------------------------+| Engine     | Support | Comment                                                        |+------------+---------+----------------------------------------------------------------+| MyISAM     | YES     | Default engine as of MySQL 3.23 with great performance         || MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables      || HEAP       | YES     | Alias for MEMORY                                               || MERGE      | YES     | Collection of identical MyISAM tables                          || MRG_MYISAM | YES     | Alias for MERGE                                                || ISAM       | NO      | Obsolete storage engine, now replaced by MyISAM                || MRG_ISAM   | NO      | Obsolete storage engine, now replaced by MERGE                 || InnoDB     | DEFAULT | Supports transactions, row-level locking, and foreign keys     || INNOBASE   | YES     | Alias for INNODB                                               || BDB        | YES     | Supports transactions and page-level locking                   || BERKELEYDB | YES     | Alias for BDB                                                  || NDBCLUSTER | NO      | Clustered, fault-tolerant, memory-based tables                 || NDB        | NO      | Alias for NDBCLUSTER                                           || EXAMPLE    | NO      | Example storage engine                                         || ARCHIVE    | YES     | Archive storage engine                                         || CSV        | NO      | CSV storage engine                                             || FEDERATED  | YES     | Federated MySQL storage engine                                 || BLACKHOLE  | YES     | /dev/null storage engine (anything you write to it disappears) |+------------+---------+----------------------------------------------------------------+

为了测试Archive引擎压缩数据的效果,我们先以一个包含10万行数据的表为数据源,创建几种不同数据引擎的表,看看存储引擎的表现。先声明:以下的性能测试均是在一台拥有2GHz奔腾M处理器和1GB内存的Dell笔记本电脑上,运行WindowsXP系统和MySQL 5.0.10 β版。

mysql> create table test_myisam engine=myisam as select * from client_transaction_hist;Query OK, 112050 rows affected (1.06 sec)Records: 112050  Duplicates: 0  Warnings: 0

mysql> create table test_innodb engine=innodb as select * from client_transaction_hist;Query OK, 112050 rows affected (3.72 sec)Records: 112050  Duplicates: 0  Warnings: 0

mysql> create table test_archive engine=archive as select * from client_transaction_hist;Query OK, 112050 rows affected (1.92 sec)Records: 112050  Duplicates: 0  Warnings: 0

mysql> SELECT  table_name table_name,->         engine,->         ROUND(data_length/1024/1024,2) total_size_mb,->         table_rows-> FROM   information_schema.tables-> WHERE  table_schema = 'gim' and->        table_name like 'test%'-> ORDER BY 3;+--------------+---------+---------------+------------+| table_name   | engine  | total_size_mb | table_rows |+--------------+---------+---------------+------------+| test_archive | ARCHIVE |          1.64 |     112050 || test_myisam  | MyISAM  |          6.46 |     112050 || test_innodb  | InnoDB  |          9.52 |     112050 |+--------------+---------+---------------+------------+

可以看到,Archive表比MyISAM表要小大约75%,比支持事务处理的InnoDB表小大约83%。接下来再让我们将MyISAM表压缩,比较看看:

C:\Program Files\MySQL\MySQL Server 5.0\data\gim>..\..\bin\myisampack test_myisam.MYICompressing test_myisam.MYD: (112050 records)- Calculating statistics- Compressing file67.76%

+--------------+---------+---------------+------------+| table_name   | engine  | total_size_mb | table_rows |+--------------+---------+---------------+------------+| test_archive | ARCHIVE |          1.64 |     112050 || test_myisam  | MyISAM  |          2.08 |     112050 || test_innodb  | InnoDB  |          9.52 |     112050 |+--------------+---------+---------------+------------+

即便是启用了压缩之后,Archive表依然比MyISAM表小约7%。那么执行INSERT插入的速度呢?前面的例子使用CREATE TABLE … AS SELECT …语句向Archive表中插入数据时,性能表现不如MyISAM表好。但这是数据少的情况,当数据量非常大的时候Archive的插入性能表现会较MyISAM为佳。在接下来的例子里,我们要用一个存储过程插入100万行记录:

mysql> create table insert_test (c1 int, c2 varchar(20)) engine=myisam;Query OK, 0 rows affected (0.00 sec)

mysql> drop procedure test_insert;Query OK, 0 rows affected (0.00 sec)

mysql> delimiter //mysql> create procedure test_insert()-> begin-> declare v_ctr tinyint;-> set v_ctr = 0;-> while v_ctr <> do->     insert into insert_test values (1,'testing insert');->     set v_ctr = v_ctr + 1;-> end while;-> end-> //Query OK, 0 rows affected (0.00 sec)

mysql> delimiter ;mysql> call test_insert();Query OK, 1 row affected (33.06 sec)

mysql> truncate table insert_test;Query OK, 0 rows affected (0.01 sec)

mysql> alter table insert_test engine=archive;Query OK, 0 rows affectedRecords: 0  Duplicates: 0  Warnings: 0

mysql> call test_insert();Query OK, 1 row affected (21.42 sec)

正如你所看到的,在这个INSERT测试例子中,Archive引擎比MyISAM更快。在某些情况下,使用INSERT DELAYED(延迟写入)选项能让Archive引擎的插入速度更快。启用DELAYED选项时,Archive引擎会使用一个压缩缓冲区来保存插入的数据,这当然也能起到提高性能的作用。还有一种方法是直接对标准MyISAM表执行ALTER TABLE语句转换成Archive表:

mysql> alter table myisam_insert engine=archive;Query OK, 3000000 rows affected, 0 warning (8.84 sec)Records: 3000000  Duplicates: 0  Warnings: 0

上面的测试显示,将拥有300万行的MyISAM表转换成Archive表只花了不到9秒的时间,太棒了!

读取性能又如何呢?Archive和其他MySQL存储引擎相比较,有何不同?Archive表的第一个弊端是它不支持索引,所以任何SELECT指令都会扫描整个表。MySQL团队正在测试Archive表的索引支持,可能在更高的版本中会发布。但是到目前为止,唯一能帮助提高SELECT执行速度的就是MySQL查询缓存了。

我们来测试一下三种不同存储引擎的数据表(刚超过10万行)执行完全扫描的性能表现:

mysql> select count(*) from test_myisam where client_id = 50;+----------+| count(*) |+----------+|       24 |+----------+1 row in set (0.25 sec)

mysql> select count(*) from test_innodb where client_id = 50;+----------+| count(*) |+----------+|       24 |+----------+1 row in set (0.59 sec)

mysql> select count(*) from test_archive where client_id = 50;+----------+| count(*) |+----------+|       24 |+----------+1 row in set (0.41 sec)

Archive引擎似乎表现还不错,接下来我们测试一下扫描包含300万行数据的表:

mysql> select count(*) from myisam_insert where c1 = 1;+----------+| count(*) |+----------+|  3000000 |+----------+1 row in set (1.05 sec)

mysql> select count(*) from archive_insert where c1 = 1;+----------+| count(*) |+----------+|  3000000 |+----------+1 row in set (2.20 sec)

mysql> flush status;Query OK, 0 rows affected (0.00 sec)

mysql> select count(*) from archive_insert where c1 = 1;+----------+| count(*) |+----------+|  3000000 |+----------+1 row in set (0.00 sec)

mysql> show status like 'qcache_hits';+-------------------------+----------+| Variable_name           | Value    |+-------------------------+----------+| Qcache_hits             | 1        |+-------------------------+----------+

在上面的例子中,Archive表确实比MySQL表慢一些,但是它也在大约2秒的时间里完成了扫描。另外这个例子也表明,Archive表的扫描结果被放入了查询缓冲区。所以相同的查询请求几乎是立即得到回复(因为缓存命中)。

读取数据的时候,Archive引擎启用了一种称为“快照”的技术,这一点和InnoDB很相似。所以大量的并发读取操作不会阻止写入操作的执行。Archive表使用行锁定技术,这一点也和InnoDB一样。

Archive表的性能是否可能超过MyISAM?答案是肯定的。根据MySQL工程师的资料,当表内的数据达到1.5GB这个量级,CPU又比较快的时候,Archive表的执行性能就会超越MyISAM表。因为这个时候,CPU会取代I/O子系统成为性能瓶颈。别忘了Archive表比其他任何类型的表执行的物理I/O操作都要少。

记住一点,Archive存储引擎设计的出发点不仅是追求SQL查询时卓越的性能,而且更重要的是为备份提供便利。当我们需要备份历史数据的时候,Archive引擎能在实质上减少需要转移的数据量。

较小的空间占用也能在你移植MySQL数据的时候发挥作用。当你需要把数据从一台MySQL服务器转移到另一台的时候,Archive表可以方便地移植到新的MySQL环境,你只需将保存Archive表的底层文件复制过去就可以了。

背景

一直以来,数据库专家都为企业中飞速增长的商业数据所困扰。工业分析数据正以平均42%/年的速率递增,保守估计,某些地方增长速度已达百分之几百,且完全没有停止迹象。究竟是什么原因导致数据爆炸性地增长?

首先,企业都已意识到大量相关数据蕴含着巨大的价值,他们比从前任何时候都更愿意保留这些可以利用的数据。从决策层到执行层,几乎所有人都高度重视数据分析结果的战略价值。于是数据被导入数据仓库,商业情报人员不时地输入分析查询语句,为将来某个关键的商业决策搜集支持依据。

其次,政府章程,比如Sarbanes-Oxley法案、 HIPAA标准等,促成了一种通过保留不必要保留的操作记录来清查越权行为的习惯。为了避免违反联邦法案,企业、学校、非盈利组织都要求软件记录下操作员执行的每一个步骤,这自然为数据库管理员带来了巨大的负担——他们不得不管理这些漫无边际地增长的数据。

最后,政府还有一个让数据库专家摊上更多事情的职能,就是安全控制和数据审计。那些管理着海量数据仓库的企业官员常常得回答诸如“何人何时修改了什么”或者“何人何时查看了什么”这样的提问。那些拥有数以千计的员工,开展着不计其数的业务的企业,每天都会产生出大量的日志记录数据,而且必须将其好好保存。

为了帮助数据库专家应对数据爆炸的挑战,MySQL5.0引入了一种新的数据存储引擎,叫做Archive。这个先进的数据管理工具,让MySQL的专家们拥有了处理和管理海量数据的新式武器。

Archive存储引擎概览

MySQL5.0的Archive存储引擎是唯一一个被设计用来帮助数据库管理员对付企业和组织中的大量流水数据的存储引擎。让我们马上来看看那些令Archive存储引擎能轻松应对前述挑战的独有特性吧。

由于企业要管理大量无关联历史数据,“信息生命周期管理”的需要开始增强。信息生命周期管理(ILM)的基本方法是,将历史的数据和操作记录转移到离线存储仓库中,在必要的时候依然可以访问他们。 MySQL 5.0中新的Archive存储引擎是保存无关联数据和操作记录的完美解决方案。它使用了一种透明的压缩算法,让数据都保存在压缩的存档表中。

许多年来,MySQL的MyISAM数据表压缩技术提供了减少数据使用空间的方法。但Archive存储引擎比压缩的MyISAM更合适,因为:

  • MyISAM压缩技术要求数据库管理员离线操作,而Archive数据引擎无需数据库暂停服务。所以使用Archive能保证数据库无间断运行。
  • MyISAM的压缩需要myisampack工具在命令行中执行,而Archive的压缩只需要一个简单的数据库描述语言指令。
  • 压缩的MyISAM表是只读的,Archive则同时支持Select和Insert的操作。另外,Archive使用常量读的方式,所以读取操作不会锁定数据表,阻止写操作的执行。
  • 数据存储于Archive表比压缩的MyISAM更为高效,所以Archive的投资回报率更高。

那些被数据存档和安全备案任务所困扰的MySQL数据库管理员们会喜欢Archive数据存储引擎,因为他们将不再需要将历史数据备份到磁带以节省存档开销。而且,历史数据的价值也可以得到提升,因为调用这些数据的时候无需先将数据从磁带还原到磁盘。

除了拥有简单易用的压缩特性之外,Archive存储引擎也是数据审计的最佳选择。Archive表只支持SELECT和INSERT操作,系统安全官员和审计员一定会非常乐于这样,毕竟审计工作要求严格保证原始数据不可更改。Archive表正好提供了这种限制——数据既无法修改又不能选择性地删除,换句话说,不可人为干预。

其他数据库厂商也提供数据表或数据库的压缩功能,但没有一个像MySQL的Archive存储引擎一样是直接为数据存档审计设计的。比如,Oracle从9.2版开始,引入了“压缩表”,但是它不具备数据审计的特性——只支持SELECT和INSERT。微软的SQL Server数据库管理员可以利用操作系统的压缩功能来减少数据库文件占用的磁盘空间量,不过偶有报告的数据损坏的情况吓阻了许多人。MySQL的Archive表的使用更为简单,完全不需要操作系统介入,能有效预防数据变更,保障数据可靠安全。

所以,不论是数据仓库、数据存档、还是数据审计的应用场合,全新的MySQL5.0 Archive存储引擎都是保障数据安全储存的最佳选择。在诸多数据存储产品中,它拥有最高的投资回报率。

本文自MySQL网站文章翻译而来,您可以查看原文下一篇文章将继续介绍Archive存储引擎的试用情况。

Powered by WordPress. Theme: Motion by 85ideas.