搬迁惯用就是临时表或者新库,如今铺面用到

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

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

前日在数额迁移的时候因为手贱际遇一个坑爹问题,发来我们乐乐,也传授新手点经历

又一个多月没冒泡了,其实多年来学了些东西,不过并未布置时间整理成博文,后续再奉上。方今还写了一个发邮件的零件以及性能测试请看 《NET开发邮件发送功效的两全教程(含邮件组件源码)》 ,还弄了个MSSQL参数化语法生成器,会在6月整理出来,有趣味的园友可以关怀下我的博客。

搬迁惯用就是临时表或者新库,常常用的语法有不可胜言,这一次重大说的是以此: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、  单独开一个数据库,获取全局唯一的自增系列号或各表的马克斯(Max)Id

终极说提议的话,对于这种多表的最好仍旧用程序来决定和拍卖多少(你得保障标识唯一),倘诺不管标识就不管搞了~

1)         使用自增种类号表

 

专门一个数据库,生成序列号。开启事物,每一回操作插入时,先将数据插入到种类表并重回自增体系号用于做为唯一Id进行作业数据插入。

留意:须要定期清理系列表的数码以担保收获系列号的频率;插入体系表记录时要打开事物。

应用此方案的题材是:每一回的查询连串号是一个属性损耗;借使这么些队列号列暴了,那就杯具了,你不了然哪位表使用了哪位连串,所以就必须换另一种唯一Id方式如GUID。

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

专门一个数据库,记录各样表的马克斯Id值,建一个存储进度来取Id,逻辑大概为:开启事物,对于在表中不设有记录,直接再次回到一个默许值为1的键值,同时插入该条记录到table_key表中。而对此已存在的笔录,key值直接在本来的key基础上加1更新到马克斯(Max)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
    SERVER会有限协理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)缓存第一回访问马克斯(Max)Id表数据,以提升再一次访问速度,并定时用缓存数据更新五遍马克斯Id表,但我们担心的题目是:

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

b)         分布式缓存不是一封存下来,其余服务器上就立刻可以赢得到的,即数据存在不确定性。(其实也是缓存的一个误用,缓存应该用来存的是反复造访并且很少改动的始末)

         修正方案:

一体化思想:建立两台以上的数据库ID生成服务器,每个服务器都有一张记录各表当前ID的马克斯(Max)Id表,不过马克斯Id表中Id的滋长幅度是服务器的数据,早先值依次错开,那样相当于把ID的更动散列到种种服务器节点上。例如:假诺我们设置两台数据库ID生成服务器,那么就让一台的马克斯(Max)Id表的Id开始值为1(或当前最大Id+1),每回增加幅度为2,另一台的马克斯(Max)Id表的ID发轫值为2(或当前最大Id+2),每便步长也为2。这样就将发出ID的下压力均匀分散到两台服务器上,同时同盟应用程序控制,当一个服务器失效后,系统能活动切换来另一个服务器上赢得ID,从而化解的单点问题保险了系统的容错。(Flickr思想)

而是要专注:1、多服务器就必须面临负载均衡的题材;2、如若添加新节点,须求对原本数据重复根据步长统计迁移数据。

结论:适合大型应用,生成Id较短,友好性相比好。(强烈推荐)

3、  Sequence特性

其一特性在SQL Server
2012、Oracle中可用。这一个特点是数据库级其他,允许在四个表之间共享体系号。它能够化解分表在同一个数据库的情事,但要是分表放在分裂数据库,那将共享不到此连串号。(eg:Sequence使用境况:你须求在七个表之间公用一个流水号。以往的做法是相当建立一个表,然后存储流水号)

有关Sequence特性资料:

SQL
Server2012中的SequenceNumber尝试

SQL Server
2012 开发新功用——种类对象(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平时表示成32个16进制数字(0-9,A-F)组成的字符串,如:{21EC2020-3AEA-1069-A2DD-08002B30309D},它实质上是一个128位长的二进制整数。

GUID制定的算法中应用到用户的网卡MAC地址,以有限协理在微机集群中生成唯一GUID;在同一总结机上自由生成八个相同GUID的可能是充足小的,但并不为0。所以,用于生成GUID的算法平常都投入了非随机的参数(如时间),以确保那种重新的气象不会时有暴发。

优点:GUID是最简便易行的方案,跨平台,跨语言,跨业务逻辑,全局唯一的Id,数据间共同、迁移都能大致达成。

缺点:

1)         存储占了32位,且无可读性,重返GUID给客户出示很不规范;

2)         占用了可贵的聚集索引,一般大家不会基于GUID去查单据,并且插入时因为GUID是不必的,在聚集索引的排序规则下或者移动大批量的笔录。

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

@徐少侠           GUID无序在并发下功用高,并且一个数目页内添加新行,是在B树内增添,本质没有怎么数据被挪动,唯一可能的,是页填充因子满了,须求拆页。而GUID方案导致的拆页比顺序ID要低太多了(数据库不是很懂,暂时不可以判断,大家温馨认识)

@无色                大家要通晓id是怎么,是身份标识,标识身份是id最大的事体逻辑,不要引入什么时间,什么用户业务逻辑,那是此外一个字段干的事,使用base64(guid,uuid),是通盘考虑,完全可以更好的合营nosql,key-value存储。

(推荐),但是一旦你系统一开始没有安插一个作业Id,那么将造成大批量的改动,所以这么些方案的极品状态是一起首就统筹工作Id,当然事情Id的唯一性也是我们要考虑的。

敲定:适合大型应用;生成的Id不够自己;占据了32位;索引功用较低。

改进:

1)         (@dudu提点)在SQL Server
2005中新增了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不够自己;占据了32位。

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

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

COMB数据类型的骨干布署思路是这么的:既然GUID数据因并非规律可言造成索引功效低下,影响了系统的性能,那么能无法通过整合的章程,保留GUID的10个字节,用另6个字节表示GUID生成的大运(Date提姆e),那样我们将时刻音讯与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不够自己;占据了32位。(强烈推荐)

3)         长度问题,使用Base64或Ascii85编码解决。(要留心的是上述有序性方案在拓展编码后也会变得无序)

如:

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

当须求选取更少的字符表示GUID时,可能会选用Base64或Ascii85编码。Base64编码的GUID有22-24个字符,如:

7QDBkvCA1+B9K/U0vrQx1A

7QDBkvCA1+B9K/U0vrQx1A==

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

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转为了19位数字,数字反映给客户可以一定水准上化解友好性问题。EG:

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

Int64:
5717212979449746068                                      (友好性还行)

而是我的同伙说ToInt64后就不唯一了。因而我专门写了个冒出测试程序,后文将提交测试结果截图及代码容易表达。

(唯一性、业务适合性是可以衡量的,那些唯一性肯定比然而GUID的,一般程序上都会安插错误处理机制,比如万分后举办五次重插的方案……)

敲定:适合大型应用,生成相对友好的Id(纯数字)–—-因不难和作业友好性而引进。**

8、  自己写编码规则

可取:全局唯一Id,符合业务后续深刻的腾飞(可能实际事务须要团结的编码规则等等)。

缺陷:依照具体编码规则达成而分化;还要考虑假使主键在事情上同意改变的,会带动外键同步的麻烦。

自身那边写五个编码规则方案:(可能不唯一,只是个体方案,也请大家提议自己的编码规则)

1)         12位年月日时分秒+5位随机码+3位服务器编码  (那样就全盘单机落成生成全局唯一编码)—共20位

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

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

症结:因为运用到流水码,流水码的生成必然会碰到和MaxId、系列表、Sequence方案中接近的问题

(为啥一贯不阿秒?微秒也不拥有业务可读性,我改用5位随机码、流水码代替,估摸1秒内应有不会下99999[五位]条语法)

 

敲定:适合大型应用,从事情上来说,有一个平整的编码能突显产品的正经成度。(强烈推荐)

 

 

GUID生成Int64值后是或不是还具有唯一性测试

测试环境

 

重大测试思路:

  1. 基于内核数使用四线程并爆发成Guid后再转为Int64位值,放入集合A、B、…N,多少个线程就有稍许个聚众。
  2. 再使用Dictionary字典高效查key的特点,将步骤1中变化的五个会聚全部加到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. 应用Date提姆(Tim)e.Now.Ticks做为Random参数,存在重复。
  3. 运用unchecked((int)Date提姆e.Now.Ticks)做为Random参数,存在重复。
  4. 采纳Guid.NewGuid().GetHashCode()做为random参数,测试不存在双重(或存在性极小)。
  5. 选取RNGCryptoServiceProvider做为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);

        }

测试结果:

 

敲定:随机码使用RNGCrypto瑟维斯(Service)(Service)Provider或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:“事务、并发、并发问题、事务隔离级别、锁”小议,重点介绍:“事务隔离级别”怎样影响 “锁”?

相关文章