数据库设计——关于大量数据

天蝎座小混混 2014-01-27 05:17:37
假如有1000家营业部,每家营业部又有1w人,每天每个人会发0到多条的心情,还有一些其他的信息,那么用不了多久数据库数据条数就会很庞大,对于这样的情况 如何设计sqlserver数据库,以及服务器方面如何设计比较好!同时又要考虑到数据备份和安全方面。
如果数据库放在多个服务器上面 那么数据同步要怎么实现,如何通过程序来选择最优的服务器来进行数据交互!
总的来说就是像新浪微博这样的应用,每天那么多数据,他的数据库以及前台是怎么设计的,才可以保证微博数据访问的速度和安全!
...全文
578 30 打赏 收藏 转发到动态 举报
写回复
用AI写文章
30 条回复
切换为时间正序
请发表友善的回复…
发表回复
haitao 2014-02-17
  • 打赏
  • 举报
回复
引用 29 楼 zai_yuzhong 的回复:
[quote=引用 28 楼 sz_haitao 的回复:] [quote=引用 27 楼 zai_yuzhong 的回复:] 看来是没人回复了,果断结贴!
关键的需求没回答: 心情信息是否跨营业部可见?[/quote]所发的可以跨营业部可见[/quote] 如果这样,就无法在应用上进行分服务器了 即 此应用必须要求一个 统一的 数据库(逻辑或物理)服务器
天蝎座小混混 2014-02-17
  • 打赏
  • 举报
回复
引用 28 楼 sz_haitao 的回复:
[quote=引用 27 楼 zai_yuzhong 的回复:] 看来是没人回复了,果断结贴!
关键的需求没回答: 心情信息是否跨营业部可见?[/quote]所发的可以跨营业部可见
天蝎座小混混 2014-02-12
  • 打赏
  • 举报
回复
看来是没人回复了,果断结贴!
haitao 2014-02-12
  • 打赏
  • 举报
回复
引用 27 楼 zai_yuzhong 的回复:
看来是没人回复了,果断结贴!
关键的需求没回答: 心情信息是否跨营业部可见?
一枚小菜 2014-02-11
  • 打赏
  • 举报
回复
收藏!收藏!
gongjian0628 2014-02-11
  • 打赏
  • 举报
回复
【分表,分文件组,分库,分服务器,磁盘raid】
xiaoxiangqing 2014-02-08
  • 打赏
  • 举报
回复
这么大的数据量,估计要用oracle
天蝎座小混混 2014-02-08
  • 打赏
  • 举报
回复
引用 16 楼 ap0405140 的回复:
大数据的问题,单纯用mssql估计难以支撑,LZ可以了解一下nosql技术.
那可以给我找些nosql的资料吗
天蝎座小混混 2014-02-08
  • 打赏
  • 举报
回复
引用 19 楼 hotel9545 的回复:
1、读写分离,就是说新老数据分离,建立同结构的新表和老表。 2、根据实时性要求关闭DB的自动更新统计信息功能,在闲时打开,或者用作业的方式定时执行。 3、老表也要分表,分表的依据是不要让数据在物理存储上跨页,这个需要你看看MSSQL每页的大小和你的记录大小来确定。 4、同步可以考虑使用发布、订阅功能,或者建立链接,再写个作业利用BulkCopy实现数据同步。
那有没有比较具体的实现步骤!
撸大湿 2014-02-08
  • 打赏
  • 举报
回复
这个数据量还称不上大数据 员工心情数据属于业务LOG数据,没必要放在RDBMS(不管是MSSQL、ORACLE),这种数据不需要ACID支持 23楼说的mongodb是一种选择,但在我感觉这货任然是轻中量级的 这种业务用分布式DB处理最好 单行横向扩展
引用 楼主 zai_yuzhong 的回复:
假如有1000家营业部,每家营业部又有1w人,每天每个人会发0到多条的心情,还有一些其他的信息
这种业务放在RDBMS中,每条心情数据就是一行,没行几列 但放在KV DB中,每天只有1000行,但没行可能有上百万个列 这种业务用KV横向扩展DB来处理是王道 唯一的缺陷是无法再用SQL,需要一定的开发功底 推荐hbase或cassandra,者两款都是基于 google bigtable 开源实现 处理千亿行数据、每行上百万个列轻轻松松。。。
梁山草寇 2014-02-08
  • 打赏
  • 举报
回复
如果要实现这么多要求还基于大数据量的情况下建议使用nosql,现比较火的mongodb,你说的主从,副本,读写分离,分片等等。。。一条命令即可。现如今大型社交网站基本都在转向mongodb,参考网站 http://www.2cto.com/database/201203/122269.html
hotel9545 2014-02-07
  • 打赏
  • 举报
回复
1、读写分离,就是说新老数据分离,建立同结构的新表和老表。 2、根据实时性要求关闭DB的自动更新统计信息功能,在闲时打开,或者用作业的方式定时执行。 3、老表也要分表,分表的依据是不要让数据在物理存储上跨页,这个需要你看看MSSQL每页的大小和你的记录大小来确定。 4、同步可以考虑使用发布、订阅功能,或者建立链接,再写个作业利用BulkCopy实现数据同步。
發糞塗牆 2014-02-07
  • 打赏
  • 举报
回复
听过博客园某大牛的经历,说去一个客户里面看系统,SAP,管理人员基本上不怎么懂sqlserver,但是3T的数据库依旧运行得还不错,这是极致优化的结果(当然是SAP做的),这些你除非分析他们的系统,不然也很难想到
line_us 2014-02-05
  • 打赏
  • 举报
回复
这是他们的吃饭家伙,可是我也想知道。
唐诗三百首 2014-02-03
  • 打赏
  • 举报
回复
大数据的问题,单纯用mssql估计难以支撑,LZ可以了解一下nosql技术.
haitao 2014-02-03
  • 打赏
  • 举报
回复
每个人的心情信息 是不是 只有同营业部的才能看到? 那就简单很多了,无须一个大服务器,可以n个小服务器来分别支持各个营业部
PaulPaul 2014-02-02
  • 打赏
  • 举报
回复
引用 13 楼 luckyrandom 的回复:
找专业的dba去规划和设计,既然数据量有一定规模,就该配置相应的dba资源
对。找合适的人做事情,这才是正道。
Q315054403 2014-01-31
  • 打赏
  • 举报
回复
找专业的dba去规划和设计,既然数据量有一定规模,就该配置相应的dba资源
天蝎座小混混 2014-01-30
  • 打赏
  • 举报
回复
引用 10 楼 yupeigu 的回复:
如果再考虑大数据量太大,进行备份的时间太长,那么可以考虑用数据库的复制。 也就是你不用去备份数据库,而是每台服务器配置一台从属服务器,那么原来有10台服务器,那么再加10台服务器,每台服务器通过数据库复制,把数据复制到从属服务器上,另外,从属服务器可以提供读操作,而主服务器提供了读和写操作,这样就实现了读写分离,另外,也是下了高可用性。
小当家的意见很不错,等过了春节来看看!
lifefamily11 2014-01-30
  • 打赏
  • 举报
回复
1 读写分离 2 采用分表策略 3 可以考虑采用NOSQL,不要过多考虑表之间的关系
加载更多回复(10)

27,579

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 应用实例
社区管理员
  • 应用实例社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧