none
对内存表的测试发现的问题 RRS feed

  • 问题

  •  1、使用TSQL如 insert update delete ,操作内存表比操作磁盘表要略慢一些
     2、 如果使用本地编译的存储过程进行操作,与操作磁盘表相比:select操作几乎差不多,一条一条的对表中的数据进行insert update delete却有非常绝对的优势

     3:使用c#写了一个并发测试程序,同时打开10000个线程,SQL里面是一条update语句,对表中仅某一行进行修改操作,结果发现:
           对磁盘表操作明显快于本地编译的存储过程的内存表操作,而且后者还会约有5%的失败率,因为采用乐观控制原理,将被回滚,而不是磁盘表那种阻塞 对于这种劣势,某些业务的确是存在的,如:大量用户看同一种商品,而且又不能容忍延时的话,就会存在这种需求,那么如何解决呢,如果内存表不能解决这种类似的问题,我觉得也有很大的遗憾

         还有一点:5%的失败率说明争用并不是很强,不应该比磁盘表的操作慢才对赛,这是为何呢?

    2014年12月29日 10:39

答案

  • 最好把你的测试表结构和更新语句都贴出来,随机更新,还是更新同一条,考虑的因素是不一样的,表的数据量大时的随机更新和小表的随机更新考虑的因素也不一样

    “%的失败率说明争用并不是很强” 这个理论不成立, 失败和争用不能划等号,合理的加锁,执行超时够长,则并发不会失败,只是在等待,不能说明并发不强

    2015年1月6日 1:43

全部回复

  • How did you set memory residence table? How did you set logging? How much memory allocated to sql?
    2014年12月29日 19:53
  • 哈哈哈,这么复杂!

    bucket_count=1000000 ,但是 插入的数据仅仅10w条

    全部采用的是持久化的内存表!


    2014年12月30日 7:20
  • 要理解内存表是hash而不是b+ tree。另外,idu也是要写日志文件的(非持久化不写)。

    失败了要考虑retry。

    你的并发测试是对同一行修改操作吗?

    bucket_count=1000000 ,内存足够用吗?


    想不想时已是想,不如不想都不想。

    2015年1月3日 9:52
    版主
  • 最好把你的测试表结构和更新语句都贴出来,随机更新,还是更新同一条,考虑的因素是不一样的,表的数据量大时的随机更新和小表的随机更新考虑的因素也不一样

    “%的失败率说明争用并不是很强” 这个理论不成立, 失败和争用不能划等号,合理的加锁,执行超时够长,则并发不会失败,只是在等待,不能说明并发不强

    2015年1月6日 1:43