用什么在数据库中存储的是存储大量简单数据比较合适

大量文件存储,以及提供下载,数据库并发,有什么好的解决方案呢?
公司要推出一个网盘,设计目标是每天100万PV。
大量的文件存储,高峰期的数据库并发。
程序用PHP去写,nginx + php-fpm.
数据库该怎么选择呢?如果不做数据库集群的话,需要什么样的硬件配置才能满足呢?
还有就是文件肯定不能只存放在一台服务器上,对于负载均衡,冗余技术目前还不懂。。
头疼,头疼;
以下是问题补充:
:文件存储用 fastdfs ?
mysql的并发写入瓶颈与什么有关?cpu,内存,硬盘?还是mysql本身?
网盘这些都有个特点,已经上传的文件不会重复上传,所以有时候上传一个文件会出现秒传的现象
--- 共有 3 条评论 ---
: 想了一下还是可行的。
矛盾吗?!用户有自己的文件,只需要维护账户与文件的关联关系,但文件本身完全可以只存储1份(文件后缀、大小和MD5等多重校验唯一性)。
不,我们不做那样的,就做传统的,每个文件都只属于一个用户。
数据库就mysql吧。2台也够用了,而且网盘的数据结构也不是特复杂。能很好的优化 。
这都不是什么问题。
问题是文件存储。网盘文件一般是小文件,所以推荐淘宝开源的FastDFS
--- 共有 3 条评论 ---
: 主要就是统计下载次数的问题,一个IP24小时内还不能重复。我想的是将当天的下载记录全部记录到文件中,然后第二天再处理后一次导入数据库
其实mysql一般够用 百万pv 其实多半是读。写其实不多。同时一般情况下网盘这种业务很好做分表分库(用户之间交互少)。即使以后扩展也好。不用做集群
那你的意思是,mysql还是要做集群?不然高并发写入吃得消吗?
不太推荐用hdfs 就目前来看 一般的设计目标都是高于实际需求的。现在就上hdfs有点。。。。
而fastdfs文档齐全,成熟案例多:参看:&http://bbs.chinaunix.net/forum-240-1.html
--- 共有 3 条评论 ---
: 我明白了。
hadoop只是一个平台,但是一般主要用作数据的离线处理分析。
他是可以架构在hdfs上的。╮(╯Д╰)╭为何现在好多人不是把hadoop当数据库,就是当文件系统了。汗。你们目前没得必要架设这玩意
昨天我同学提到hadoop,也不知道如何
如果贵公司是知名大公司,这个问题需要你问么
所以贵公司是一般公司,那网盘劝你老板别做了,尤其是你说的这样的
红海竞争,你做得过海了去的其他网盘,告诉你老板现在有多少家和他们是谁
--- 共有 6 条评论 ---
: 关我鸟事?我只负责开发,赚钱了有粉红,亏了不关我事,工资照拿啊
好吧,你这么迷信你们老板我就不说什么了。懂用网盘人的心理吗?!怕就怕尼玛的哪天关闭了,小公司我敢用?!当然如果你们产品是你们其他产品的增值服务不算,客户关系是依附你其他产品的。
: 我这边四五个老板,然后技术就我一个吗?而我才刚刚大四,接触PHP不到一年,又不是计算机专业的,linux也是最近一个月学的,我发现我迷失了方向了。至于盈利,有流量就有钱,而他们不缺流量
: 我倒觉得这东西有市场了,才有做的价值。至于怎么做,这些技术都不是壁垒性技术,没什么大不了的
呵呵,我才不关心你们如何盈利呢,我只是觉得你们老板自以为是了,如果你们技术团队连这个架构都没概念更别提做好了(不是针对你,呵呵),商业模式还是后面的事
mysql 做个读写分离,1主2从。文件系统看你准备多少服务器了,现在淘宝的tfs很火。不过我建议简单点nfs+rsync同步就好了,如果要求不是特别高的话。还有日志不建议进mysql
--- 共有 2 条评论 ---
: 一般并发查询会比较多,并发写入超过100就很多了
主从的话,高并发写入不合适吧?
我的观点, 难道技术真不值钱吗 ? &像这样的例子已经很多了. 为什么第一想法不是合作.而是自创呢. &
--- 共有 2 条评论 ---
那么,你们真的很需要这个功能? 如果是小量的就自己维护. 当遇见瓶颈就直接找现成技术公司合作.
我很苦B,他们当老板的冒出来一个想法,然后就一股脑将需求发给技术,你做不好吧,他认为你能力不足,也不多招一些技术。查看:19201|回复:20
本人想做一个人员管理系统,现在已经有人员基本信息表,表中关键列为(“人员id”,“工作单位”);同时还有部门信息表格,表格中包括(“部门编号”,“部门名称”,“部门人员”),由于一个部门有多个人员,对于这样的数据不知道如何组织,本来打算将部门信息表中“部门人员”一列设置为字符串,然后添加类似于(1,2,3)这样的数据,其中的数字表示该人员在人员信息表中的编号,这样一来到时候从数据库取出数据的时候可以转化为数组,然后再执行查询。
挺麻烦的,而且容易出错,而且考虑到维护,比如在某一部门增加一个人员的时候,是不是需要同样取出字符串,转化为数组,然后在数组中添加一个数字,然后再转为字符串,再插入表格。
总觉得这样子太麻烦,不知道大家有没有好的设计思路啊?
应该把部门信息表中的“部门人员”字段去掉,然后在人员表中添加“所属部门”(部门编号)字段,这样就可以了
人员信息表 就是你说的那样设计的
但是我觉得人员太多,而且要分类显示各部门人员的时候会挺慢,所以才这样想的
首先,觉得你说的数组的做法的实现性不太可能,而且分类各部门人员的时只用到一个联表查询,应该不会太慢,你还可以把它写成一个存储过程
嗯,你说的方法可行,存储过程比单纯的sql语句效率更高吗?
不过你说的我的那个方法也并不是不可行的,可以将人员编号用逗号分隔开连成字符串存到数据库,等从数据库取出的时候再根据分隔符转化为数组,不过维护起来就很麻烦,而且真正实现起来效率也不是很高
用存储过程来实现效率是所有提高的,因为存储过程编译后它就在内存里了,再次运行时就不用再编译了
哦&&知道了 那我就用存储过程吧&&呵呵 谢谢:ldw5:
新增一张表,记录人员和部门之间的关系。
一个人多个部门,就多条记录即可。
查询的时候关联这3个表就好了。
嗯&&,有道理
你说的这种方式也可以尝试一下
中级工程师
用表 来存储数组 ~
用表来存储数组? 问的就是这个问题啊& &数据库中有数组这种字段吗?
不需要专门的类型
一个数组就是一个表,这么理解就好了。
额,,,好吧
试试,然后把结果反馈一下
这个,,还要反馈吗&&就是在创建一个表,其中有部门编号和人员编号就这么简单啊
呵呵,当然要反馈一下
这个是你的心得啊。自己知道了,写出来就能分享给别人了。
拆分数据表,建立合理的索引,查询的时候不会慢。
做一个E-R关系图,区分好2NF和3NF。把实体关系搞清楚,如实体有人员,部门。然后实体人员的属性有ID,名称,性别,年龄,工龄等。实体部门的属性有部门ID,部门名称,部门人数等。有疑问,可以联系我。
其实没必要抠着“数组”这两个字不放。你实现的也只是一个集合嘛。那就用版主说的,用一对多的结构,把人员放入一个新表,用一个部门来与你的主表关联,这样方便更新。至于效率,我觉得一个企业再大,也不过几十万人。应该不会体现出慢
嗯,是的引用:原帖由 Huangzhaoji 于
16:13 发表
其实没必要抠着“数组”这两个字不放。你实现的也只是一个集合嘛。那就用版主说的,用一对多的结构,把人员放入一个新表,用一个部门来与你的主表关联,这样方便更新。至于效率,我觉得一个企业再大,也不过几十万人。应该不会体 ...用什么数据库存储大量简单数据比较合适_电脑数码_橘子知识网
用什么数据库存储大量简单数据比较合适
编辑: 橘子知识网 &&&来源:用户发表&&&发布时间:&&&点击次数:25
请帮看下!用什么数据库存储大量简单数据比较合适?感激不尽!
【知识探讨】
手机app用什么数据库比较好?
我们单位需要研发一套移动互联系统,这里涉及到手机app的研发与使用。我...一般的数据量很小的项目,没必要使用数据库,如果只是保存写用户信息,大可以用其他的方法,用keychain或者nsuserdefault或者其他的都可以。 对于sqlite和coredata,只是两种不同的存储方法,一种是小型轻量级sqlite数据库,所有移动设备经常用...
一个表格存储四五亿条,用什么数据库存储比较好。
我用mysql存储之后,单用户查询一次都要10多秒。我不懂为什么百度那些为...你的是服务器还是笔记本?就算是台式机也很难跟正式服务器比,而且再加上集群,磁盘阵列等等,这就不是一个等级的了,最最重要的,像百度这种超大型的系统都是服务器群组成的,背后可能有上千上万台服务器,能不快吗(百度不清楚,google背后的服务器过万...
数据量不大,用xml文件代替数据库有没有大的影响
数据量不大,用xml文件代替数据库有没有大的影响 不适合. XML适合记录配置文件或者其他的需要移植和共享的数据. 优势在于使用标准的格式,不同的程序和系统都能看懂.也方便人阅读. 存储大量数据时没有简单有效的检索机制,无论查询还是修改都不便...
电脑数码相关
更多相关内容
本站内容来自网友发布,本站无法保证其部分内容的正确性,请用户一定仔细辨别。
[] &&[联系QQ:885&971&98] &
沪ICP备号&大容量数据存储解决方案_百度文库
两大类热门资源免费畅读
续费一年阅读会员,立省24元!
大容量数据存储解决方案
上传于|0|0|文档简介
&&NEXSAN 存储产品
阅读已结束,如果下载本文需要使用0下载券
想免费下载更多文档?
定制HR最喜欢的简历
下载文档到电脑,查找使用更方便
还剩2页未读,继续阅读
定制HR最喜欢的简历
你可能喜欢

我要回帖

更多关于 数据库存储过程怎么写 的文章

 

随机推荐