评论: 弄清楚你的业务类型——OLTP or OLAP

作者: 木匠

木匠 — Tue, 29 May 2007 20:28:53 +0000

两点问题需要深究:

1)数据库扩展是困难的，而应用服务器扩展是简单的。其实，也就是说，在高可用的OLTP环境中，数据库使用越简单的功能越好.

–Best practice:
请搜索和参考 Database API, 将数据处理集中在数据库完成, Java mid tier layer 只是调用 PL/SQL package (Database API).
数据库就是设计用来处理数据的,很多功能+性能远远强于 Java or C#.

2)OLTP 和 table/index partition

OLTP 可以使用 Table Partition,
便于日常数据维护,archive, 降低Contention.

即使Global Partition Index 也可以降低B Tree level, 加速Index Scan.
请查看 AnySQL 的技术博客, 有详细测试和解释.

作者: piner

piner — Wed, 30 May 2007 00:26:35 +0000

1、如果你这样，只会加重数据库的业务负担，在一些小的数据库系统上，这样做是可以的，但是，在一些大的，高业务访问的系统上，你这样做，就是让数据库死。
2、分区在oltp中，我不赞成使用的，除非你有很特别的数据类型，如日志，正好可以根据日志时间来分区，方便归档。
但是，你说全局索引可以提高访问性能，这个是没有任何道理的，呵呵，全局索引中保存的rowid长度还是10个字节的，比普通索引要多4个字节，这点你要清楚。
另外，分区是需要另外付费的。

作者: Talmud

Talmud — Wed, 30 May 2007 01:40:53 +0000

好文，总结的很好，获益良多。

作者: wdjk1999

wdjk1999 — Wed, 30 May 2007 02:40:29 +0000

PINER,问题是现在很多系统都模糊了这两种的界限啊，既有ＯＬＡＰ，又有ＯＬＴＰ

作者: piner

piner — Wed, 30 May 2007 02:57:44 +0000

[quote]PINER,问题是现在很多系统都模糊了这两种的界限啊，既有ＯＬＡＰ，又有ＯＬＴＰ[/quote]

这样的系统应当是有的，但是不多，如果这样的系统存在，那很多时候是因为功能分工不明确，或者是数据量，访问量都很小。这个时候，综合考虑一下即可，利用各个部分的优点。

作者: jacky

jacky — Wed, 30 May 2007 07:25:53 +0000

收录下了，谢谢

作者: newboy

newboy — Wed, 30 May 2007 08:29:36 +0000

tom不是说能在数据库中实现的就尽量在数据库中实现吗?

作者: piner

piner — Wed, 30 May 2007 08:40:00 +0000

tom的很多说法，在一些高并发，高业务量的oltp系统上，都是行不通的。

他的技术，是针对一般的小应用的。

作者: Fenng

Fenng — Wed, 30 May 2007 09:24:40 +0000

OLAP 和 DSS 也是有不少差别的

作者: piner

piner — Wed, 30 May 2007 12:05:49 +0000

[quote]OLAP 和 DSS 也是有不少差别的[/quote]

这两个定义现在基本一致了,不过DSS更早一些,现在基本都叫OLAP

作者: anysql

anysql — Wed, 30 May 2007 12:20:41 +0000

要让他们跑得快, 都有DBA的任务, 这是共同点.

作者: piner

piner — Wed, 30 May 2007 13:12:15 +0000

恩,这就是你与我存在的原因.

作者: 木匠

木匠 — Wed, 30 May 2007 16:52:19 +0000

[quote]tom的很多说法，在一些高并发，高业务量的oltp系统上，都是行不通的。
他的技术，是针对一般的小应用的。[/quote]

洗耳恭听. 请举出两三个例子, 和 complete small test case,
我真的非常有兴趣, 用事实说明问题, I always ask for proof, and maintain an open mind too.

比如: In search of the truth:
http://asktom.oracle.com/pls/ask/download_file?p_file=3067171813508366601

Piner 兄弟很果断呀, 还好, 没有删掉我的评论, 哈哈, 一笑而过.

作者: piner

piner — Thu, 31 May 2007 00:45:37 +0000

呵呵，我为什么要删除评论？

例子很多的，我当然没有说tom是错的，但是，不同的时候，的确要注意不同的用法，tom是oracle公司的人，他的主张当然是用oracle实现一切。
但是，数据库最容易成为瓶颈，就是再高端的机器，挡不住几千台web server的，而且，他们基本可以无限制的加下去，数据库想扩展，分布？太难，不是不可以，成本非常大。

那么，我就拿一个tom经常用的例子来说明，tom在更新大批量数据的时候，主张采用最快的方式，尽量减少提交次数。这个做法，很多时候是对的，如数据仓库，停机维护，时间是宝贵的。

但是，在线系统上，你要更新100w条数据，你就不能这么做了，你要考虑这个表的压力，是否有复制，是否有触发器，是否有应用的dump等等。

更新数据的时候，还可能要根据压力，刻意的减慢更新速度，而且，更不能尽量的少提交了，而是要多提交，多提交的意思不是说每条提交一次，如，你可以1000条提交一次，减少对表的锁时间。

当然，很多人说，数据回滚的问题，数据回滚是有很多办法的，如你可以把你要更新的数据先备份起来，比如你可以分段更新，最重要的是，你要弄清楚为什么要更新，更新的风险在哪里。

作者: piner

piner — Thu, 31 May 2007 00:46:08 +0000

更多的例子，在我的书里面。

作者: 木匠

木匠 — Thu, 31 May 2007 05:50:38 +0000

[quote]更新数据的时候，还可能要根据压力，刻意的减慢更新速度，而且，更不能尽量的少提交了，而是要多提交，多提交的意思不是说每条提交一次，如，你可以1000条提交一次，减少对表的锁时间。[/quote]

这完全是数据建模设计的问题.

作者: piner

piner — Thu, 31 May 2007 06:05:20 +0000

[quote]
这完全是数据建模设计的问题.[/quote]

但是，的确是在现实情况中，要去做的事情，其实，我最不主张死记硬背，生搬硬套，什么情况下，需要怎么用，再根据实际情况去决定。

我经常说的，技术做到最后，就如太极，不要去想招数了。