海量数据的删除策略

海量数据删除还真是头疼的事情，我用的是“分解动作”，还是熬不过数据库，什么事务日志不够，表空间不够。。。

恩，删除时要考虑分批多线程删除。

分批为啥还有多线程？是否需要考虑锁的问题？

学习了，不过有时候业务上决定你采用的方案，当上亿条数据 需要删除的时候 就很恐怖了。

比方说，年终了，银行要结算一些数据，从A库倒到B库，A库里要删除数据，这时候可能是上亿的数据量。同时这样的删除可能因为业务需要一条一条删而且这一条删除之后，下一条数据的删除之前需要根据这一条删除后，B库里发生的变化而进行校验。那么IO量之大就可想而知了。 这样的情况，怎么处理比较合适

1.延迟删除
一条数据会被很多数据引用。当被引用的数据删除时，引用的数据也需要删除。这时候可以用延迟删除的方法。
例子：
用户发表的帖子，可以被转发到很多地方。所有转发过的贴都是对原帖的引用，用户接着把他的原帖删除，所有被转发过的帖子也需要进行清理。我们采用的是延迟删除的方法，用户操作时，先直接删除原帖，被转发的贴，在点击时，会到原帖加载内容，这时发现原帖已经不存在，此时这条被点击的转发贴也会被删除。

当用户访问引用的数据时，发现被引用的数据不存在，此时删除引用的数据。

2.线下删除
一条数据关联到很多数据。但这条数据是所有其他数据的入口。
例子：
一个扣扣群里，会有很多内容，相册，图片等等。在解散扣扣群时是不可能同步删除和该群相关的所有数据的。此时可以用线下删除的方法。先将扣扣群的状态置为 inactive（解散）状态。然后提交一条任务，在指定的时候将所有和该扣扣群相关的数据都删除。任务可以在系统负载比较低的时候触发。因为扣扣群的状态已经被设置为inactive状态，它也不会再被其他人访问到。所有访问需要加状态进行判断。

3.异步删除
当某个系统的服务和其他系统的服务做了集成后，业务数据就可能是相互关联的。当某个服务的数据被删除时，需要通知相关联的所有系统删除和他相关联的数据。
例子：
用户会对他所加入的群进行了偏好设置，比如对某个群的评价，是否接收该群的通知等等。而这些数据是存在用户系统（其他服务器）上的。当一个群组被解散时，无法同步地调用用户系统的服务删除所有的数据。因为一个群组可能有几万甚至更多的成员。此时可以用异步的方式通知用户系统，群组系统发送一条“群解散”消息给用户系统，用户系统接收到消息后，会把所有相关联的数据都清除。

延迟删除结合使用：
如果数据量很大的话异步删除也需要相当长的时间，这时可以结合使用延迟删除的方法。
当用户在用户中心点击某群的偏好设置时，系统发现该群组已经被删除，就通知用户该群不存在，并删除相关的偏好设置。

线下删除结合使用
数据量很大如果立即删除会给系统突发地带来相当大的负载，甚至可能会引起用户访问的响应率降低。这时需要采用线下删除的方法，将删除任务分割成很多很小的任务。分批地提交给系统定时处理。

4.不删除
有些相关联的数据，重要性很低，又有有效期。我们是不会再花费额外的代价去删除它们的。

例子：
系统会记录用户的访问足迹。用户可以查询他的这些访问足迹。
您在2011.02.03在群组B（链接）回复了C（链接）发表的帖子D（链接）。
当B被解散或D被删除后，不需要主动去清理这条数据。因为所有的访问足迹都是有有效期的，当有效期到了的时候，这条数据就会被自动清除。
但是当D被删除后，用户点击D链接会提示用户404。

延迟删除结合使用：
如果数据量很大的话异步删除也需要相当长的时间，这时可以结合使用延迟删除的方法。
当用户在用户中心点击某群的偏好设置时，系统发现该群组已经被删除，就通知用户该群不存在，并删除相关的偏好设置。