9 个解决方案
#1
对了 补充一下,那一个用户一个数据库是不是效果又如何?主要是我也没听过这么做的,但是有人提出,只是觉得这样船桨多个链接实体会很麻烦,而且mysql 能建立多少个数据库呢?
#2
你还是放一张表里吧,数据库没有你想象的那么脆弱。
#3
你好,能给出一个有说服力的理由吗,因为老板强调的,用多表,你懂得想说服老板不能没有理由啊...麻烦了
#4
单独创建几百万的表?
那这个表怎么设计?
用户的所有行为动作你都放在这个用户表里面吗?
那这个表怎么设计?
用户的所有行为动作你都放在这个用户表里面吗?
#5
用户总数固定吗?
如果固定且数量不大,那么一个用户一张表还有可行性。但这里可能需要牵涉到后面的扩展。你的查询可能在现在看来,似乎只会按用户分类来查,那么如果你要按时间来查询所有的用户信息呢?你如何把这些零散的数据集中起来?
如果用户数量不确定,那就麻烦了,你需要动态创建表,上面的问题也依然存在,除了这个,管理和组织这么一堆不知道什么时候就会变的东西,相信是件很痛苦的事情。
就个人的理解,分表主要是解决两个问题,一是数据压力太大,分摊负载,一是解决写入时的效率,因为如果一个表太大,写入数据时建立索引会花费大量时间。而对于查询的速度提升并不大。
但你的数据库,似乎也只是一张历史记录表,只有一次写入操作而已,分表到底能有多大的好处,你自己权衡吧。
嗯,你可以了解下分区表的一些功能,看是否适用。
以上是个人的一些考虑,供参考,如果有什么错误,大家指正。
如果固定且数量不大,那么一个用户一张表还有可行性。但这里可能需要牵涉到后面的扩展。你的查询可能在现在看来,似乎只会按用户分类来查,那么如果你要按时间来查询所有的用户信息呢?你如何把这些零散的数据集中起来?
如果用户数量不确定,那就麻烦了,你需要动态创建表,上面的问题也依然存在,除了这个,管理和组织这么一堆不知道什么时候就会变的东西,相信是件很痛苦的事情。
就个人的理解,分表主要是解决两个问题,一是数据压力太大,分摊负载,一是解决写入时的效率,因为如果一个表太大,写入数据时建立索引会花费大量时间。而对于查询的速度提升并不大。
但你的数据库,似乎也只是一张历史记录表,只有一次写入操作而已,分表到底能有多大的好处,你自己权衡吧。
嗯,你可以了解下分区表的一些功能,看是否适用。
以上是个人的一些考虑,供参考,如果有什么错误,大家指正。
#6
事务表的意思就是创建一个类似任务的东西,也就是相当于笔记。一个用户一个表,可能就是这么设计表名,task_“uid”,就是task加用户ID组成,如果用户达到百万级,就会有百万个表,我就是想知道是这样设计好还是一个大表,统一放这几百条记录乘以几百万用户,也就是上亿条记录好
#7
首先,我这种一个用户一个表,不是用户数数量确定的,是用户数量动态增加的,就是一个注册就会多一个。
通过你的介绍,我可以这么理解吗?这种建表,一、对以后的数据挖掘不是很好;二、动态建表很复杂,不容易实现;三、以后DBA面对这么多表会很头疼。
不知道我的理解对不对,还有其实我不知道DBA都做啥事,我真的是个小白,只是在帮导师做项目,也没人带,很多事情都是摸索中,麻烦了。
#8
呃,用户数要不断增长到百万……,你们是出于什么一种想法,要一个用户一张表呢?
#9
老板说,第一方便远程数据库和本地数据之间的同步,就是都有task表,这样一个用户一个表方便同步。我其实一直想做成大表的,只是没有好的理由劝服老板所以才来这里咨询
#1
对了 补充一下,那一个用户一个数据库是不是效果又如何?主要是我也没听过这么做的,但是有人提出,只是觉得这样船桨多个链接实体会很麻烦,而且mysql 能建立多少个数据库呢?
#2
你还是放一张表里吧,数据库没有你想象的那么脆弱。
#3
你好,能给出一个有说服力的理由吗,因为老板强调的,用多表,你懂得想说服老板不能没有理由啊...麻烦了
#4
单独创建几百万的表?
那这个表怎么设计?
用户的所有行为动作你都放在这个用户表里面吗?
那这个表怎么设计?
用户的所有行为动作你都放在这个用户表里面吗?
#5
用户总数固定吗?
如果固定且数量不大,那么一个用户一张表还有可行性。但这里可能需要牵涉到后面的扩展。你的查询可能在现在看来,似乎只会按用户分类来查,那么如果你要按时间来查询所有的用户信息呢?你如何把这些零散的数据集中起来?
如果用户数量不确定,那就麻烦了,你需要动态创建表,上面的问题也依然存在,除了这个,管理和组织这么一堆不知道什么时候就会变的东西,相信是件很痛苦的事情。
就个人的理解,分表主要是解决两个问题,一是数据压力太大,分摊负载,一是解决写入时的效率,因为如果一个表太大,写入数据时建立索引会花费大量时间。而对于查询的速度提升并不大。
但你的数据库,似乎也只是一张历史记录表,只有一次写入操作而已,分表到底能有多大的好处,你自己权衡吧。
嗯,你可以了解下分区表的一些功能,看是否适用。
以上是个人的一些考虑,供参考,如果有什么错误,大家指正。
如果固定且数量不大,那么一个用户一张表还有可行性。但这里可能需要牵涉到后面的扩展。你的查询可能在现在看来,似乎只会按用户分类来查,那么如果你要按时间来查询所有的用户信息呢?你如何把这些零散的数据集中起来?
如果用户数量不确定,那就麻烦了,你需要动态创建表,上面的问题也依然存在,除了这个,管理和组织这么一堆不知道什么时候就会变的东西,相信是件很痛苦的事情。
就个人的理解,分表主要是解决两个问题,一是数据压力太大,分摊负载,一是解决写入时的效率,因为如果一个表太大,写入数据时建立索引会花费大量时间。而对于查询的速度提升并不大。
但你的数据库,似乎也只是一张历史记录表,只有一次写入操作而已,分表到底能有多大的好处,你自己权衡吧。
嗯,你可以了解下分区表的一些功能,看是否适用。
以上是个人的一些考虑,供参考,如果有什么错误,大家指正。
#6
事务表的意思就是创建一个类似任务的东西,也就是相当于笔记。一个用户一个表,可能就是这么设计表名,task_“uid”,就是task加用户ID组成,如果用户达到百万级,就会有百万个表,我就是想知道是这样设计好还是一个大表,统一放这几百条记录乘以几百万用户,也就是上亿条记录好
#7
首先,我这种一个用户一个表,不是用户数数量确定的,是用户数量动态增加的,就是一个注册就会多一个。
通过你的介绍,我可以这么理解吗?这种建表,一、对以后的数据挖掘不是很好;二、动态建表很复杂,不容易实现;三、以后DBA面对这么多表会很头疼。
不知道我的理解对不对,还有其实我不知道DBA都做啥事,我真的是个小白,只是在帮导师做项目,也没人带,很多事情都是摸索中,麻烦了。
#8
呃,用户数要不断增长到百万……,你们是出于什么一种想法,要一个用户一张表呢?
#9
老板说,第一方便远程数据库和本地数据之间的同步,就是都有task表,这样一个用户一个表方便同步。我其实一直想做成大表的,只是没有好的理由劝服老板所以才来这里咨询