前日厂商选拔,迁移惯用正是一时表可能新库

 汇总篇: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、  单独开三个数据库,获取全局唯风流倜傥的自增系列号或各表的马克斯Id

最终说提出的话,对于这种多表的最佳只怕用程序来调整和拍卖数量(你得保证标记唯生龙活虎),若是不管标志就不管搞了~

1)         使用自增种类号表

 

特地贰个数据库,生成连串号。开启事物,每趟操作插入时,先将数据插入到类别表并重回自增系列号用于做为唯风度翩翩Id实行作业数据插入。

留心:须求依期清理体系表的多少以确认保证收获种类号的频率;插入类别表记录时要开启事物。

选用此方案的难点是:每趟的询问系列号是叁性情质损耗;假诺那几个行列号列暴了,那就杯具了,你不知道哪位表使用了哪些连串,所以就非得换另生机勃勃种唯后生可畏Id情势如GUID。

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

特地二个数据库,记录各类表的马克斯Id值,建叁个存储进程来取Id,逻辑差没有多少为:开启事物,对于在表中不设有记录,直接回到多少个暗中认可值为1的键值,同一时候插入该条记录到table_key表中。而对于已存在的笔录,key值直接在原先的key基础上加1更新到马克斯Id表中并回到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
    SEEnclaveVE宝马X5会保险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)         要是缓存失效或暴掉了,那缓存的马克斯Id未有更新到数据库导致数据错过,必得停掉站点来推行Select
max(id)各类表来同步马克斯Id表。

b)         布满式缓存不是风流倜傥保存下来,别的服务器上就马上能够取获得的,即数据存在不分明性。(其实也是缓存的三个误用,缓存应该用来存的是数11回探望并且相当少纠正的剧情)

         改正方案:

大器晚成体化思想:组建两台以上的数据库ID生成服务器,种种服务器都有一张记录各表当前ID的MaxId表,可是马克斯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
二〇一三、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常常表示成叁拾四个16进制数字(0-9,A-F)组成的字符串,如:{21EC2020-3AEA-1069-A2DD-08002B30309D},它实质上是三个1贰17个人长的二进制整数。

GUID制定的算法中应用到客商的网卡MAC地址,以管教在微型计算机集群中生成唯豆蔻梢头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远远不足本身;占领了31个人;索引作用十分低。

改进:

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

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

在钦赐计算机上创建大于先前经过该函数生成的其余 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-二十多少个字符,如:

7QDBkvCA1+B9K/U0vrQx1A

7QDBkvCA1+B9K/U0vrQx1A==

Ascii85编码后是十八个字符,如:

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)         11个人年月日时分秒+5位随机码+3位服务器编码  (那样就全盘单机完结生成全局独一编码)—共贰十一个人

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

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

破绽:因为运用到流水码,流水码的转移必然会遇上和马克斯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

也正是说,其实重复的机缘是某些,只是可能率难点。

楼主测验数是29997350000,发生再一次的可能率是:

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. 选取安德拉NGCryptoServiceProvider做为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);

        }

测量试验结果:

 

敲定:随机码使用奇骏NGCryptoServiceProvider或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:“事务、并发、并发难点、事务隔绝等级、锁”小议,注重介绍:“事务隔开品级”怎么着影响 “锁”?

相关文章