再发一请求:关于数据库和内存数据同步的问题

4 views
Skip to first unread message

ben

unread,
Nov 15, 2009, 7:09:26 AM11/15/09
to 高性能服务器研发与运营邮件列表
感觉这里面高手如云啊,现在有个需求麻烦大家:就是一个海量数据和内存同步,如果是服务程序定时轮询的话,需要把内存锁住,服务程序就没法处理业务了,
性能较差,还有没有别的办法?请达人指点。

deng zhengping

unread,
Nov 15, 2009, 9:31:49 AM11/15/09
to dev4s...@googlegroups.com
锁范围设计小点。
比如我们操作数据库一般情况是不锁表,而是锁行或锁记录。

Hailong Shu

unread,
Nov 15, 2009, 8:29:25 PM11/15/09
to dev4s...@googlegroups.com
问题描述的不太清楚。
1.海量数据的数据量。
2.关系式数据库和内存数据库的对应关系,1:1或者1:N。如果是后者,理论上更新只需要锁住N这部分,这个是可以通过关系式数据库的设计来达到这一点的。

基本上海量数据的优化都是通过良好的设计来达到这一点。比如硬件采取多个并行读写的硬盘,设计上把根据应用逻辑把数据分配到各个不同的硬盘上。同时数据表采取分区机制。

楼主需要把自己的应用说的更加清楚点,数据库同步的优化设计到应用细节才能给出有效的建议。

2009/11/15 deng zhengping <dengzh...@gmail.com>:
> 锁范围设计小点。
> 比如我们操作数据库一般情况是不锁表,而是锁行或锁记录。
>
> 2009/11/15 ben <lizp...@gmail.com>

raymond

unread,
Nov 16, 2009, 7:15:36 AM11/16/09
to 高性能服务器研发与运营邮件列表
这位兄弟说的对,锁是必须的,无非粒度大小不同。除非你允许数据不一致。
你可以看看google的big table和chubby lock service,对于你这样需要将大量数据加载到内存的应用有点用。

On 11月15日, 下午10时31分, deng zhengping <dengzhengp...@gmail.com> wrote:
> 锁范围设计小点。
> 比如我们操作数据库一般情况是不锁表,而是锁行或锁记录。
>

> 2009/11/15 ben <lizp....@gmail.com>

杨光

unread,
Nov 17, 2009, 12:02:04 AM11/17/09
to dev4s...@googlegroups.com
看你两边数据同步是否需要实时性。不需要实时可以定时保存,也不需要锁定内存,反正数据下一秒就可能改变,锁了也没用。需要实时性,你做个分发数据的程序吧,修改内存数据和入库同时进行。

2009/11/16 raymond <shiq...@gmail.com>

无双大蛇

unread,
Nov 20, 2009, 10:08:58 PM11/20/09
to 高性能服务器研发与运营邮件列表
能不能这样:
1、在你写内存之前先把准备要写入数据的(SQL语句+特殊标志符A)写到某个Request-Log文件中,然后再修改内存;
2、把SQL语句发送到另外一条线程执行,再把(执行结果+特殊标志符A)写到某个Response-Log文件中;
3、再启动一个进程来实时扫描这两个文件,发现一旦Request-Log和Response-Log(就有一个里面没有A)对不上,那么就做相应的差
错处理。

这样子做的目的主要是要将耗时多的数据库操作和耗时少的内存读取分离,保证了内存操作线程能够花更多的时间在操作内存上
而数据库操作线程和内存操作线程的数量是N:1的关系;这个模型的另外一个设计思路是:让内存线程认为数据库线程是一定能
执行成功的,而减少了回调和差错处理。把差错处理留给了其他进程完成

Tomt

unread,
Nov 21, 2009, 4:17:37 AM11/21/09
to dev4s...@googlegroups.com
看了上面的帖子,我有一个疑惑,如果是分布式的数据库,同时数据是实时性很重要,比如说银行的数据库,这个怎么处理呢?

Hailong Shu

unread,
Nov 26, 2009, 9:12:27 AM11/26/09
to dev4s...@googlegroups.com
银行的同步数据是有限的(比如账户上还有多少钱)。
历史数据时快照(比如上个月的操作明细)

海量数据的总原则就是通过设计来用时间换空间。

2009/11/21 Tomt <tomtf...@gmail.com>:

Reply all
Reply to author
Forward
0 new messages