0
0

One size does not fit all

jametong 发表于 2013年03月16日 15:43 | Hits: 1765
Tag: oracle | tradeoff

To date, nobody has ever discovered a data layout that is efficient for all usage patterns.As a general rule, simpler data layouts are often faster to write, while fancier ones can boost query performance. Specific tradeoffs include, but hardly are limited to:

  • Big blocks of data compress better, and can be also be faster to retrieve than a number of smaller blocks holding the same amount of data. Small blocks of data can be less wasteful to write. And different kinds of storage have different minimum block sizes.
  • Operating on compressed data offers multiple significant efficiencies. But you have to spend cycles (de)compressing it, and it’s only practical for some compression schemes.
  • Fixed-length tabular records can let you compute addresses rather than looking them up in indexes. Yay! But they also waste space. Tokenization can help with the fixed-/variable-length tradeoff.
  • Pointers are wonderfully efficient for some queries, at least if you’re not using spinning disk. But they can create considerable overhead to write and update.
  • Indexes, materialized views, etc. speed query performance, but can be costly to write and maintain.
    Storing something as a BLOB (Binary Large OBject), key-value payload, etc. is super-fast — but if you want to look at it, you usually have to pay for retrieving the whole thing.

总的来讲,无法做到一招鲜走天下,总是面临不同的选择与权衡,得到这个,则会失去那个。

要通用,一定会牺牲一些特定场景的优化;要专用,则使用场景少,投入的产出相对较少。面向行存储,OLTP效率高,OLAP牺牲大;面向列存储,则OLTP的业务牺牲大(内存数据库要稍好点),OLAP的整体效率高。

No related posts.

原文链接: http://feedproxy.google.com/~r/dbthink/~3/gN-M4cz4_4E/825

0     0

我要给这篇文章打分:

可以不填写评论, 而只是打分. 如果发表评论, 你可以给的分值是-5到+5, 否则, 你只能评-1, +1两种分数. 你的评论可能需要审核.

评价列表(0)