对于海量数据高并发请求的数据库架构求教! 20zznj1123]

发布时间:2016-12-9 19:41:59 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"对于海量数据高并发请求的数据库架构求教! 20zznj1123]",主要涉及到对于海量数据高并发请求的数据库架构求教! 20zznj1123]方面的内容,对于对于海量数据高并发请求的数据库架构求教! 20zznj1123]感兴趣的同学可以参考一下。

1、海量数据的处理 众所周知,对于一些相对小的站点来说,数据量并不是很大,select和update就可以解决我们面对的问题,本身负载量不是很大,最多再加几个索引就可以搞定。对于大型应用,每天的数据量可能就上百万,如果一个设计不好的多对多关系,在前期是没有任何问题的,但是随着用户的增长,数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。 2、数据并发的处理 在一些时候,就是缓存。对于缓存,在高并发高处理的时候也是个大问题。在整个应用程序下,缓存是全局共享的,然而在我们进行修改的时候就,如果两个或者多个请求同时对缓存有更新的要求的情况下,应用程序会直接的死掉。这个时候,就需要一个好的数据并发处理策略以及缓存策略。 另外,就是数据库的死锁问题,也许平时我们感觉不到,死锁在高并发的情况下的出现的概率是非常高的,磁盘缓存就是一个大问题。 我的问题:我们现在的用户是不断增长的,数据库用的是链接服务器的形式,现在经常会出现死锁的情况,手动杀死死锁进程就会出现数据不一致的情况。 请问大家对于海量高并发数据库的设计和架构是如何实现的? 谢谢!

既然是海量,就不要频繁的查询和UPDATE. 既然要频繁的查询和UPDATE.数据就不能是海量. 如果两者都想要,那就象CSDN一样,让你暂时打不开帖,等着吧.

把热点表,热点字段先划分出来 想办法垂直拆分

引用 2 楼 flairsky 的回复:把热点表,热点字段先划分出来  想办法垂直拆分 可以说得更详细点吗。我遇到的正好是这样的问题,有两三个表,数据量特别大,而且操作频率比较高。 求详解!

楼主信息太少 1。你主要cost是读还是写? 2。如果是读,是哪类查询比较多,range query, equality query, or cube query? 3。一般来说,可以试试 Index Tuning Wizard 

路过,帮顶并学习一下。

 学习学习

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

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

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

学习

分区表,按时间段或客户编码的前2位或其他特征,把一个大表按特征分多个小表存储 访问起来有好像是一个表,实际执行的索引更新、使用又仅仅按涉及到的一个小表来进行 sql2000的分区表设计相当麻烦,sql2005好像好了一些,自称方便,但是感觉还是有点麻烦 当然,设计好了,使用起来是没任何麻烦的

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

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

上 SSD 存储

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

关注

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

学习中

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

帮顶  ~~ 学习

学习中

1楼的回答很强

bang ding,盼“仙人”指路。

关注,学习

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

上一篇:如何用Mysql开发高级鼠标管理器? 100qiaosai02]
下一篇:sql2000备份的数据库怎么用sql2005还原不了呢,请帮解决,谢谢! 30hxd209]

相关文章

相关评论