1
Livid MOD 大数据需要的也是大机器,而且是不止一台大机器。当你手上有一堆大机器时,需要做的就是设计一个能够应对灾难状况的架构,及尽可能在流量高峰能够吃透这些机器的性能。到一家大公司参与一个有规模的项目,是学习这些技术最快的方式。
|
2
likuku 2013-06-30 01:41:25 +08:00
「现在连mysql 几百并发都搞不定啊」
烂的SQL语句可以让机器表现变慢1万倍。 充分利用缓存了没?用好缓存能解决绝大部分「性能问题」。 web静态缓存(varnish/squid),对象内存缓存(memcached),db 查询缓存,等等。 |
3
jjx 2013-06-30 08:59:22 +08:00
都是靠横向和纵向扩展的
业务系统的关系数据库查询和插入都很复杂的,就算你能把操作平均到10毫秒,一秒也就能处理100个,但实际情况是远远达不到。 但你可能通过扩展多个工作进程达到n倍的性能改进。 但最终,数据库又是瓶颈,你只好再对数据库做扩展(但对关系数据库做扩展都比较麻烦), 或使用内存数据库。 很多人使用mongdb, 无非就是他标称的快和所谓的扩展能力。 |
4
kennedy32 2013-06-30 10:43:45 +08:00
可以考虑把数据库分离出来,aws或者aliyun都有提供单独的数据库服务器
|
5
dongbeta 2013-06-30 10:46:57 +08:00
高性能MySQL + 靠谱的生产环境项目
|
8
akalanala 2013-06-30 13:57:30 +08:00
搞着几百并发的事, 操着几千万并发的心... 楼主还是先歇歇吧.
|
9
keakon 2013-06-30 14:02:58 +08:00 2
1. 尽量别依赖数据库来实现数据的关联关系。
知乎内部的 MySQL 使用准则中,就禁止使用 JOIN、GROUP BY、子查询和外键。 说实话,这等于使用非关系型数据库了。 2. 查询主要靠缓存和索引。 但千万别乱加缓存和索引,它们和表的结构、业务逻辑、使用频率之间有且只有一个最优解。 你只能靠经验和测试来寻找,而且越到后期,这些就越难改动。 做到这 2 点还有瓶颈的话,基本也是价值不菲司了,也不会缺有经验的 DBA 了。 这时的瓶颈主要在写了,就通过分离读写、分库、使用 SSD 的方式来满足吧。这部分我也不熟。 |
10
kevinv 2013-06-30 14:53:30 +08:00
上面说的都有道理,其实最基础的还是把程序优化好,再做其他的,要不然都是扯淡。
|
11
Feobe 2013-06-30 15:40:05 +08:00
|
12
avichen 2013-06-30 15:52:30 +08:00
1.把需要执行10秒的sql优化成0.x秒
2.花钱买硬件 |
13
darasion 2013-06-30 16:32:53 +08:00
软件上能精简的都精简,甚至硬件都特殊定制。
比如apache,不用的部分就连代码都删掉。比如google连服务器都自己造. |
14
akira 2013-06-30 17:23:02 +08:00
数据库几百并发不算少了吧,网站的话,都是日均百万pv级别了。
之前在dbanote还是nosql看到过一篇讲新浪架构的,那个对你应该有点帮助。 |
15
lhx2008 2013-07-04 08:24:08 +08:00
几百并发可以玩玩memcache顶顶吧
|
16
clino 2013-07-04 08:56:58 +08:00
openresty 不就是擅长高并发的嘛
不过据我粗浅的了解,还是要注意很多方面才能扛得住 |
17
cxe2v 2013-07-04 09:17:38 +08:00
数据库几百并发,你做的项目有点大啊,有多少台服务器要连你的数据库啊?
|