近年厂家采纳,前天在数量迁移的时候因为手贱碰到多少个坑爹难题澳门永利娱乐总站

 汇总篇:http://www.cnblogs.com/dunitian/p/4822808.html#tsql

http://www.cnblogs.com/heyuquan/p/global-guid-identity-maxId.html

后日在数额迁移的时候因为手贱蒙受贰个坑爹难点,发来大家乐乐,也传授菜鸟点经历

又四个多月没冒泡了,其实多年来学了些东西,不过尚未配备时间整治成博文,后续再奉上。前段时间还写了二个发邮件的零件以及品质测量试验请看 《NET开辟邮件发送功效的通盘教程(含邮件组件源码)》 ,还弄了个MSSQL参数化语法生成器,会在一月整理出来,风野趣的园友能够关切下自家的博客。

搬迁惯用就是不经常表只怕新库,常常用的语法有广大,本次重大说的是其一:select * into 数据库名..表名 from xxx

 

先不扯了,先看错误:

享用原由,前段时间供销合作社采用,並且在找最合适的方案,希望大家多加入座谈和提议新方案。作者和作者的伴儿们也斟酌了那么些主旨,笔者有相当的大的收获啊……

澳门永利娱乐总站 1

 

不久看看是或不是数据再次~事实表明,木有重复数据。。。

博文示例:

澳门永利娱乐总站 2

  1. GUID生成Int64值后是不是还装有独一性测量检验
  2. Random生成高独一性随机码

有人会问,你怎么那样求count?。。。额,小编会的是最核心的不二诀窍,常见的三种其实品质一样的,相比图:(有更加好写法能够提点一下小弟^_^

 

澳门永利娱乐总站 3

明天分享的大旨是:如何在高并发遍布式系统中变化全局独一Id。

澳门永利娱乐总站 4

但这篇博文实际上是“半分享半商讨”的博文:

得了,查下改ID下的多寡:到底是或不是重新~~~不是。。。

1)         半分享是本人将说下小编所掌握到的有关后天大旨所波及的二种方案。

澳门永利娱乐总站 5

2)         半商讨是本身愿意咱们对一一方案都说说本人的意见,越发期望我们能建议更加好的方案。(作者还另外提问在此:http://q.cnblogs.com/q/53552/上面已有三人园友回复(谢谢dudu站长的到场),若你们有意见和新方案就在本博文留言吧,方便小编收拾更新到博文中,多谢!)

行吧,这大家就看看同三个ID重复次数

 

澳门永利娱乐总站 6

本人询问的方案如下……………………………………………………………………

紧凑想了下,整个搬迁进度,貌似木有怎么着错误,难道是其一手贱的原故??(命令没实行完,点了几许次加快,也不掌握是不是那一个缘故促成的,好呢就当是他了===》( ̄— ̄))

1、  使用数据库自增Id

澳门永利娱乐总站 7

优势:编码轻巧,没有供给思量记录唯一标志的标题。

消除措施:两种,一种正是重复来壹回数据迁移整理

缺陷:

第二种正是Id先删了,再建(因为数量没难点,即使多少出标题了,那不管怎么说都得重来二回)

1)         在大表做水平分表时,就不可能选拔自增Id,因为Insert的记录插入到哪些分表依分表准则判定决定,假如自增Id,各种分表中Id就能够再次,在做询问、删除时就能够有充足。

澳门永利娱乐总站 8

2)         在对表进行高并发单记录插入时需求步入事物机制,不然会出现Id重复的标题。

脚本:

3)         在业务上操作父、子表(即关联表)插入时,须求在插入数据库之前得到max(id)用于标识父表和子表关系,若存在并发获取max(id)的动静,max(id)会同时被其他线程获取到。

alter table Info01 drop column Id
go
alter table info01 add Id int identity(1,1) primary key
go

4)         等等。

 现在终于精晓,为何很繁多据库的主键都是在最终一列了

敲定:相符小应用,不供给分表,未有高并发质量供给。

澳门永利娱乐总站 9

2、  单独开三个数据库,获取全局独一的自增连串号或各表的MaxId

说起底说建议的话,对于这种多表的最佳照旧用程序来支配和处理多少(你得保障标记唯一),若是不管标记就随意搞了~

1)         使用自增种类号表

 

极度三个数据库,生成类别号。开启事物,每回操作插入时,先将数据插入到种类表并赶回自增种类号用于做为独一Id实行作业数据插入。

小心:供给按期清理种类表的数量以担保收获种类号的频率;插入类别表记录时要打开事物。

应用此方案的主题材料是:每一趟的查询种类号是叁本性能损耗;假如那几个队列号列暴了,那就杯具了,你不领悟哪个表使用了哪位体系,所以就必得换另一种独一Id格局如GUID。

2)         使用马克斯Id表存储各表的马克斯Id值

特意一个数据库,记录各类表的马克斯Id值,建三个存储进度来取Id,逻辑大概为:开启事物,对于在表中不设有记录,直接再次来到叁个暗中同意值为1的键值,同不时间插入该条记录到table_key表中。而对此已存在的记录,key值直接在本来的key基础上加1更新到MaxId表中并回到key。

运用此方案的主题材料是:每一遍的询问马克斯Id是三个属性损耗;不过不会像自增系列表那么轻巧列暴掉,因为是摆表举行剪切的。

详见可参谋:《使用马克斯Id表存储各表的马克斯Id值,以博取全局独一Id》

                   作者截取此文中的sql语法如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
第一步:创建表
create table table_key
(
       table_name   varchar(50) not null primary key,
       key_value    int         not null
)
 
 
第二步:创建存储过程来取自增ID
create procedure up_get_table_key
(
   @table_name     varchar(50),
   @key_value      int output
)
as
begin
     begin tran
         declare @key  int
          
         --initialize the key with 1
         set @key=1
         --whether the specified table is exist
         if not exists(select table_name from table_key where table_name=@table_name)
            begin
              insert into table_key values(@table_name,@key)        --default key vlaue:1
            end
         -- step increase
         else   
            begin
                select @key=key_value from table_key with (nolock) where table_name=@table_name
                set @key=@key+1
                --update the key value by table name
                update table_key set key_value=@key where table_name=@table_name
            end
        --set ouput value
    set @key_value=@key
 
    --commit tran
    commit tran
        if @@error>0
      rollback tran
end

谢谢园友的好建议:

  1. @辉_辉)建议给table_key中为各样表起始化一条key为1的记录,那样就不用每一次if来判别了。
  2. @乐活的CodeMonkey)提出给存款和储蓄进度中数据库事物隔绝等第进步级中学一年级下,因为现身在CS代码层上选用如下事物代码会变成出现重复难题.
1
2
3
4
5
6
7
8
TransactionOptions option = new TransactionOptions();
option.IsolationLevel = IsolationLevel.ReadUncommitted;
option.Timeout = new TimeSpan(0, 10, 0);
  
using (TransactionScope transaction = new TransactionScope(TransactionScopeOption.RequiresNew, option))
{
        //调用存储过程
}

在咨询过DBA后,这一个蕴藏进程提升数据库阻隔等级会加大数据库访谈压力,导致响应超时难点。所以这一个指出大家只幸好代码编写宣传引导上做。

  1. @马铃薯烤肉)存款和储蓄进度中不应用事物,一旦选择到东西性质就能够下滑。直接选拔UPDATE获取到的换代锁,即SQL
    SE昂科拉VE科雷傲会保险UPDATE的逐一实施。(已在客商过相对化的产出系统中应用)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
create procedure [dbo].[up_get_table_key]
(
   @table_name     varchar(50),
   @key_value      int output
)
as
begin
 
    SET NOCOUNT ON;
    DECLARE @maxId INT
    UPDATE table_key
    SET @maxId = key_value,key_value = key_value + 1
    WHERE table_name=@table_name
    SELECT @maxId
 
end

敲定:适用中型应用,此方案化解了分表,关联表插入记录的标题。可是敬敏不谢知足高并发质量供给。同时也存在单点问题,假设那一个数据库cash掉的话……

我们脚下正感冒这些主题材料,因为大家的高并发日常出现数据库访谈超时,瓶颈就在这些马克斯Id表。大家也许有思索使用遍布式缓存(eg:memcached)缓存第一遍访谈马克斯Id表数据,以增长再次访谈速度,并定期用缓存数据更新一回马克斯Id表,但大家担忧的难点是:

a)         借使缓存失效或暴掉了,那缓存的MaxId没有立异到数据库导致数据错过,必得停掉站点来奉行Select
max(id)各类表来同步马克斯Id表。

b)         遍及式缓存不是一保存下去,别的服务器上就立时能够获得到的,即数据存在不明确性。(其实也是缓存的二个误用,缓存应该用来存的是几度拜谒何况比少之甚少改变的剧情)

         勘误方案:

完全观念:创立两台以上的数据库ID生成服务器,每一个服务器都有一张记录各表当前ID的马克斯Id表,不过马克斯Id表中Id的滋长幅度是服务器的数据,早先值依次错开,那样也便是把ID的变通散列到每一种服务器节点上。比方:倘诺大家设置两台数据库ID生成服务器,那么就让一台的马克斯Id表的Id最初值为1(或当前最大Id+1),每回增幅为2,另一台的马克斯Id表的ID伊始值为2(或当前最大Id+2),每一遍步长也为2。那样就将发出ID的压力均匀分散到两台服务器上,同期包容应用程序调控,当一个服务器失效后,系统能自行切换来另一个服务器上获取ID,从而化解的单点难题保险了系统的容错。(Flickr理念)

可是要小心:1、多服务器就不能够不面前遭逢负载均衡的标题;2、若是增加新节点,须求对本来数据重复根据步长计算迁移数据。

敲定:符合大型应用,生成Id极短,友好性相比好。(猛烈推荐)

3、  Sequence特性

这一个特点在SQL Server
2011、Oracle中可用。那特本性是数据库等级的,允许在八个表之间分享种类号。它能够减轻分表在同一个数据库的境况,但万一分表放在分歧数据库,那将分享不到此连串号。(eg:Sequence使用情形:你须要在多个表之间公用八个流水号。今后的做法是非凡创建二个表,然后存款和储蓄流水号)

连带Sequence天性资料:

SQL
Server2012中的SequenceNumber尝试

SQL Server
二〇一二 开荒新功效——类别对象(Sequence)

identity和sequence的区别

Difference between Identity and Sequence in SQL Server
2012

敲定:适用中型应用,此方案无法完全解决分表难题,并且不可能满意高并发品质要求。同时也存在单点难点,假使这些数据库cash掉的话……**

4、  通过数据库集群编号+集群内的自增类型多少个字段共同组成独一主键

可取:完成轻易,维护也相比轻松。

症结:关联表操作相对相比较复杂,要求四个字段。并且作业逻辑必得是一开首就设计为处理复合主键的逻辑,倘若是到了前期,由单主键转为复合主键那改变开支就太大了。

结论:切合大型应用,但需求工作逻辑合营管理复合主键。

5、  通过安装每一种集群中自增 ID 开始点(auto_increment_offset),将次第集群的ID实行绝对的分层来促成全局独一。当际遇有个别集群数据增加过快后,通过命令调度下叁个 ID 早先地点跳过或然存在的龃龉。

可取:达成轻松,且比较便于遵照 ID 大小直接决断出多少处在哪个集群,对利用透明。劣势:维护相对较复杂,供给低度关切种种集群 ID 拉长现象。

敲定:符合大型应用,但需要高度关心各种集群 ID 增进现象。

6、  GUID(Globally Unique
Identifier,全局独一标记符)

GUID常常表示成35个16进制数字(0-9,A-F)组成的字符串,如:{21EC2020-3AEA-1069-A2DD-08002B30309D},它实质上是三个129位长的二进制整数。

GUID制订的算法中选取到客商的网卡MAC地址,以管教在Computer集群中生成独一GUID;在同一Computer上任意生成三个一样GUID的恐怕性是极其小的,但并不为0。所以,用于生成GUID的算法平常都加入了非随机的参数(如时间),以管教这种重新的事态不会发生。

优点:GUID是最不难易行的方案,跨平台,跨语言,跨业务逻辑,全局独一的Id,数据间一块、迁移都能大概实现。

缺点:

1)         存款和储蓄占了三十多少人,且无可读性,重返GUID给顾客出示十分不标准;

2)         占用了宝贵的聚焦索引,日常大家不会依靠GUID去查单据,何况插入时因为GUID是无须的,在集中索引的排序法则下恐怕移动大量的记录。

有两位园友首荐GUID,无须顺序GUID方案原因如下:

@徐少侠           GUID冬辰在并发下功能高,而且一个数量页内增加新行,是在B树内扩大,本质未有啥数据被移动,独一大概的,是页填充因子满了,要求拆页。而GUID方案导致的拆页比顺序ID要低太多了(数据库不是很懂,暂且不能够确定,大家温馨认知)

@无色                我们要驾驭id是哪些,是身价标记,标志身份是id最大的专门的学业逻辑,不要引进什么日子,什么顾客业务逻辑,那是其他二个字段干的事,使用base64(guid,uuid),是通盘考虑,完全能够越来越好的相称nosql,key-value存款和储蓄。

(推荐),可是一旦你系统一开端并未有安排一个职业Id,那么将导致大气的改动,所以这一个方案的特等状态是一早先就盘算职业Id,当然事情Id的独一性也是大家要思虑的。

敲定:切合大型应用;生成的Id相当不足自个儿;攻下了34个人;索引成效异常低。

改进:

1)         (@dudu提点)在SQL Server
二〇〇五中新扩展了NEWSEQUENTIALID函数。

详尽请看:《理解newid()和newsequentialid()》

在内定Computer上创制大于先前透过该函数生成的别的 GUID 的 GUID。 newsequentialid 爆发的新的值是有规律的,则索引B+树的改造是有规律的,就不会导致索引列插入时移动多量记录的主题材料。

但若是服务珍视新启航,其再一次转移的GUID大概反倒变小(但照旧维持独一)。那在比非常大程度上抓实了目录的性格,但并无法担保所生成的GUID一贯增大。SQL的那几个函数发生的GUID很简短就可以预测,因而不合乎用来安全目标。

a)         只可以做为数据库列的DEFAULT VALUE,不能施行类似SELECT
NEWSEQUENTIALID()的语句.

b)         怎么样获得生成的GUID.

只要生成的GUID所在字段做为外键要被别的表使用,大家就要求取得那么些变化的值。平常,PK是三个IDENTITY字段,大家得以在INSERT之后实施 SELECT
SCOPE_IDENTITY()来获取新生成的ID,然而出于NEWSEQUENTIALID()不是一个INDETITY类型,那几个格局是做不到了,而她自身又不得不在默许值中应用,不得以先行SELECT好再插入,那么大家怎么着获取呢?有以下二种格局:

1
2
3
4
5
6
7
8
9
10
11
12
--1. 定义临时表变量
DECLARE @outputTable TABLE(ID uniqueidentifier)
INSERT INTO TABLE1(col1, col2)
OUTPUT INSERTED.ID INTO @outputTable
VALUES('value1', 'value2')
SELECT ID FROM @outputTable
  
--2. 标记ID字段为ROWGUID(一个表只能有一个ROWGUID)
INSERT INTO TABLE1(col1, col2)
VALUES('value1', 'value2')
--在这里,ROWGUIDCOL其实相当于一个别名
SELECT ROWGUIDCOL FROM TABLE1

敲定:切合大型应用,化解了GUID严节天性导致索引列插入移动大批量记下的难点。可是在关联表插入时必要重返数据库中变化的GUID;生成的Id远远不够自个儿;攻克了叁拾三人。

2)         “COMB”(combined guid/timestamp,意思是:组合GUID/时间截)

(感谢:@
ethan-luo
 ,@lcs-帅 )

COMB数据类型的中坚安顿思路是如此的:既然GUID数据因并不是规律可言产生索引成效低下,影响了系统的性质,那么能或不能够经过整合的办法,保留GUID的十三个字节,用另6个字节表示GUID生成的日子(DateTime),那样大家将时刻消息与GUID组合起来,在保留GUID的独一性的同期增添了有序性,以此来巩固索引效用。

在NHibernate中,COMB型主键的浮动代码如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
/// <summary> /// Generate a new <see cref="Guid"/> using the comb algorithm.
/// </summary>
private Guid GenerateComb()
{
    byte[] guidArray = Guid.NewGuid().ToByteArray();
 
    DateTime baseDate = new DateTime(1900, 1, 1);
    DateTime now = DateTime.Now;
 
    // Get the days and milliseconds which will be used to build   
    //the byte string   
    TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks);
    TimeSpan msecs = now.TimeOfDay;
 
    // Convert to a byte array       
    // Note that SQL Server is accurate to 1/300th of a   
    // millisecond so we divide by 3.333333   
    byte[] daysArray = BitConverter.GetBytes(days.Days);
    byte[] msecsArray = BitConverter.GetBytes((long)
      (msecs.TotalMilliseconds / 3.333333));
 
    // Reverse the bytes to match SQL Servers ordering   
    Array.Reverse(daysArray);
    Array.Reverse(msecsArray);
 
    // Copy the bytes into the guid   
    Array.Copy(daysArray, daysArray.Length - 2, guidArray,
      guidArray.Length - 6, 2);
    Array.Copy(msecsArray, msecsArray.Length - 4, guidArray,
      guidArray.Length - 4, 4);
 
    return new Guid(guidArray);
}

结论:符合大型应用。即保留GUID的独一性的还要增添了GUID有序性,升高了索引功效;化解了关联表业务难点;生成的Id缺乏自个儿;攻克了三二十一人。(猛烈推荐)

3)         长度难点,使用Base64或Ascii85编码消除。(要在意的是上述有序性方案在开展编码后也会变得无序)

如:

GUID:{3F2504E0-4F89-11D3-9A0C-0305E82C3301}

当必要使用更加少的字符表示GUID时,大概会采纳Base64或Ascii85编码。Base64编码的GUID有22-25个字符,如:

7QDBkvCA1+B9K/U0vrQx1A

7QDBkvCA1+B9K/U0vrQx1A==

Ascii85编码后是22个字符,如:

5:$Hj:Pf\4RLB9%kU\Lj

                   代码如:

         Guid guid = Guid.NewGuid();

         byte[] buffer = guid.ToByteArray();

         var shortGuid = Convert.ToBase64String(buffer);

                   敲定:切合大型应用,缩小GUID的长短。生成的Id缺乏本人;索引功用极低。

7、  GUID TO Int64

对此GUID的可读性,有园友给出如下方案:(谢谢:@深褐的羽翼

1
2
3
4
5
6
7
8
/// <summary>
/// 根据GUID获取19位的唯一数字序列
/// </summary>
public static long GuidToLongID()
{
    byte[] buffer = Guid.NewGuid().ToByteArray();
    return BitConverter.ToInt64(buffer, 0);
}

将在GUID转为了17位数字,数字反映给顾客能够肯定水平上化解友好性难题。EG:

GUID: cfdab168-211d-41e6-8634-ef5ba6502a22    (不友好)

Int64:
5717212979449746068                                      (友好性尚可)

只是本身的伴儿说ToInt64后就不唯一了。由此笔者非常写了个冒出测量试验程序,后文将交由测验结果截图及代码轻松表达。

(独一性、业务相符性是能够衡量的,这一个独一性确定比可是GUID的,通常程序上都会陈设错误管理机制,比方极其后进行一遍重插的方案……)

结论:契合大型应用,生成相对友好的Id(纯数字)–—-因简单和专门的学业友好性而推荐。**

8、  本人写编码法规

可取:全局独一Id,切合业务后续浓厚的进化(恐怕实际业务供给和谐的编码法则等等)。

瑕疵:依据现实编码准绳完成而各异;还要思索即使主键在业务上同意改变的,会带来外键同步的分神。

自个儿这边写三个编码法则方案:(可能不唯一,只是私家方案,也请我们建议自个儿的编码准绳)

1)         拾壹人年月日时分秒+5位随机码+3位服务器编码  (那样就全盘单机完结生成全局独一编码)—共十多少人

破绽:因为附带随机码,所以编码贫乏一定的顺序感。(生成高独一性随机码的方案稍后给给出程序)

2)         10个人年月日时分秒+5位流水码+3位服务器编码 (那样流水码就须要结合数据库和缓存)—共十十个人  (将影响顺序权重大的“流水码”放前面,影响顺序权重小的服务器编码放后)

劣势:因为运用到流水码,流水码的浮动必然会凌驾和马克斯Id、种类表、Sequence方案中近乎的难题

(为何未有飞秒?阿秒也不富有业务可读性,作者改用5位随机码、流水码替代,估摸1秒内相应不会下99999[五位]条语法)

 

结论:相符大型应用,从作业上来讲,有八个准则的编码能浮现产品的专门的学业成度。(刚毅推荐)

 

 

GUID生成Int64值后是还是不是还怀有独一性测量试验

测量试验情形

 

重大测验思路:

  1. 传闻内核数使用十二线程并发出成Guid后再转为Int陆十个人值,放入集结A、B、…N,多少个线程就有微微个汇集。
  2. 再利用Dictionary字典高效查key的特征,将步骤第11中学变化的多少个汇聚全部加到Dictionary中,看是不是有重复值。

躬行实践注脚:测了 Dictionary<long,bool> 最大体量就在5999470左右,所以每一遍并发生成的独一值总量调控在此限制内,让测量试验高达最有效话。

重视代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
for (int i = 0; i <= Environment.ProcessorCount - 1; i++)
{
    ThreadPool.QueueUserWorkItem(
        (list) =>
        {
            List<long> tempList = list as List<long>;
            for (int j = 1; j < listLength; j++)
            {
                byte[] buffer = Guid.NewGuid().ToByteArray();
                tempList.Add(BitConverter.ToInt64(buffer, 0));
            }
            barrier.SignalAndWait();
        }, totalList[i]);
}

测量检验数据截图:                                                                           

 

 

数据一(循环1000次,测试数:1000*5999470)

 

数据二(循环5000次,测试数:5000*5999470)–跑了二个晚间……

 

 

感谢@Justany_WhiteSnow的行业内部回答:(我们深入分析下,笔者数学比非常差,稍后再说自个儿的明白)

GUID桶数量:(2 ^ 4) ^ 32 = 2 ^ 128

Int64桶数量: 2 ^ 64

假如每种桶的空子是均等的,则每个桶的GUID数量为:

(2 ^ 128) / (2 ^ 64) = 2 ^ 64 = 18446744073709551616

也正是说,其实重复的时机是有的,只是可能率难题。

楼主测验数是29997340000,发生再一次的票房价值是:

1 – ((1 – (1 / (2 ^ 64))) ^ 29997350000) ≈ 1 – ((1 – 1 / (2 ^ 64)) ^ (2
^ 32)) < 1 – 1 + 1 / (2 ^ 32) = 1 / (2 ^ 32) ≈ 2.3283064e-10

(独一性、业务相符性是足以衡量的,那一个独一性肯定比但是GUID的,通常程序上都会布置错误管理机制,比方极度后举行贰回重插的方案……)

(独一性、业务适合性是可以度量的,这些独一性明确比然而GUID的,日常程序上都会安排错误管理机制,比如特别后施行三次重插的方案……)

结论:GUID转为Int64值后,也许有所高唯一性,可以行使与品种中。

 

Random生成高独一性随机码

自己使用了多样Random生成方案,要Random生成独一首要要素即是种子参数要独一。(那是十分久在此以前写的测验案例了,一贯找不到合适的博文放,前日算是找到适当的地点了)

可是该测量检验是在单线程下的,二十八线程应选取不相同的Random实例,所以对结果影响不会太大。

  1. 应用Environment.TickCount做为Random参数(即Random的私下认可参数),重复性最大。
  2. 运用DateTime.Now.Ticks做为Random参数,存在双重。
  3. 接纳unchecked((int)DateTime.Now.Ticks)做为Random参数,存在双重。
  4. 接纳Guid.NewGuid().GetHashCode()做为random参数,测验空中楼阁重新(或存在性十分的小)。
  5. 采纳RubiconNGCryptoServiceProvider做为random参数,测验一纸空文重复(或存在性相当小)。

即:

        static int GetRandomSeed()

        {

            byte[] bytes = new byte[4];

            System.Security.Cryptography.RNGCryptoServiceProvider rng

= new System.Security.Cryptography.RNGCryptoServiceProvider();

            rng.GetBytes(bytes);

            return BitConverter.ToInt32(bytes, 0);

        }

测量试验结果:

 

结论:随机码使用奥迪Q5NGCryptoServiceProvider或Guid.NewGuid().GetHashCode()生成的独一性较高。

 

 

一部分不错冲突(部分更新到原博文对应的地点)

一、

数据库文件体积只是贰个仿效值,可水平增添系统质量(如nosql,缓存系统)并不和文件体量有高指数的线性相关。

如taobao/qq的体系比拼byte系统慢,关键在于索引的命中率,缓存,系统的品位扩张。

即便数据库很少,你搞那样多byte能增加品质?

万一数据库十分大,你搞那样多byte不宽容索引不相配缓存,不是害自已吗?

假若数据库必要伸缩性,你搞这么多byte,要求不停改程序,不是自找苦啊?

若是数据库供给移植性,你搞那样多byte,移植起来不比重新规划,那是或不是好些个商厦持续加班的原由?

 

不借助于于数据存款和储蓄系统是分段设计理念的卓越,完成战略质量最大化,实际不是追求计谋单机性能最大化。

 

永不迷信数据库质量,不要迷信三范式,不要选择外键,不要采用byte,不要使用自增id,不要使用存款和储蓄进度,不要选用在那之中等学园函授数,不要选择非标准化准sql,存款和储蓄系统只做存储系统的事。当出现系统天性时,如此设计的数据库能够更加好的兑现迁移数据库(如mysql->oracle),完毕nosql改换((mongodb/hadoop),实现key-value缓存(redis,memcache)。

 

二、

过多程序员有对品质认知有误区,如采取存款和储蓄进程代替正常程序,其实使用存款和储蓄进度只是追求单服务器的高品质,当必要服务器水平扩大时,存款和储蓄进程中的业务逻辑就是您的背运。

 

三、

除数字日期,能用字符串存储的字段尽量采纳字符串存款和储蓄,不要为节约那不值钱的1个g的硬盘而选用类似字节之类的字段,进而小幅牺牲系统可伸缩性和可扩张性。

无须为了追求所谓的性质,引进byte,使用byte注定是指日可待和急难移植,想想怎么html,email一向流电行,因为它们采纳的是字符串表示法,只要有人类永世都能分析,如email把二进制转成base64存款和储蓄。除了实时系统,录像外,建议采纳字符串来存储数据,系统本性的关键在于布满式,在于水平扩大。

 

 

这次博文到此停止,希望大家对此番大旨“怎么着在高并发布满式系统中变化全局独一Id”多提议本身宝贵的思想。另外望着认为安适,还请多帮推荐…推荐……

 

 

推荐阅读

         
 C#生成独一值的办法汇总

相关:http://www.cnblogs.com/studyzy/archive/2008/11/28/1342950.html  

在SQL Server中应用种子表生成流水号注意顺序

.NET:“事务、并发、并发难题、事务隔开品级、锁”小议,器重介绍:“事务隔开分离等级”怎样影响 “锁”?

相关文章