世界（top500）强服务器的排名

在2006年超级计算机大会SC06开幕前一天，TOP500org提前公布了第28次超级计算机五百强名单，其中前十位的排行发生了重大变化，因为TOP10中的新秀有7款之多，而且两款新的AMD Opteron系统占据了第二和第九。
超级计算机TOP500的计算性能依然在飞速提升，这次第10名的平均计算能力为5420TFlpos，第500名也有2734TFlops，比上次的 203TFlops增加347％之多，而第100名的665TFlops如果放在2003年甚至可以跻身TOP10。
整体而言， TOP500的总计算能力比上次提升56％，其中前十名受影响较大。排名第一的仍是美国能源部劳伦斯利物莫国家实验室(LLNL)的“蓝色基因/L”系统 (BlueGene/L)，峰值计算能力3670TFlops，平均2806TFlops；新科亚军是美国Sandia国家实验室的“红色风暴” (Red Storm)，由超级计算机制造商Cray采用13277颗24GHz双核心Opteron处理器打造而成，峰值计算能力1274TFlops，虽然只有蓝色基因的347％，但却是史上第二台超越100TFlops的超级计算机；IBM的一套新蓝色基因系统“BGW”夺得季军，峰值计算能力也超过了 100TFlops大关，达到1147TFlops。
IBM的Cell系统不但拿下了冠军和季军，还占据了TOP10中的另外两个位置，在TOP500中也有93套。
排名第六的是戴尔“Thunderbird”(雷鸟)系统，基于Intel Xeon 36GHz处理器，这也是Intel平台的最高排名。TOP500中的Intel平台从上次的301台减少到263台，其中Itanium系统从37台减少到35台，不过基于最新Woodcrest Xeon 5100的系统已经开始上榜。
凭借近年来在服务器领域内的优异表现和杰出的计算性能，AMD的Opteron处理器已经在TOP500中占据了113个席位，上次只有81个。另外，PA-RISC平台20套、Alpha平台3套、富士通研发的Sparc平台3套，Sun的10套系统则全部采用了x86处理器。
(ARMONK，纽约)——近日，在IDC最新公布的世界最强功能超级计算机排行榜上，IBM的上榜数量在所有的生产商名列第一，几乎是排名第二位的公司(New HP)上榜数量的两倍。IDC的排行榜上共有304种IBM eServer系统，而新HP公司有171种，Sun公司则只有89种。此外，IDC的“平衡等级基准”也进一步证明了：一台32路IBM eServer p690服务器的性能强于Sun Fire 15K和HP Superdome，而其处理器数量仅仅是这些服务器的一半。
“IBM在超级计算领域的成功来自一个简单的哲学——我们制造超级计算机的目的是用来处理各种商业和技术环境下的超级计算应用。”IBM eServer基准测试部主管David Gelardi说，“只要更多的公司借助于超级计算机来处理大型数据挖掘和其它重要应用，IBM就会在此重要领域内继续保持其领先地位。”
排行榜上的IBM超级计算机包括从单机系统到512台计算机的大型集群。在单机水平上，32路IBM eServer p690与72路Sun Fire 15K与64路HP Superdome相比，显示出了非凡的优越性。IBM eServer p690由POWER4微处理器支持，是第一种“一个芯片上的服务器”，它包括2个1GHz以上的处理器，1个大带宽系统开关，1个大内存缓冲器和I/O接口。也正是因为p690的独特设计，它的出现才改变了UNIX业界的游戏规则。
IDC的这个排行榜也符合超级计算机前500强排名结果。超级计算机前500强的排名由来自美国田纳西州大学的Jack Dongarra和德国曼海姆大学的Hans Meuer两位超级计算专家公布，每年公布两次。这500种计算机都是世界上功能最强、性能最好的计算机，在最新的前500强排名中，IBM系统占了160种——超过其它所有生产商。
IBM还透露，他们正打算在不久的将来建立“蓝色基因/L”——一个200 Tflop(1Tflop等于每秒进行一万亿次计算)的超级计算机。目前，它的一些相关基础技术正在IBM研究中心和美国Lawrence Livermore国家研究室的共同开发中。此外，IBM也正在为各项生命科学工程建造一台Pflop级(每秒钟完成千万亿次 *** 作)蓝色基因机器。

数据库吧，你用什么数据库
mysql可以配合lucene做搜索引擎，还不够大可以用cluster一般你用like没问题，索引要做得好。
如果大家有异议，可以在后面补充。我会随时更新的。
现在大概列出如下:(望各位补充)
1数据库的设计
尽量把数据库设计的更小的占磁盘空间
1)尽可能使用更小的整数类型(mediumint就比int更合适)
2)尽可能的定义字段为not null,除非这个字段需要null（这个规则只适合字段为KEY的情形）
3)如果没有用到变长字段的话比如varchar,那就采用固定大小的纪录格式比如char（CHAR 总是比VARCHR快）
4)表的主索引应该尽可能的短这样的话每条纪录都有名字标志且更高效
5)只创建确实需要的索引。索引有利于检索记录，但是不利于快速保存记录。如果总是要在表的组合字段上做搜索，那么就在这些字段上创建索引。索引的第一部分必须是最常使用的字段如果总是需要用到很多字段，首先就应该多复制这些字段，使索引更好的压缩。
（这条只适合MYISAM引擎的表，对于INNODB则在保存记录的时候关系不大，因为INNODB是以事务为基础的，如果想快速保存记录的话，特别是大批量的导入记录的时候）
6)所有数据都得在保存到数据库前进行处理。
7)所有字段都得有默认值。
8)在某些情况下,把一个频繁扫描的表分成两个速度会快好多。在对动态格式表扫描以取得相关记录时，它可能使用更小的静态格式表的情况下更是如此。
(具体的表现为：MYISAM表的MERGE类型，以及MYISAM和INNODB通用的分区，详情见手册)
9)不会用到外键约束的地方尽量不要使用外键。
2系统的用途
1)及时的关闭对MYSQL的连接。
2)explain 复杂的SQL语句。（这样能确定你的SELECT 语句怎么优化最佳）
3)如果两个关联表要做比较话，做比较的字段必须类型和长度都一致（在数据庞大的时候建立INDEX）
4)LIMIT语句尽量要跟order by或者 distinct这样可以避免做一次full table scan
5)如果想要清空表的所有纪录,建议用truncate table tablename而不是delete from tablename
不过有一个问题，truncate 不会在事务处理中回滚。因为她要调用create table 语句。
（Truncate Table 语句先删除表然后再重建，这个是属于文件界别的，所以自然快N多）
实测例子：
song2为INNODB表。
mysql> select count(1) from song2;
+----------+
| count(1) |
+----------+
| 500000 |
+----------+
1 row in set (091 sec)
mysql> delete from song2;
Query OK, 500000 rows affected (1570 sec)
mysql> truncate table song2;
Query OK, 502238 rows affected (017 sec)
mysql>
{
这一点手册上有详细解释：
1329 TRUNCATE语法
TRUNCATE [TABLE] tbl_name
TRUNCATE TABLE用于完全清空一个表。从逻辑上说，该语句与用于删除所有行的DELETE语句等同，但是在有些情况下，两者在使用上有所不同。
对于InnoDB表，如果有需要引用表的外键限制，则TRUNCATE TABLE被映射到DELETE上；否则使用快速删减（取消和重新创建表）。使用TRUNCATE TABLE重新设置AUTO_INCREMENT计数器，设置时不考虑是否有外键限制。
对于其它存储引擎，在MySQL 51中，TRUNCATE TABLE与DELETE FROM有以下几处不同：
· 删减 *** 作会取消并重新创建表，这比一行一行的删除行要快很多。
· 删减 *** 作不能保证对事务是安全的；在进行事务处理和表锁定的过程中尝试进行删减，会发生错误。
· 被删除的行的数目没有被返回。
· 只要表定义文件tbl_namefrm是合法的，则可以使用TRUNCATE TABLE把表重新创建为一个空表，即使数据或索引文件已经被破坏。
· 表管理程序不记得最后被使用的AUTO_INCREMENT值，但是会从头开始计数。即使对于MyISAM和InnoDB也是如此。MyISAM和InnoDB通常不再次使用序列值。
· 当被用于带分区的表时，TRUNCATE TABLE会保留分区；即，数据和索引文件被取消并重新创建，同时分区定义（par）文件不受影响。
TRUNCATE TABLE是在MySQL中采用的一个Oracle SQL扩展。
}
6)能使用STORE PROCEDURE 或者 USER FUNCTION的时候（ROUTINE总是减少了服务器端的开销）
7)在一条insert语句中采用多重纪录插入格式而且使用load data infile来导入大量数据，这比单纯的indert快好多（在MYSQL中具体表现为：INSERT INTO TABLEQ VALUES (),(),();）
（还有就是在MYISAM表中插入大量记录的时候先禁用到KEYS后面再建立KEYS,具体表现语句：
ALTER TABLE TABLE1 DISABLE KEYS;ALTER TABLE TABLE1 ENABLE KEYS;
而对于INNNODB 表在插入前先 set autocommit=0;完了后：set autocommit=1;这样效率比较高。）
8)经常OPTIMIZE TABLE 来整理碎片
9)还有就是date 类型的数据如果频繁要做比较的话尽量保存在unsigned int 类型比较快。
3系统的瓶颈
1)磁盘搜索
并行搜索,把数据分开存放到多个磁盘中，这样能加快搜索时间
2)磁盘读写(IO)
可以从多个媒介中并行的读取数据。
3)CPU周期
数据存放在主内存中这样就得增加CPU的个数来处理这些数据。
4)内存带宽
当CPU要将更多的数据存放到CPU的缓存中来的话,内存的带宽就成了瓶颈
====
Another article more about tuning details:
>

有人删了千万级的数据，结果导致频繁的慢查询。

线上收到大量慢查询告警，于是检查慢查询的SQL，发现不是啥复杂SQL，这些SQL主要针对一个表，基本都是单行查询，看起来应该不会有慢查询。这种SQL基本上都是直接根据索引查找出来的，性能应该极高。

是否可能慢查询不是SQL问题，而是MySQL生产服务器的问题？特殊情况下，MySQL出现慢查询还真不是SQL问题，而是他自己生产服务器的负载太高，导致SQL语句执行慢。比如现在MySQL服务器的

磁盘I/O负载高，每秒执行大量高负载的随机I/O，但磁盘本身每秒能执行的随机I/O有限，导致正常SQL在磁盘执行时，若跑一些随机IO，你的磁盘太忙，顾不上你了，导致你本来很快的一个SQL，要等很久才能执行完毕，这时就可能导致正常SQL也变成慢查询。

也许网络负载高，导致你一个SQL语句要发到MySQL，光是等待获取一个和MySQL的连接，都很难，要等很久或MySQL自己网络负载太高，带宽打满，带宽打满后，你一个SQL也许执行很快，但其查出来的数据返回给你，网络都送不出去，也会变成慢查询。

若CPU负载过高，也会导致CPU过于繁忙去执行别的任务，没时间执行你的SQL。

所以慢查询不一定是SQL本身导致，若觉得SQL不应该会慢查询，结果他那个时间段跑这个SQL 就是慢，应排查当时MySQL服务器的负载，尤其看看磁盘、网络及 CPU 的负载，是否正常。

当某个离线作业瞬间大批量把数据往MySQL里灌入的时，他一瞬间服务器磁盘、网络以及CPU的负载会超高。

此时你一个正常SQL执行下去，短时间内一定会慢查询，类似问题，优化手段更多是控制你导致MySQL负载过高的那些行为，比如灌入大量数据，最好在业务低峰期灌入，别影响高峰期的线上系统运行。

但看了下MySQL服务器的磁盘、网络以及CPU负载，一切正常，似乎也不是这问题导致。看起来无解了？

慢 SQL 的头两步排查手段：

这两种办法都不奏效之后，第三步：用MySQL profilling工具去细致的分析SQL语句的执行过程和耗时。

这个工具可以对SQL语句的执行耗时进行非常深入和细致的分析

打开profiling，使用

接着MySQL就会自动记录查询语句的profiling信息。此时若执行show profiles，就会给你列出各种查询语句的profiling信息，会记录下来每个查询语句的query id，所以你要针对你需要分析的query找到对他的query id，我们当时就是针对慢查询的那个SQL语句找到了query id。

然后针对单个查询语句，看其profiling信息，使用show profile cpu, block io for query xx，这里的xx是数字，此时就可以看到具体的profile信息。

除了cpu以及block io以外，还能指定去看这个SQL语句执行时候的其他各项负载和耗时。

会给你展示出来SQL语句执行时候的各种耗时，比如磁盘IO的耗时，CPU等待耗时，发送数据耗时，拷贝数据到临时表的耗时等，SQL执行过程中的各种耗时都会展示。

检查该SQL语句的profiling信息后，发现问题，其Sending Data耗时最高，几乎使用1s，占据SQL执行耗时的99%！其他环节耗时低可以理解，毕竟这种简单SQL执行速度真的很快，基本就是10ms级别，结果跑成1s，那肯定Sending Data就是问题根源！

这Sending Data在干啥呢？

MySQL官方释义：为一个SELECT语句读取和处理数据行，同时发送数据给客户端的过程，简单来说就是为你的SELECT语句把数据读出来，同时发送给客户端。

但这过程为啥这么慢？profiling确实是提供给我们更多的线索了，但似乎还是没法解决问题。但已经捕获到异常关键点，就是Sending Data的耗时很高！

接着：

看innodb存储引擎的一些状态，此时发现一个奇怪的指标：history list length，值特别高，达到上万。

MVCC就是多个事务在对同一个数据， 有人写，有人读，此时可以有多种隔离级别，对一个数据有个多版本快照链条，才能实现MVCC和各种隔离级别。

所以当你有大量事务执行时，就会构建这种undo多版本快照链条，此时history list length就会很高。然后在事务提交后，会有一个多版本快照链条的自动purge清理机制，清理了，该值就会降低。一般该值不应过高，所以注意到第二个线索：history list length过高，即大量的undo多版本链条数据没有清理。推测可能有的事务长时间运行，所以其多版本快照不能被purge清理，进而导致history list length过高。

经过这俩线索推测，在大量简单SQL变成慢查询时，SQL因为Sending Data环节异常，耗时过高；同时此时出现一些长事务长时间运行，大量的频繁更新数据，导致有大量undo多版本快照链条，还无法purge清理。

因为发现有大量的更新语句在活跃，而且有那种长期活跃的长事务一直在跑而没有结束，问了下系统负责人，在后台跑了个定时任务：他居然开了一个事务，然后在一个事务里删除上千万数据，导致该事务一直在运行。

这种长事务的运行会导致你删除时，仅只是对数据加了一个删除标记，事实上并没有彻底删除。此时你若和长事务同时运行的其它事务里再查询，他在查询时可能会把那上千万被标记为删除的数据都扫描一遍。因为每次扫描到一批数据，都发现标记为删除了，接着就会再继续往下扫描，所以才导致一些查询语句很慢。

那为何你启动一个事务，在事务里查询，凭什么就要去扫描之前那个长事务标记为删除状态的上千万的垃圾数据？讲道理，那些数据都被删了，跟你没关系了呀，你可以不去扫描他们 嘛！

而问题症结在于，那个 删除千万级数据的事务是个长事务 ！即当你启动新事务查询时，那个删除千万级数据的长事务一直在运行，它是活跃的！结合MVCC的Read View机制，当你启动一个新事务查询时，会生成一个Read View。你的新事务查询时，会根据ReadView去判断哪些数据可见及可见的数据版本号，因为每个数据都有个版本链条，有时你能可见的仅是这个数据的一个 历史 版本。

所以正是因为该长事务一直在运行，还在删除大量数据，而且这些数据仅是逻辑删除，所以此时你新开事务的查询还是会读到所有逻辑删除数据，也就会出现千万级的数据扫描，导致了慢查询！

所以禁止在业务高峰期运行那种删除大量数据的语句，因为这可能导致一些正常的SQL都变慢查询，因为那些SQL也许会不断扫描你标记为删除的大量数据，好不容易扫描到一批数据，结果发现是标记为删除的，于是继续扫描下去，导致慢查询！

直接kill那个正在删除千万级数据的长事务，所有SQL很快恢复正常。此后，大量数据清理全部放在凌晨执行，那个时候就没什么人使用系统了，所以查询也很少。

服务器多了
比如大型web服务器。一般硬盘挂5个360g的硬盘就可以，服务器硬盘（7200转以上），4核以上。2g内存以上。大概在7000++，不带显卡
如果是网吧的游戏和服务器，那就简单的多。一般硬盘大点。cpu都不用太好。1g。不用显卡
如果是游戏公司的服务器
估计，大概也得7000+++
如果是网吧无盘网络的上网服务器。
那要看你要带动几台机器。试情况而定
如果的如果是普通上网服务器。只要过了奔4就可以了

首先要确定你的目标，所谓千万级是每秒千万次查询还是千万条记录的数据库，前者是一个极其复杂的，这个不是光告mysql能解决的，我想不是前者，而后者却是很简单的一件事，前提是定义高效，定义两个指标：

1，每秒查询的次数是多少

2，每次查询时长

确定好以后再考虑以下几个因素的优化

1，存储的类型，SSD比普通磁盘的随机读写能力可以提高不少，一般2到3个数量级，还要看索引和数据块的大小，比较复杂

2，先择RAID类型，如果选raid0和raid10可以提升近似1倍的速度

3，使用高带宽的网速，可以减少网络传输延迟，用10g的光纤比1g的电缆理论上可以提升1个数量级的吞吐量，尤其对大数据据量的结果集特别有效

4，合理的索引，带条件的检索字段加上索引

5，用大宽表，尽可能减少多表关联查询，用空间换时间吧

6，_用主从的集群，基本上查询的并发量和服务器的数量成正比的

7，使用缓存，如memcached，尤其对静态数据提升尤其明显

8，合理选择数据库字段的类型，用定长字字，不要用变长的，如定长的int,char,decimal类型，别用varchar,text等

9，给数据库配置更大的内存

10，检查下瓶颈在不在CPU，如果查询复杂，换个更高配置的服务器

总的原刚就是，尽可能用内存替代碰盘提升IO速度，提高网络和CPU的配置以减少查询时间；尽可能提升网络速度，内存和主机的数量以提高并发

我们先探讨非高并发量的实现。

对于查询频次较高的字段，加上索引。

加索引注意事项：

1对那些字符内容较长的最好不要加索引

2按照官方文档，单表加的索引不要超过16个，索引的长度不要超过256个字节。

随意加索引，会给数据维护增加负担

其实，可以引入分区。

分区注意事项：

1常见的分区类型有range，list，hash，key等。用的比较多的就是range分区。

2对于初始建立索引的时候，我们往往会忽视一个前提条件，导致添加失败报错。

这里的前提是，如果表是有主键的，分区的键和主键不是同一个，那么分区的键也必须是主键。

引入分区后，数据写入时，数据库会自动判断写入哪个分区

对于并发量较高的，我们除了做上面的 *** 作外，就要考虑分库分表或者采用一主多从的方式。

未来我相信这类问题需要采用NewSQl这类数据库来解决，如TiDb等，此时，我们将不必考虑数据分区的问题，而且可以做到数据水平无限扩展，和热点数据的动态分布。

千万级数据检索，主要应该在数据库方面处理。
但单独的数据库服务器肯定是不行的，需要使用服务器集群，并且把所需数据尽量放置到内存中来。
最好的解决方案是采购MY SQL集群，每台服务器内存8G以上（这不算奢侈的配置），这样在几十台服务器以上之后就可以响应了。
当然更全面的还需要考虑中国的国情，注意网通与电信之间的瓶颈问题的处理。
希望能帮到你。

数据库的存在让我们无论是在制定营销计划还是获取新用户等目标上有一个更好的结果，下面昌平IT培训就一起来了解一下，数据化的服务器都有哪些特点。

强调互联网，这是因为本文所讨论的前提是互联网应用。与“传统”应用不同，互联网中的应用每天面临的是海量的数据、大量的请求以及对系统可靠性和响应速度有着更高的要求。“传统”应用，我姑且浅显地认为是，数据量不大，面对的用户群范围相对较小，自然大量的高并发请求场景几乎不存在。

在上文对互联网应用和传统应用有了一个大概的认识后，接下来我们来谈一谈，本文的主题关系型数据库在两种类型应用的不同使用方式，以及关系型数据在如今的互联网应用中是否不再是关注的焦点。

海量的数据。百万级甚至千万级亿级的数据已不可能存储在单一的数据表中，甚至不可能存储在一个数据库中。试想如果将所有的数据存储在单库单表中，一旦发生全表扫描，这对于系统响应速度来讲将是一个灾难。然而在传统应用中，可能单库单表已经足以适用。

二，由于产生了海量数据，进而数据在磁盘上的存储被设计成了“分库分表”的模式，利用某种特定的“路由”算法，定位一个数据所处的位置。正是因为“分库分表”的设计，使得关系型数据中的“联表查询”场景失效，所以在互联网应用中，一张表的设计已经几乎不再有“外键”，也就是联表查询几乎已消失。

三，大量的请求。这在互联网应用中比较常见，一起突发事件，一个明星的突发新闻，都会造成大量的请求瞬时到达。数据库的承载能力是有限的，一旦所有的访问量在某一时刻同时涌入，这直接会造成数据库宕机，整个系统甚至会因为数据库的原因造成服务不可用。所以在如今的互联网应用中，对数据的读取写入几乎已经不再直接 *** 作数据库，而是在数据库前加入了一道“安全”屏障——缓存。

四，服务的可靠性。服务的可靠性，即使系统出现问题，也要保证部分可用，读写分离是一个很好的解决方案，读取和写入 *** 作不再同一个数据库中进行，而是将他们分开。如果此时有大量写 *** 作，要尽量不影响读 *** 作，或者如果如果在写入数据库时造成数据库宕机，此时要尽量不能影响数据库的读 *** 作。此时在互联网应用中通常就会部署一套“主从”数据库，主库写，从库读，这就会衍生出数据同步的问题，或者归纳为数据一致性问题。

---