2008-11-17 Mon
CCTV是一家邪恶的媒体，但你不能不承认它巨大的影响力和压迫力。它曾经搬倒过分众无线，不管其动机是什么，至少它让群发垃圾短信这种生意，无法登堂入室成为主流商业模式。现在，它的炮口对准了百度。这一次，百度可能不得不面对它有史以来最严重的一次危机，不是公关危机，而是更本质的商业模式和商业道德的危机。
百度迅速处理了医疗、医药类关键词的竞价排名，反应不可谓不快。有报道称，对涉嫌违规操作竞价排名的相关业务责任人，百度还会进行内部处理。但这些都只是皮毛，只要竞价排名仍然是百度的核心商业模式，它就永远摆脱不了层出不穷的质疑和曝光，不可能改变被动挨打的局面。如果百度的“天条”从根本上与其商业模式相冲突，那么我相信，所谓“用户体验第一”中的用户，一定是付了费的用户。商业的驱动力在这里起着至关重要的作用，它决定了销售人员的行为模式，也决定了一个企业是否总是不得不背离自己最初的理念。
竞价排名的弊端，网上已经有大量的讨论，除了商业欺诈、无效点击等问题，更关键问题是，花钱可以收买搜索结果，让技术创新的努力变得一钱不值。设想一下，一个是经过大量复杂计算的最符合用户需求的结果，一个是企业花钱买到的结果，应该把哪个结果优先提供给用户？不同的商业逻辑决定了不同的处理方式。竞价排名的商业强势，让完善算法的努力变得没有必要，最终，一个企业被一种模式绑架。
百度遭受的质疑，不管有多少来自竞争对手的操作，终归是因为它自身有缺陷。而且，这种质疑由来已久，只不过这一次是CCTV。
对百度来说，这是一道艰难的选择题，无论怎么选择都会是痛苦的。今年第三季度，百度以竞价排名为核心的网络营销收入9.182亿元，占总收入的99.9%。可以说，百度就是一家以竞价排名为核心商业模式的互联网营销公司。放弃竞价排名？这一2001年9月推出的商业模式，铸就了百度过去8年的辉煌。放弃，谈何容易。
但是别无选择。据说李彦宏也早就意识到了竞价排名的问题，阻碍百度刮骨疗毒的根本原因，仍然是把商业利益看得太重。
根据艾瑞的调查，今年第三季度百度的网页搜索请求量市场占有达73.2%，谷歌为20.8%，前者为后者的3.5倍。不过，两者收入的差距却要小得多。百度三季度的网络营销收入为9.182亿元，谷歌为4亿元（数据来自易观），前者只是后者的2.3倍。这说明，将搜索结果与广告严格区分开，并不必然影响企业的商业利益。
置之死地而后生。百度，请拿出你的勇气。
2008-11-16 Sun
Fenng(dbanotes) posted a photo:
2008-11-14 Fri
作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复
Perl是一门非常适合用来写数据库管理脚本的语言, Shell当然也很强, 但在这个领域还是没有Perl好. 来讲一个最简单的需求, 需要取得Standby或Dataguard上最后一个应用的归档日志, 在普通恢复和Managed恢复方式都要支持, 这个需求并不容易准确地实现. 如果用Perl来分析Oracle的alert日志文件, 则比较容易. 如下所示:
sub getLastRecoveredLog
{
my ($alert_log_file) = @_;
my $logseq = "???";
my $lastline = `tail -1000 ${alert_log_file} | grep "Media Recovery Log" | tail -1`;
if (defined($lastline))
{
$lastline =~ s/.*\///g;
my @cols = ($lastline =~ /\w+_\d?_(\d+)[\.|_]/);
if (defined($cols[0]))
{
$logseq = $cols[0];
$logseq = $logseq - 1;
}
}
scalar $logseq;
}
如要删除已经应用过的归档日志, 那么只需要再写一个根据Sequence查找归档日志位置的函数就行了.
sub findLogBySequence
{
my ($logseq) = @_;
my $logfile = `find /data*/arch -follow -name *_${logseq}.* | head -1`;
chomp($logfile);
# Foloowing logic is for Oracle 10g
if (length($logfile) == 0)
{
$logfile = `find /data*/arch -follow -name *_${logseq}_* | head -1`;
chomp($logfile);
}
scalar $logfile;
}
先找出所有要删除的归档日志, 存在变量中, 然后根据Sequence从小删到大就行了.
相关文章 | Related Artiles
我要留言(当前1)
2008-11-13 Thu
我相信，所有在中国经营的互联网公司，都至少有一个这样的大客户，它是你的上帝，它让你怎么做，你就得怎么做，它让你屏蔽什么，你就得当机立断地屏蔽什么，它让你捧谁，你就得欢天喜地地捧谁。没错，它就是监管部门。他们如太上皇一般，对企业指手画脚，要求企业做这做那。在很多时候，不是企业在控制用户能看到什么，而是他们。
搜索，本来是个技术活儿，需要长期不断地调整算法，努力通过技术手段，而不是人工，将用户最需要的结果呈现给用户。但在中国，不人工干预结果，比马丁·路德·金的那个梦，还难实现，监管部门的一道圣旨，要比所有的算法重要1000倍。所以，监控、删除、屏蔽，成了中国互联网公司的一项基本功。而且这个大客户脾气古怪，今天让你捧的，明天可能就要你屏蔽，你永远都要对它弯腰低头，笑脸相迎，否则有你好看。
如果这个大客户需要企业特别保护，那么别的客户为什么就不可以呢？如果这个大客户有权，那么别的客户有钱行不行？
也许，这就是国情，就是中国特色。是这个大客户帮助中国互联网公司练就了删除、屏蔽的基本功，也是这个大客户让中国互联网公司学会了看客户脸色行事。现在，他们又要求企业讲道德。拜托，您真的对自己的道德水准那么有信心？有你们这种无法无天的大客户在，中国企业的道德水准怎么可能高得起来。
2008-11-07 Fri
作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复
eBay的chao_ping在Oracle-l中问如何节约历史库的空间, 经过了10年的发展, eBay的历史库积累了100多TB的数据, 并且数据的增幅很大, 虽然历史库用不着很好的存贮, 但这笔成本还是比较大的. 已经使用了压缩表将常规的表的空间压缩到了三分之一到六分之一, 但其中有一半的数据是用LONG或LONG RAW类型存放的, 没有办法用压缩表. 想想再过几年, 这样的历史库空间问题, 也会面临在很多的DBA前面.
在Oracle中比较花存贮的有如下方面:
字段编码. 不要小看这个字段编码, 比如状态字段, 用"E"和用"ENABLE"来表示, 当然后者更好读了, 生产库中应用开发人员可能偏向于后者, 但到历史库中时, 不如转换成前者. 其实一个表中一般不止一个这样的状态字段. 因此我将这个摆在第一位.
索引. 在生产库上就有些索引, 用得很少, 但每次要用, 都是比较重要的情况, 因此不得不心不由己地加索引, 历史库也有一样的情况. 其实有时不如引进针对某类记录的附加表, 来解决大表的索引问题.
LOB列. 大量的LOB不光是耗性能, 也是很耗空间的, 因为LOB的最小分配单位是一个数据块, 两个LOB值没有办法共享一个数据块. 如果是CLOB, 在变长字符集中存放大量英文文本的话, 浪费更严重, 一个英文字母在LOB中存放需要占用两个字节, 不管是INLINE还是OUTLINE.
LONG列. 有LONG的列没有办法压缩, 在插入记录时, Oracle也会过量使用空的数据库, 因而浪费空间. 用utl_compress将值取出来, 再存到LONG RAW中或RAW中, 也是不错的选择.
垃圾数据. 数据库中肯定多多少少会有垃级记录, 象天文数字交易额的交易记录等等, 要筛选这些记录, 过程可能过于复杂, 所以就留了它们.
当然应对的办法, 也就随之而出了, 压缩及11g中的新的LOB格式. 也许可以将所有的字段进行序列化, 然后存在一个字段中, 要查询时用应用来解开这些字段. 过段时间也好好分析一下我们的历史库, 想想有没有办法省钱.
相关文章 | Related Artiles
我要留言(当前0)
