对于海量数据高并发请求的数据库架构求教！

[zznj1123]

1、海量数据的处理

众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。对于大型应用，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。

2、数据并发的处理

在一些时候，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存策略。

另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。

我的问题：我们现在的用户是不断增长的，数据库用的是链接服务器的形式，现在经常会出现死锁的情况，手动杀死死锁进程就会出现数据不一致的情况。
请问大家对于海量高并发数据库的设计和架构是如何实现的？
谢谢！

[steavenhe]

学习学习

[seawalt]

如果同时要频繁的查询和DML，那就分开吧，一台用于查询，一台用于DML.

[seawalt]

对于以后不会怎么更新的数据，转移出去，放在另外的服务器上。

[Sqler]

这个话题太大了，呵呵
看热闹中......
顺顶。

[ChinaITOldMan]

学习

[haitao]

分区表，按时间段或客户编码的前2位或其他特征，把一个大表按特征分多个小表存储
访问起来有好像是一个表，实际执行的索引更新、使用又仅仅按涉及到的一个小表来进行

sql2000的分区表设计相当麻烦，sql2005好像好了一些，自称方便，但是感觉还是有点麻烦
当然，设计好了，使用起来是没任何麻烦的

[mlemon]

业务表应该和仓库分开，放在同一台服务器上负载很重。
而且热点表或热点字段会因为并发访问加锁，极度影响性能，需要合理的模式设计。

[hyrongg]

一直在关注大量数据存储，实时数据分析的问题
没有好的解决办法。

[jamo]

上 SSD 存储

[Q315054403]

这样都能找到答案，那我就发贴询问火箭是如何制造的了。。。

[guohouchang]

关注

[还要匿名啊]

我是新人学习中。。
但一般的都应该是 分表吧~~
假如千万数据的新闻。
按类分多种表
然后把过期新闻随时删掉，保持数据大小

[还要匿名啊]

学习中

[chenfeng3000]

把数据库搞成分布式数据库，利用水平分割，垂直分割的原理，将数据分配到几台服务器上，这样或许能搞达到负载均衡的目的

[guoming_yc]

帮顶 ～～ 学习

[xuqh123]

bang ding，盼“仙人”指路。

[aa215]

学习中

[play7788]

1楼的回答很强

[无锡阔微信息科技]

关注,学习

[ElberOnly]

上面都有回答！~
第一、是从数据库入手。分库分表。在就是读写分离， 辅库肯定是保证读取的速度。
第二、加入缓存代理，可以用squid缓存静态文件 及 mc缓存。以减轻源服务器压力。
第三、如果有热点文件。那么要根据自己的需求 写个热点算法。来把热点文件缓存到内存。或者热点内容放到热表里。用队列定时更新。