f****4
发帖数: 1359 | 1 问题描述：
一个容器，大概有40万+的objects，对object有get/set/delete/add操作；这些操作要
求尽快完成。还有几个操作（long run tasks），要求对整个容器所有objects做遍历
，遍历过程会很长（有些费时间的业务处理），这几个操作的要求就是只对snapshot做
。就是说一旦开始遍历，后面来的set/delete/add操作完全不关心，等到这次操作结束
下次再处理。
这些long run tasks会增加。支持多线程。每个object的get/set操作很频繁。
我能想到的就是一旦long run task开始跑了，到它完成前对所有发生的object操作全
部更新在临时对象上。等task结束了，和容器里的对象同步。好处是实现方便，坏处是
内存太浪费了，同步浪费时间。没讲清楚：因为task太耗时间，直接对每个object拷贝
一份更快，但内存就费得更多了。。。
有啥好的点子？ |
w***g
发帖数: 5958 | 2 做snapshot最牛的思路莫过于基于日志的数据结构。你可以参考一下Log-Structured
File System，或许会有启发。
【在 f****4 的大作中提到】
: 问题描述：
: 一个容器，大概有40万+的objects，对object有get/set/delete/add操作；这些操作要
: 求尽快完成。还有几个操作（long run tasks），要求对整个容器所有objects做遍历
: ，遍历过程会很长（有些费时间的业务处理），这几个操作的要求就是只对snapshot做
: 。就是说一旦开始遍历，后面来的set/delete/add操作完全不关心，等到这次操作结束
: 下次再处理。
: 这些long run tasks会增加。支持多线程。每个object的get/set操作很频繁。
: 我能想到的就是一旦long run task开始跑了，到它完成前对所有发生的object操作全
: 部更新在临时对象上。等task结束了，和容器里的对象同步。好处是实现方便，坏处是
: 内存太浪费了，同步浪费时间。没讲清楚：因为task太耗时间，直接对每个object拷贝
|
f****4
发帖数: 1359 | 3 谢谢，我去看看。
log的话估计悬，主要get可能会受影响。得试试看。
在优化老模块，条条框框太多了 -_-
【在 w***g 的大作中提到】
: 做snapshot最牛的思路莫过于基于日志的数据结构。你可以参考一下Log-Structured
: File System，或许会有启发。
|
g*****g
发帖数: 34805 | 4 Take a page from DB cluster design. You use a replica for long running job.
Updates are logged, batched and asynchronous.
If your objects are in memory, logging does you no good, but you can still
batch and update async. And if memory is a concern, who says replica can't
be in a different machine.
【在 f****4 的大作中提到】
: 问题描述：
: 一个容器，大概有40万+的objects，对object有get/set/delete/add操作；这些操作要
: 求尽快完成。还有几个操作（long run tasks），要求对整个容器所有objects做遍历
: ，遍历过程会很长（有些费时间的业务处理），这几个操作的要求就是只对snapshot做
: 。就是说一旦开始遍历，后面来的set/delete/add操作完全不关心，等到这次操作结束
: 下次再处理。
: 这些long run tasks会增加。支持多线程。每个object的get/set操作很频繁。
: 我能想到的就是一旦long run task开始跑了，到它完成前对所有发生的object操作全
: 部更新在临时对象上。等task结束了，和容器里的对象同步。好处是实现方便，坏处是
: 内存太浪费了，同步浪费时间。没讲清楚：因为task太耗时间，直接对每个object拷贝
|
w***g
发帖数: 5958 | 5 人可能受不了eventual consistancy.
.
【在 g*****g 的大作中提到】
: Take a page from DB cluster design. You use a replica for long running job.
: Updates are logged, batched and asynchronous.
: If your objects are in memory, logging does you no good, but you can still
: batch and update async. And if memory is a concern, who says replica can't
: be in a different machine.
|
g*****g
发帖数: 34805 | 6 受不了就不会谈 snapshot了。
【在 w***g 的大作中提到】
: 人可能受不了eventual consistancy.
:
: .
|
f****4
发帖数: 1359 | 7 不是所有地方都能想加机器就加机器的。这点传统IT不如你们做服务的爽。。。
优化了点别细节，提高了点速度。这块留着下回再说吧。
.
【在 g*****g 的大作中提到】
: Take a page from DB cluster design. You use a replica for long running job.
: Updates are logged, batched and asynchronous.
: If your objects are in memory, logging does you no good, but you can still
: batch and update async. And if memory is a concern, who says replica can't
: be in a different machine.
|
n****1
发帖数: 1136 | 8 这种需求在fp中非常常见，因为data structure都是immutable, 所以每个add/delete
都会生成new copy, 但完全在内存层复制性能消耗太大，所以就做copy on write, 专
业点叫persistent data structure
你可以看看boost里面的Boost.Flyweight, java里面也应该有类似的data structure.
【在 f****4 的大作中提到】
: 问题描述：
: 一个容器，大概有40万+的objects，对object有get/set/delete/add操作；这些操作要
: 求尽快完成。还有几个操作（long run tasks），要求对整个容器所有objects做遍历
: ，遍历过程会很长（有些费时间的业务处理），这几个操作的要求就是只对snapshot做
: 。就是说一旦开始遍历，后面来的set/delete/add操作完全不关心，等到这次操作结束
: 下次再处理。
: 这些long run tasks会增加。支持多线程。每个object的get/set操作很频繁。
: 我能想到的就是一旦long run task开始跑了，到它完成前对所有发生的object操作全
: 部更新在临时对象上。等task结束了，和容器里的对象同步。好处是实现方便，坏处是
: 内存太浪费了，同步浪费时间。没讲清楚：因为task太耗时间，直接对每个object拷贝
|
