最近可能要做一个项目，规模不小，但我负责的部分不大，就是开发一些管理工具，用于对Partition和FileGroup的管理。
用户的这个数据库就是用于管理文件的，但是数量相当的大，预估每天在60G左右， 在使用FileStream的时候就要考虑一下了。本身FileStream就是Varbinary的数据类型，我们可以使用T-SQL语句进行操作，也可以使用Win32 API(那天听说了一个新名词RBS-Remote Blob Storage)，这样一来我们如何确定适用那种方式进行操作就成了问题。
如何选择主要要看数据的大小了，一般来说如果数据小于2M的使用使用T-SQL的方式会比较快一些，如果数据大小大于2M Win32 API会快一些，另外还要注意的就是Win32 API不支持部分更新，也就是说无法进更新varbinary中部分的数据，所以选择以何种方式使用Filestream的时候也要注意。
另外在还要注意的是我们在更新数据byte的的时候都会有一个缓存的数组，这个数组的大小对于性能也有很大的影响，这个大小最好能够与磁盘扇区的大小对齐，在之前我的代码中512和4096时的性能差异就很大了。
5.12地震，我正在成都出差，正当讲课的时候，地震了。稳住情绪后和学员一起逃生。经历的这场恐怖的地震后，发现地震并不可怕，真正可怕的来自于自己内心的恐惧和孤独，另外还要不出一些专业知识。我总结了一些经验给大家共享一下：
- 不要恋财，逃命要紧，只要拿上必需的钱和手机即可，其他的以后再说
- 手机上设置好紧急拨号的功能，1键拨出去。
- 有机会要买些水和士力架，我就忘了士力架了，本来包里有的，出来时候让我拿出去了，但是水一定要有，没水人坚
- 不了多久，士力架主要是糖和巧克力对于补充体力来说很有效，毕竟你不能背着葡萄糖的瓶子到处跑
- 找空旷的地方，酒店不要太高，也不要太低。高层的基本逃不出来，低的一般设计上不结实
- 注意使用电梯的时机，并且每到一个地方先看好紧急出口在那里，有条件的先走一遍，这样逃得时候才能最快的找到出路。
- 不要到人员聚集的地方，人多地地方不一定安全，人多的地方经常遇到情况的时候会很混乱，可能没被震死，会被踩死
- 远离加油站、电线杆、隧道、山坡、水渠、化工厂，那里可能会有其他的危险
- 保持通讯，有机会就找地方给手机充电，虽然手机不一定都好用，但是也许能用于求救
- 通过各种渠道及量多地从外面获取消息，本地的消息你很难及时得到，这里机场和航空公司的电话根本打不进去
- 有机会就去提款机拿点现金，很多地方不能刷卡的，现金更管用
- 保持冷静，如果恐惧就给别人打电话，这样冷静下来能让你更灵敏，头脑清醒非常重要
- 保持体力，不要瞎跑，能休息时尽量找安全地方休息，也许下一秒需要你来一个冲刺才能逃出去，另外安全的时候找机会睡一下，因为更多地时候都是出于神经紧张的状态
- 抽烟的人，多准备点烟，这个东西可以让你放松一下，可以自己安抚一下恐惧的心情，不抽烟的就准备口香糖。或者找点其他的事干，当然干工作都没心情了，但是要想办法击退自己内心的心魔
- 最后一点最重要了，保持冷静，自己不要乱了方寸，能战胜自己就是胜利，心魔是你自己，战胜它不难，但要有意志力。遇事切勿慌张，要有自己的想法，切勿不自己思考跟着别人走，那样你的命运就不再你手上了
还有主要的恐惧不是来源于那次主震，而是接连不断的余震，震动的不是大楼，而是震得是你的心，不断地折磨你，摧毁你的意志，说不怕都瞎扯。所以要不断地给自己信号，冷静没什么事了。
目前本人还没有出来呢，但情况还好，可以接受了。就是睡觉不踏实，经常感觉有震动，由于神经高度紧张，有点像地动仪了。原来准备继续写的文章也都推迟了，等我从成都回去再说了。
God save me.
Scalability对于软件设计师来说永远都是一种挑战，虽然我们设计的系统并不一定都要有Scalibility的能力但是客户往往都有这方面的期待，因为每个客户都希望自己的业务能够做大，都希望自己的数据库可以与Myspace一样大。最近要和lvke兄弟合作写一些对于数据库的东西，这里也和大家分享一下自己的体会。
Session 1
What is Scalability?
扩展性就是说我们需要让应用程序可以使用更多的资源去做更多的工作。简单的说就是随着业务增加，应用程序将承担更多的负载，这个时候我们需要对于应用程序使用的资源进行调整，用来处理这些负载，这是我们的应用程序能否有能力的利用这些增加的资源，这就是Scalability。
对于应用程序来说，我们可通过减低组件的耦合程度将组件分层并部署到不同的服务器上，同时考虑每层组件对于NLB的支持，这样就可形成一个云，每层服务组件都可能由若干服务器来运行，当负载增加时可以通过增加服务器的方式来进行横向的扩展，多数的互联网企业都是这种思路。
对于Scalability来说，通常用2种方式实现-Scale Up和Scale Out。对于不同的环境和要求来说，正确的使用相应的策略才是最关键的。Scale up就是提供更强大的服务器来提供更好的性能，如果你的软件系统可以支持更多的CUP和内存，Scale up也是一个不错的方式。但是目前的服务器的处理能力受到很多技术上的限制，并不是说我们可以无限制的添加资源，同时我们的软件系统也并不一定可以支持这么多的CPU和内存，不论你是Windows或Unix。同时更大的服务器也意味着更高的成本。这时人们更多的是想到Scale out的方案。Scale out方案就是利用N个廉价的服务器去处理更多的业务，业务增加时可通过增加服务器来实现业务的处理，这样从理论上我们可以不去限制服务器的数量，互联网应用就是典型的Scale out，当然互联网行业有他特定的行业特点。
应用程序中很多情况下离不开数据库的支撑，除非你是Google，有能力自己去编写适应与自己业务的数据库。通常情况下我们都会采用一些商业或开源的数据库产品来实现我们对于数据持久和查询的功能。我遇到了很多客户在进行产品选型的时候都会说我们要求你们的数据库可以实现负载均衡等类似的要求，大家也都知道数据库上的均衡方式不同于我们Web服务器的均衡，我们要考虑到数据的同步、事务等更多的方面。长期以来很多用户都在诟病SQL Server无法做到Load Balance，而Oracle的RAC却可以实现。我稍微看了一下Oracle的RAC，从原理上他也无法实现类似于服务器云的那种形态，因为RAC其实是一个Cluster，需要共享网络总线和磁盘系统，网络总线用于同步Cache，共享SAN用于存储数据。SQL Server虽然也能实现Cluster，但是A/A群集上的2个实例还是无法做到对于性能有什么提升。当然RAC也不是没有缺陷，当节点数大于2个的时候性能并不是按照我们想象的一样按照线形增长，而且当节点数持续增加的时候网络可能就会成为最大的瓶颈，而且在国内目前看到的RAC也只是以2个节点的为多，更多节点的RAC目前在国内也没有太多成功的案例。回来继续谈谈SQL Server，虽然By default，没有RAC的功能，但是并不是代表不能做到，MySpace有数百台SQL Server支撑网站，形成一个数据库服务器云，可以通过增加数据库服务器来支撑用户数量的增加，还有像纳斯达克这样的应用场景也都是存在类似的方案。所以说能和不能并不是重要的，系统地架构设计+产品的功能也能帮我们实现数据库服务器的Scale out。
目前我们在SQL Server上的Scale out Solutiion主要有以下几种
- Scalable Shared Database
- Peer-to-Peer Replication
- Linked Servers and Distributed Queries
- Distributed Partitioned Views(DPV)
- Data-Dependet Routing
- SOA
后续的文章我会慢慢的聊聊这些Solution，时间所限可能会很慢很慢很慢。。。。