123
 123

2008-04-23 Wed

23:25 Efficient Boolean value storage for Innodb Tables (70505 Bytes) » MySQL Performance Blog

Sometimes you have the task of storing multiple of boolean values (yes/now or something similar) in the table and if you get many columns and many rows you may want to store them as efficient way as possible.
For MyISAM tables you could use BIT(1) fields which get combined together for efficient storage:

PLAIN TEXT
SQL:
  1. CREATE TABLE `bbool` (
  2.   `b1` bit(1) NOT NULL,
  3.   `b2` bit(1) NOT NULL,
  4.   `b3` bit(1) NOT NULL,
  5.   `b4` bit(1) NOT NULL,
  6.   `b5` bit(1) NOT NULL,
  7.   `b6` bit(1) NOT NULL,
  8.   `b7` bit(1) NOT NULL,
  9.   `b8` bit(1) NOT NULL,
  10.   `b9` bit(1) NOT NULL,
  11.   `b10` bit(1) NOT NULL
  12. ) ENGINE=MyISAM
  13.  
  14. mysql> SHOW TABLE STATUS LIKE 'bbool' \G
  15. *************************** 1. row ***************************
  16.            Name: bbool
  17.          Engine: MyISAM
  18.         Version: 10
  19.      Row_format: Fixed
  20.            Rows: 10
  21.  Avg_row_length: 7
  22.     Data_length: 70
  23. Max_data_length: 1970324836974591
  24.    Index_length: 1024
  25.       Data_free: 0
  26.  AUTO_INCREMENT: NULL
  27.     Create_time: 2008-04-24 00:41:01
  28.     Update_time: 2008-04-24 00:45:40
  29.      Check_time: NULL
  30.       Collation: latin1_swedish_ci
  31.        Checksum: NULL
  32.  Create_options:
  33.         Comment:
  34. 1 row IN SET (0.00 sec)

As you can see for MyISAM 10 columns take just 7 bytes - less than a byte per column. This is just minimum row length we can have for this table - myisam_data_pointer_size is 6 default plus we need space for delete flag which makes 7 minimum row size MyISAM can have in this configuration.

This trick however does not work for Innodb which allocates 1 byte for each BIT(1) column. So we can get 1 byte per column for boolean flag storage in Innodb (not accounting for standard row overhead) if we use BIT(1), TINYINT or ENUM types but can we do better ?

In fact we can - by using CHAR(0) type (without NOT NULL flag) - this will be pretty much column containing NULL bit only which can store one of two values - NULL or Empty String.

Lets see how these 3 different table format look in Innodb (I've populated each with some 2M rows so difference is more visible)

PLAIN TEXT
SQL:
  1. CREATE TABLE `tbool` (
  2.   `t1` tinyint(4) NOT NULL,
  3.   `t2` tinyint(4) NOT NULL,
  4.   `t3` tinyint(4) NOT NULL,
  5.   `t4` tinyint(4) NOT NULL,
  6.   `t5` tinyint(4) NOT NULL,
  7.   `t6` tinyint(4) NOT NULL,
  8.   `t7` tinyint(4) NOT NULL,
  9.   `t8` tinyint(4) NOT NULL,
  10.   `t9` tinyint(4) NOT NULL,
  11.   `t10` tinyint(4) NOT NULL
  12. ) ENGINE=InnoDB
  13.  
  14. CREATE TABLE `cbool` (
  15.   `c1` char(0) DEFAULT NULL,
  16.   `c2` char(0) DEFAULT NULL,
  17.   `c3` char(0) DEFAULT NULL,
  18.   `c4` char(0) DEFAULT NULL,
  19.   `c5` char(0) DEFAULT NULL,
  20.   `c6` char(0) DEFAULT NULL,
  21.   `c7` char(0) DEFAULT NULL,
  22.   `c8` char(0) DEFAULT NULL,
  23.   `c9` char(0) DEFAULT NULL,
  24.   `c10` char(0) DEFAULT NULL
  25. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  26.  
  27. mysql> SHOW TABLE STATUS LIKE "%bool%" \G
  28. *************************** 1. row ***************************
  29.            Name: bbool
  30.          Engine: InnoDB
  31.         Version: 10
  32.      Row_format: Compact
  33.            Rows: 2097405
  34.  Avg_row_length: 37
  35.     Data_length: 78233600
  36. Max_data_length: 0
  37.    Index_length: 0
  38.       Data_free: 0
  39.  AUTO_INCREMENT: NULL
  40.     Create_time: 2008-04-24 00:54:18
  41.     Update_time: NULL
  42.      Check_time: NULL
  43.       Collation: latin1_swedish_ci
  44.        Checksum: NULL
  45.  Create_options:
  46.         Comment: InnoDB free: 6144 kB
  47. *************************** 2. row ***************************
  48.            Name: cbool
  49.          Engine: InnoDB
  50.         Version: 10
  51.      Row_format: Compact
  52.            Rows: 2097678
  53.  Avg_row_length: 34
  54.     Data_length: 71942144
  55. Max_data_length: 0
  56.    Index_length: 0
  57.       Data_free: 0
  58.  AUTO_INCREMENT: NULL
  59.     Create_time: 2008-04-24 00:37:48
  60.     Update_time: NULL
  61.      Check_time: NULL
  62.       Collation: latin1_swedish_ci
  63.        Checksum: NULL
  64.  Create_options:
  65.         Comment: InnoDB free: 4096 kB
  66. *************************** 3. row ***************************
  67.            Name: tbool
  68.          Engine: InnoDB
  69.         Version: 10
  70.      Row_format: Compact
  71.            Rows: 2097405
  72.  Avg_row_length: 37
  73.     Data_length: 78233600
  74. Max_data_length: 0
  75.    Index_length: 0
  76.       Data_free: 0
  77.  AUTO_INCREMENT: NULL
  78.     Create_time: 2008-04-24 00:58:01
  79.     Update_time: NULL
  80.      Check_time: NULL
  81.       Collation: latin1_swedish_ci
  82.        Checksum: NULL
  83.  Create_options:
  84.         Comment: InnoDB free: 6144 kB
  85. 3 rows IN SET (0.11 sec)

As you can see table which uses BIT(1) column type takes same space as the one which uses TINYINT NOT NULL while CHAR(0) is about 10% smaller. This is modest space savings of course but considering large per row overhead Innodb has this will transform to much larger savings if you have hundreds of such columns.

Lets see how things look for MyISAM for same tables:

PLAIN TEXT
SQL:
  1. mysql> SHOW TABLE STATUS LIKE "%bool%" \G
  2. *************************** 1. row ***************************
  3.            Name: bbool
  4.          Engine: MyISAM
  5.         Version: 10
  6.      Row_format: Fixed
  7.            Rows: 2097152
  8.  Avg_row_length: 7
  9.     Data_length: 14680064
  10. Max_data_length: 1970324836974591
  11.    Index_length: 1024
  12.       Data_free: 0
  13.  AUTO_INCREMENT: NULL
  14.     Create_time: 2008-04-24 01:14:06
  15.     Update_time: 2008-04-24 01:14:09
  16.      Check_time: NULL
  17.       Collation: latin1_swedish_ci
  18.        Checksum: NULL
  19.  Create_options:
  20.         Comment:
  21. *************************** 2. row ***************************
  22.            Name: cbool
  23.          Engine: MyISAM
  24.         Version: 10
  25.      Row_format: Fixed
  26.            Rows: 2097152
  27.  Avg_row_length: 7
  28.     Data_length: 14680064
  29. Max_data_length: 1970324836974591
  30.    Index_length: 1024
  31.       Data_free: 0
  32.  AUTO_INCREMENT: NULL
  33.     Create_time: 2008-04-24 01:14:13
  34.     Update_time: 2008-04-24 01:14:17
  35.      Check_time: NULL
  36.       Collation: latin1_swedish_ci
  37.        Checksum: NULL
  38.  Create_options:
  39.         Comment:
  40. *************************** 3. row ***************************
  41.            Name: tbool
  42.          Engine: MyISAM
  43.         Version: 10
  44.      Row_format: Fixed
  45.            Rows: 2097152
  46.  Avg_row_length: 11
  47.     Data_length: 23068672
  48. Max_data_length: 3096224743817215
  49.    Index_length: 1024
  50.       Data_free: 0
  51.  AUTO_INCREMENT: NULL
  52.     Create_time: 2008-04-24 01:14:23
  53.     Update_time: 2008-04-24 01:14:26
  54.      Check_time: NULL
  55.       Collation: latin1_swedish_ci
  56.        Checksum: NULL
  57.  Create_options:
  58.         Comment:
  59. 3 rows IN SET (0.00 sec)

As you can see for MyISAM BIT(1) NOT NULL type is as compact as CHAR(0) while TINYINT NOT NULL is a bit less compact.

Looking at results of these tests using CHAR(0) is the most efficient if you would like optimal structure both for MyISAM and Innodb tables, however it is not as convenient to work with. Using NULL as one of flag values means you can't use normal "=" comparison operator with them:

PLAIN TEXT
SQL:
  1. mysql> SELECT count(*) FROM cbool WHERE c1=NULL;
  2. +----------+
  3. | count(*) |
  4. +----------+
  5. |        0 |
  6. +----------+
  7. 1 row IN SET (0.20 sec)

You can use IS NULL operator which is painful because you need to have different query based on parameter (IS '' would not work) or you can use Null-Aware comparison operator:

PLAIN TEXT
SQL:
  1. mysql> SELECT count(*) FROM cbool WHERE c1<=>NULL;
  2. +----------+
  3. | count(*) |
  4. +----------+
  5. |  1048576 |
  6. +----------+
  7. 1 row IN SET (0.22 sec)

Should you go and change all flags to use this approach ? I do not think so - for most applications using TINYINT BIT(1) or ENUM for flags benefit would unlikely be worth the trouble. Due to complication I also would not recommend as a base approach for new applications. However in special cases if you have very many rows and very many flag values to deal with which you can't pack to the bitmask this approach can be quite helpful.

Entry posted by peter | No comment

Add to: delicious | digg | reddit | netscape | Google Bookmarks

22:28 Conference for MySQL Users (3924 Bytes) » MySQL Performance Blog

If you're following PlanetMySQL you've already seen Baron's post about MySQL Conference which many of us just have returned from.
It was great event as well as 5 conferences I've been before that, though however it more and more becomes MySQL marketing channel and business event rather than Users Conference as it originated. This Year even name was changed to be MySQL Conference and Expo though I have not noticed it until Baron pointed out :)

There is nothing wrong with MySQL Conference and Expo - there are product conferences out where for pretty much any mature product with large user base, however it may not put users interest first any more.
I've been talking to a a lot of people and many inside MySQL/Sun and out share the same opinion so we thought we should organize one.

I would like to see the conference which is focused on the product users interests rather than business interests of any particular company (or personal interests of small group of people), I would like it to be affordable so more people can attend and I'd like to see it open so everyone is invited to contribute and process is as open as possible.

Just chatting about idea in the blog comments is poor way to make things happen so we organized OurSQL Google Group which is open for everyone interested in discussing organization of such conference (or set of conferences in different locations) to join. We named the group after Sheeri's podcast - though conference name may change in the future. We just wanted to avoid using "MySQL" term due to potential trademark issues.

You can also check Arjens post on the same issue.

Entry posted by peter | No comment

Add to: delicious | digg | reddit | netscape | Google Bookmarks

18:35 Avoid storing Markup (HTML) in the database (1285 Bytes) » Fenng's shared items in Google Reader
I see this to often; Storing HTML in the database. Then UI wants to change the HTML, but the data grew to 100 GB, so the really only feasible way to change the HTML is via a post process after the database fetch. This post process produces a huge list of preg_replace statements to rebuild the HTML on display. This consumes a lot of memory over time and slows down the APP, plus its time consuming to debug.


Store URLS if the apps need to. Or better yet build the schema to store the bare minimum the app needs to generate the HTML.

Here is a compelling reason why not to store HTML:

The data needed to generate the HTML is 10 bytes, but the TEXT field consumes 1024 bytes, all of which is the same text.

Thus for an app that should cost very little to maintain now costs 10 times as much.

If your building a search engine strip out the HTML and store the text. If its a quick app, take this saying into account

The is nothing more Permanent then a temporary solution


A exception that I don't mind: php serialize - this is markup that (rarely) does not change.
17:20 MySQL 5.1.24 rc版本中已取消集群功能 (865 Bytes) » Fenng's shared items in Google Reader
thinkc 写道 "一位叫Klaus Keppler的用户在4月17日23时36分向MySQL提交了一份bug报告（Bug #36187），内容是在刚刚释出的mysql-5.1.24-rc二进制版本中已经找不到ndb等涉及集群搭建的命令文件。 MySQL的Daniel Fischer在3分钟后即给予了答复，“这是有意为之，我们将不在MySQL 5.1中提供MySQL集群支持，而会推出一个基于MySQL 5.1的独立的MySQL集群产品，它将包含更多更高级的集群特性。社区二进制版本也将照此处理。” 看来真的是离开MySQL,投入PostgreSQL怀抱的时候了。不过目前pgcluster、slony等PostgreSQL集群软件无论在搭建方便性还是稳定性适用性等方面的确还是与MySQL集群软件存在一些差距。"
14:53 Video: Mark Little on SOA (1588 Bytes) » Red Hat Magazine

We hope you’ve enjoyed our videos from JBoss World–here’s one more. While we were in Orlando, we talked with Dr. Mark Little, technical development manager for the SOA (service-oriented architecture) platform at Red Hat. Little talks about these highly adaptable and agile environments, and the (government) customers that require them. He also details how MetaMatrix additions serve this project, and what kinds of tools and applications will be supported in the future.

Download this video: [Ogg Theora]



14:42 Oracle Critical Patch Update - April 2008 - E-Business Suite Impact (2160 Bytes) » Oracle Security Blog

Oracle released the fourteenth Critical Patch Update (CPU) last week.  This quarter is the same as the previous thirteen with many patches and long hours in order to get all the security patches applied in a timely manner.  Around 20 of the 41vulnerabilities fixed impact the Oracle E-Business Suite.  Fortunately like the last few quarters, this quarter there are no new Oracle Application Server or Developer 6i patches required for the Oracle E-Business Suite 11i.

Integrigy discovered 8 of the 11 Oracle E-Business Suite vulnerabilities, which were reported to Oracle in November 2007.

This quarter does have a higher than average number of database vulnerabilities that can be exploited by lowly privileged database accounts, although even if it was just one vulnerability the database security patch should still be a priority. 

Oracle continues the push to keep all customers on recent versions by only certifying the CPU patches with 9.2.0.8, 10.1.0.5, 10.2.0.3, and 11.1.0.6 for the database and ATG_PF.H RUP5, or RUP6 for the Oracle E-Business Suite 11i.

More information about the vulnerabilities and detailed recommendations on patching and testing is available at -

Oracle Oracle Critical Patch Update - April 2008 - E-Business Suite Impact

Oracle Critical Patch Update - April 2008 - Version Support Matrix

I will be presenting an OAUG eLearning Community Thursdays session on Thursday, May 1 giving additional information on the CPU and its impact on your Oracle Applications implementation.  OAUG members can sign-up for the session at -

http://secure.meetingexpectations.com/oaug/eLearning/elSchedule.aspx?DayOfWeek=5&mtd=5/1/2008

14:28 Real-Life Use Case for “Barracuda” InnoDB File Format (5498 Bytes) » MySQL Performance Blog

In one of his recent posts Vadim already gave some information about possible benefits from using new InnoDB file format but in this post I'd like to share some real-life example how compression in InnoDB plugin could be useful for large warehousing tasks.

One of our clients had really many problems with one of his servers. This is pretty powerful server (Intel Xeon E5430 / 8Gb RAM / BBU-enabled RAID10 with fast SAS drives) with really interesting dataset on it. The only table customer has on this server is one huge innodb table with a set of TEXT fields. We've been trying to optimize this server before by playing with various innodb parameters (including page size changes) but at the end of the day server was dying of I/O load because dataset size was 60Gb+ and all reads from this table were pretty random (buffer pool didn't help).

Few days ago we've decided to try to convert customer's data to Barracuda file format using new InnoDB plugin recently released by Oracle. First thing I've tried was DYNAMIC row format. After 3,5 hours of conversion we've got 58Gb data file and 30% drop in our I/O load. This was related to the fact that with DYNAMIC row format InnoDB was able to keep an entire PRIMARY index in memory (TEXT and BLOB fields are stored off-page in this format) and all our lookups weren't involving random I/O anymore.

This 30% I/O reduction was nice, but we've decided to go further with our optimizations and I've tried to convert this table using COMPRESSED row format. This time conversion took 1,5 hours and results were really surprising:

  • Only 5Gb data file (from 60Gb)
  • ~5% I/O load according to iostat (from 99%)
  • ~5% CPU load according to top (from 80-100% mostly waiting for I/O)
  • 0.01 sec average lookup time by primary key (from 1-20 sec before the conversion)

These interesting performance results obviously come from the fact that in addition to index pages compression (by default it is trying to compress 16kb pages down to 8kb) new innodb plugin performs TEXT/BLOB/VARCHAR fields compression off-page so every large TEXT field could become as small as a few bytes if its compression ratio is good. One thing I'd like to mention here that in our case we've actually tried a few possible options for compressed page sizes: 1k, 4k and 8k. Results were not so different because most of our data was in TEXT fields and there weren't many other indexes aside from PRIMARY, but for some other cases it could make sense to try other page sizes (not default 8k) to make data set smaller.

So far, so good, customer is really happy with these changes and we're really glad to have such a nice tool as new InnoDB plugin which now proved its usefulness in data warehousing tasks.

Entry posted by Alexey Kovyrin | 3 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

14:20 Google的高可扩展架构与海量数据处理 (3628 Bytes) » NinGoo@Net

Author:NinGoo posted on NinGoo.net

Google需要处理数据真正可以称得上海量，这依赖于其分布式的高扩展架构，否则，再强的小型机大型机也扛不住互联网每天产生的“信息垃圾”。Google的Jeff Dean同学为我们解密了Google的高可扩展性架构，ppt可以从这里下载。

一、底层架构

负载并行分配到多个硬件机器上
软件必须采用容错处理，不依赖具体的某一个台机器运行
大量采用刀片服务器和PC Server，低端存储和网络设备
机器追求性价比而不是盲目的高性能
基于Linux

二、分布式系统

调度系统：Scheduling System
调度系统是一个底层支撑系统，负责调度监控Cluster资源

文件存储：GFS
Master节点负责管理文件系统元数据
Chunkserver存放具体数据，以64MB为单元分布
客户端通过master查找文件
客户端直接从chunkserver获得需要的数据
目前运行超过200套GFS群集
超过5000台机器
超过5PB数据
为10000台以上客户端提供服务

数据存储：BigTable
采用多维稀疏映射图模型，每一个数据单元Cell可以存储不同时间截的数据
将表按行分隔成Tablet，分布到不同服务器上存储
底层存储架构采用GFS
Master节点处理元数据和负载均衡
Tablet服务器存储数据
锁服务器(Lock Service)控制数据访问的一致性
超过500个数据单元
最大的单元存储超过6000TB的数据，使用了超过3000台机器
最忙的单元支撑了500000次以上的操作

数据处理：MapReduce
MapRedule是Google的批量数据处理工具，分为两大功能

  • 映射(Map)：根据输入生成(key,value)键值对
  • 简化(Reduce)：合并存储(key,value)键值对

MapReduce用于Google的大多数产品中，包括Google Earth,News,Analytics,Search Quality,Indexing等等

目前，调度系统/GFS/BigTable/MapReduce可以在同一个群集内协同工作

三、未来的发展方向

跨越数据中心的分布式系统
更高的自动化程度


Related Articles

Add Comments(0) | Follow NinGoo@Twitter

bookmark

09:53 Testing InnoDB “Barracuda” format with compression (27276 Bytes) » MySQL Performance Blog

New features of InnoDB - compression format and fast index creation sound so promising so I spent some time to research time and sizes on data we have on our production. The schema of one of shards is

PLAIN TEXT
SQL:
  1. CREATE TABLE `article87` (
  2.   `id` bigint(20) UNSIGNED NOT NULL,
  3.   `ext_key` varchar(32) NOT NULL,
  4.   `site_id` int(10) UNSIGNED NOT NULL,
  5.   `forum_id` int(10) UNSIGNED NOT NULL,
  6.   `thread_id` varchar(255) CHARACTER SET latin1 NOT NULL,
  7.   `published` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  8.   `crawled` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  9.   `subject` varchar(255) NOT NULL,
  10.   `title` varchar(255) NOT NULL,
  11.   `url` varchar(255) NOT NULL,
  12.   `num_links` smallint(6) NOT NULL,
  13.   `links_in` int(10) UNSIGNED NOT NULL,
  14.   `cache_author` varchar(255) NOT NULL,
  15.   `cache_site` varchar(255) DEFAULT NULL,
  16.   `anchor` varchar(255) NOT NULL,
  17.   `isthread` tinyint(3) UNSIGNED NOT NULL,
  18.   `author_id` int(10) UNSIGNED NOT NULL,
  19.   `inserted` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  20.   `fromfile` varchar(255) NOT NULL,
  21.   `language_id` tinyint(3) UNSIGNED NOT NULL,
  22.   `encoding` varchar(255) NOT NULL,
  23.   `warning` mediumtext NOT NULL,
  24.   `is_thread_start` tinyint(3) UNSIGNED NOT NULL,
  25.   `source` mediumint(8) UNSIGNED NOT NULL,
  26.   `hash` char(32) NOT NULL,
  27.   `mod_is` tinyint(3) UNSIGNED NOT NULL DEFAULT '0',
  28.   `is_adult` tinyint(3) UNSIGNED NOT NULL DEFAULT '0',
  29.   `bodyuc` mediumtext NOT NULL,
  30.   PRIMARY KEY (`id`),
  31.  KEY `ext_key` (`ext_key`),
  32.  KEY `forum_id` (`forum_id`,`thread_id`,`published`),
  33.  KEY `site_id` (`site_id`,`published`),
  34.  KEY `hash` (`hash`),
  35.  KEY `forum_id_2` (`forum_id`,`is_thread_start`,`published`),
  36.  KEY `published` (`published`),
  37.  KEY `inserted` (`inserted`),
  38.  KEY `forum_id_3` (`forum_id`,`thread_id`,`is_thread_start`),
  39.  KEY `site_id_2` (`site_id`,`author_id`)
  40. ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

in fact this is not exact schema - difference is we are using DEFAULT CHARSET=utf8, which seems not working with fast index creation (bug 33650) , so I use latin1 for tests. Also we actually store 'bodyuc' as compressed field, doing compress()/uncompress() to store/restore. To test InnoDB compression I use only uncompressed text, though I tested compression on compress()-ed data just to see if there is any benefit from index compression.

For test I use dump created with mysqldump, final size 30286M.
To create InnoDB compression table I use ENGINE=InnoDB KEY_BLOCK_SIZE=8 and to test fast index creation I create table only with primary key, without additional indexes.

Numbers I got:

load dump into table with default format and all indexes (case 1) - 152m34.792s
size of final .ibd file for (case 1) - 43032M

What if load data and indexes separately:

load dump into table with default format and without indexes (case 2a) - 59m12.575s
size of .ibd after (case 2a) - 36968M
create all indexes (case 2b) - 18min46.05s
size of .ibd after (case 2b) - 40400M

So as you see time to load (case 2) (with fast create index way) is faster almost two times and space decreased by 6%.

Now with compressed table:

load dump into table with default format and all indexes (case 3) - 228m55.251s (time took 1.5 times longer than (case 1) )
size of final .ibd file for (case 3) - 16284M (space ratio is 0.37 compare to (case 1) )

What if load data and indexes separately:

load dump into table with default format and without indexes (case 4a) - 71m10.760s (longer 1.2 times than (case 2a))
size of .ibd after (case 4a) - 13208M (smaller 0.35 times)
create all indexes (case 4b) - 42m54.63sec (longer 2.28 times)
size of .ibd after (case 4b) - 14968M (smaller 0.37 times)

Total time for (case 4) , 6844 sec, took 1.46 times longer than (case 2) , 4678 sec, but space decreased by even more ( 0.37 from original)

Also interesting to note that fast index creation allows to load time two time faster than usual load.

Ok, There are a lot of numbers, let me summarize it:

Test Load time, sec Size, MB
Baseline (1), default format, usual load 9154 43032
default format, fast index creation 4678 (0.51)* 40400 (0.93)
compress format, default load 13735 (1.50) 16284 (0.38)
compress format, fast index creation 6844 (0.74) 14968 (0.35)

* - ratio to baseline

So in conclusion
- Fast Index creation allows to speedup load 2 times (even indexes fit into memory)
- Load in compress format slower by 30-50%
- Table in compress format takes only 1/3 of original table

Of course we also expect significant performance gain for I/O bound queries in case of compression tables, this is topic for different research.

Entry posted by Vadim | 3 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

09:00 读书日晒一下书单 (3856 Bytes) » DBA notes

作者：Fenng 发布在 dbanotes.net. FeedBurner 订阅数量,点击则可进行订阅

今天是世界读书日。不说技术这些无聊的东西了，晒一下今年以来在卓越亚马逊上的购书清单。

* 德川家康/第六部双雄罢兵
* 山南水北
* 漫长的告别
* 乡土中国--故园徽州
* 德川家康--第五部.龙争虎斗
* 大败局（修订版）
* 激荡三十年--中国企业(下)
* 鹿鼎记(共5册新修版)/口袋本金庸作品集
* 激荡的百年史（插图珍藏本）
* 汪曾祺谈吃
* 德川家康4：兵变本能寺
* 乌合之众：大众心理研究（最新版本）
* 抗战时代生活史
* 中国古代文化常识（插图典藏本）
* 痛风的诊断与治疗/临床常见病症诊疗丛书
* 银元时代生活史
* 魔鬼经济学
* 德川家康3：天下布武

看来这段时间就和《德川家康》较劲了。另外比较喜欢韩少功《山南水北》的恬淡。《银元时代生活史》传递出来的生活趣味也很有意思，和去年看过的《侠隐》有的一比。

发现自己对书的评语基本上分"好看"与"不好看"，如何好看? 有趣，如何有趣? 好看...

--EOF--

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：
最近作者还说了什么? Follow Twitter / Fenng

07:27