|
精华帖 (8) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (8)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-09-16
elmar 写道 wl95421 写道 先说明我不是DBA，所以给的方案可能不一定符合数据库设计的美观。
我觉得如果有重复，那么重复的字段应该与业务有关 完全可以根据业务字段分区，如AB开头的数据放在Test_AB中，或者是用类HashCode的算法进行分类，然后估算规模，完全可以将一张表的数据控制在一个理想的范围。 如果数据增长超出预期，那么可以考虑迁移，重做数据库。（细节不讨论） 如果是我做的话，加个Lucene分段索引（只对指定字段索引），多了不好说，做个亿级的，速度应该没有大的问题。（如果再多，加几台机器分区处理了。） 其实最根本的东西，还是你的规模估算。 有这么复杂吗？这是一个简单的数学问题而不是一个复杂的工程问题 就象如果你要做一个1万页Html的搜索引擎，还是1万亿页Html的搜索引擎。 前者对于很多程序员都不是一个问题，一个Lucene就能解决，再直接点，用数据库的Clob加个索引都能解决。 如果后者呢，就完全不是这个方案了。 所以规模估算就决定你问题的复杂度。量变引起质变。 |
| 返回顶楼 | |
|
发表时间：2008-09-16
wl95421 写道 elmar 写道 wl95421 写道 先说明我不是DBA，所以给的方案可能不一定符合数据库设计的美观。
我觉得如果有重复，那么重复的字段应该与业务有关 完全可以根据业务字段分区，如AB开头的数据放在Test_AB中，或者是用类HashCode的算法进行分类，然后估算规模，完全可以将一张表的数据控制在一个理想的范围。 如果数据增长超出预期，那么可以考虑迁移，重做数据库。（细节不讨论） 如果是我做的话，加个Lucene分段索引（只对指定字段索引），多了不好说，做个亿级的，速度应该没有大的问题。（如果再多，加几台机器分区处理了。） 其实最根本的东西，还是你的规模估算。 有这么复杂吗？这是一个简单的数学问题而不是一个复杂的工程问题 就象如果你要做一个1万页Html的搜索引擎，还是1万亿页Html的搜索引擎。 前者对于很多程序员都不是一个问题，一个Lucene就能解决，再直接点，用数据库的Clob加个索引都能解决。 如果后者呢，就完全不是这个方案了。 所以规模估算就决定你问题的复杂度。量变引起质变。 lz的问题是“向大数据数据库中插入值时，还要判断插入是否重复，然后插入。如何提高效率” 首先，一个不允许重复的字段加一个unique的index是一个必然的选择。 其次，在一个unique字段上插入，无论是1000条的数据，1M数据，1T数据都没有任何区别——你根本没办法干预数据的行为，你的任何干预都只会降低效率。 不知道Lucence怎么被扯进来了？ |
| 返回顶楼 | |
|
发表时间：2008-09-16
elmar 写道 wl95421 写道 elmar 写道 wl95421 写道 先说明我不是DBA，所以给的方案可能不一定符合数据库设计的美观。
我觉得如果有重复，那么重复的字段应该与业务有关 完全可以根据业务字段分区，如AB开头的数据放在Test_AB中，或者是用类HashCode的算法进行分类，然后估算规模，完全可以将一张表的数据控制在一个理想的范围。 如果数据增长超出预期，那么可以考虑迁移，重做数据库。（细节不讨论） 如果是我做的话，加个Lucene分段索引（只对指定字段索引），多了不好说，做个亿级的，速度应该没有大的问题。（如果再多，加几台机器分区处理了。） 其实最根本的东西，还是你的规模估算。 有这么复杂吗？这是一个简单的数学问题而不是一个复杂的工程问题 就象如果你要做一个1万页Html的搜索引擎，还是1万亿页Html的搜索引擎。 前者对于很多程序员都不是一个问题，一个Lucene就能解决，再直接点，用数据库的Clob加个索引都能解决。 如果后者呢，就完全不是这个方案了。 所以规模估算就决定你问题的复杂度。量变引起质变。 lz的问题是“向大数据数据库中插入值时，还要判断插入是否重复，然后插入。如何提高效率” 首先，一个不允许重复的字段加一个unique的index是一个必然的选择。 其次，在一个unique字段上插入，无论是1000条的数据，1M数据，1T数据都没有任何区别——你根本没办法干预数据的行为，你的任何干预都只会降低效率。 不知道Lucence怎么被扯进来了？ 就是啊。什么都出来了，就几十万的数据，有必要整那么复杂嘛，是不是也得考虑解决问题的效率。。。。 最后搞一个完美方案，一年都过去了。。。。 |
| 返回顶楼 | |
|
发表时间：2008-09-16
hallywang 写道 elmar 写道 wl95421 写道 elmar 写道 wl95421 写道 先说明我不是DBA，所以给的方案可能不一定符合数据库设计的美观。
我觉得如果有重复，那么重复的字段应该与业务有关 完全可以根据业务字段分区，如AB开头的数据放在Test_AB中，或者是用类HashCode的算法进行分类，然后估算规模，完全可以将一张表的数据控制在一个理想的范围。 如果数据增长超出预期，那么可以考虑迁移，重做数据库。（细节不讨论） 如果是我做的话，加个Lucene分段索引（只对指定字段索引），多了不好说，做个亿级的，速度应该没有大的问题。（如果再多，加几台机器分区处理了。） 其实最根本的东西，还是你的规模估算。 有这么复杂吗？这是一个简单的数学问题而不是一个复杂的工程问题 就象如果你要做一个1万页Html的搜索引擎，还是1万亿页Html的搜索引擎。 前者对于很多程序员都不是一个问题，一个Lucene就能解决，再直接点，用数据库的Clob加个索引都能解决。 如果后者呢，就完全不是这个方案了。 所以规模估算就决定你问题的复杂度。量变引起质变。 lz的问题是“向大数据数据库中插入值时，还要判断插入是否重复，然后插入。如何提高效率” 首先，一个不允许重复的字段加一个unique的index是一个必然的选择。 其次，在一个unique字段上插入，无论是1000条的数据，1M数据，1T数据都没有任何区别——你根本没办法干预数据的行为，你的任何干预都只会降低效率。 不知道Lucence怎么被扯进来了？ 就是啊。什么都出来了，就几十万的数据，有必要整那么复杂嘛，是不是也得考虑解决问题的效率。。。。 最后搞一个完美方案，一年都过去了。。。。 我不是都说了吗，其实最根本的东西，还是规模估算。 如果数据量小的话，怎么处理都无所谓，但是现在的数据库已经有几十万条了，如果它的增长量很快，而且重复率比较高，那么就不是一个简单的方案了。 至于说到lucene，其实很简单，因为我觉得根本的问题在于:如何快速判断主键重复，可以演绎成一个如何快速搜索字段的问题，那么Lucene可以解决这个问题，所以我说了可以使用Lucene。 至于Lucene，也远谈不上完美，我只是给出自己的思路，如果真的达到百万甚至更多，那么只使用数据库，就未必是个好的方案。大家不是一定要将精力放在数据库处理或者异常上，而是根据自己实际的情况来选择方案。 |
| 返回顶楼 | |
|
发表时间：2008-09-16
引用 我不是都说了吗，其实最根本的东西，还是规模估算。 如果数据量小的话，怎么处理都无所谓，但是现在的数据库已经有几十万条了，如果它的增长量很快，而且重复率比较高，那么就不是一个简单的方案了。 至于说到lucene，其实很简单，因为我觉得根本的问题在于:如何快速判断主键重复，可以演绎成一个如何快速搜索字段的问题，那么Lucene可以解决这个问题，所以我说了可以使用Lucene。 至于Lucene，也远谈不上完美，我只是给出自己的思路，如果真的达到百万甚至更多，那么只使用数据库，就未必是个好的方案。大家不是一定要将精力放在数据库处理或者异常上，而是根据自己实际的情况来选择方案。 判断一个值是否重复，其关键就是搜索，而搜索的关键是排序。 而这些都是任何一个数据库最本质，最核心的任务。 对大量常规数据（包括所有数据库支持的数据类型）的查找，这种数据库最基本的功能，除非这些数据有很强的特性可以自己写一个搜索算法，否则，怎么可能有通用的更高效的算法呢（即使有，也肯定是专利，并且被首先应用于数据库了）？ Lucene的作用是给一个长字符串分词，为分好的词做索引——它是用来查验字符串相似/包含而不是验证相等的。 |
| 返回顶楼 | |
|
发表时间：2008-09-16
用Lucene只是一种方案，或者说是一个建议
并不是一定要用 所以我说，远谈不完美，但是总比自己写算法要来的快，而且在我过去使用的经验，数据库这方面速度，如果不分表的话，不见得比Lucene快，而且Lucene感觉更灵活一些。 个人建议，还是要从自己的实例出发。 适合自己的，才是最好的。 |
| 返回顶楼 | |
|
发表时间：2008-09-17
wolfbrood 写道 vvgg 写道 设为主键，重复捕捉异常
坚决反对这种用法，异常不能这么用，每次异常都会消耗系统很多资源。 方法1：就是先把数据插入一个临时表，然后通过sql找出临时表里面哪些数据在正式表里面没有，然后把这些数据插入正式表。至于怎么找没有重复的数据那就是你的事，数据库存储过程可以完成，也可以写程序一条一条的读出。 这个方法避免了每次插入都要查找一次，但不一样的数据就要插入两次。至于效率问题你可以自己慢慢调优。 方法2：写trigger，在插入之前做一个查询，如果有就抛弃，没有就插入数据 我暂成“方法1”，我增在一个项目中这样做过，而且业务逻辑比楼主的还要复杂，其中涉及到3个主要的表，一个100多万的数据、另外两个都在50万以上，其中用到了两个临时表，在每次导入2-3万数据的情况下速度还是很快的，更大量的数据导入没有试过，不过这已经满足了我们的业务要求。 |
| 返回顶楼 | |
|
发表时间：2008-09-17
tou3921 写道 freeric 写道 cenwenchu 写道 update,命中为0,就insert
支持 这样的话，90%到命中都是1，10%命中0才insert。 这样的话，每条数据还是要对数据库执行两次操作 两边的数据都全部取出来做成两个二维数组，然后通过算法拆分成需要导入的，需要更新的，需要删除的数据，分别执行insert，update和delete，不过内存要求高。。。 |
| 返回顶楼 | |
|
发表时间：2008-09-17
找出符合条件的数据，一次性插入
|
| 返回顶楼 | |
|
发表时间：2008-09-17
update temp_ybqy a set a.yxbz=1 where not exists(select 1 from dj_nsrxx b where b.nsrsbh=a.nsrsbh)
可以把要插入的数据建立一张临时表。然后在用“not exists”比较。效率非常高 |
| 返回顶楼 | |
