04月13号，在DTCC开场演讲上，盛拓传媒CEO秦致分享一个评估数据，根据科技研究公司ＩＤＣ的数据估测，数据一直都在以每年５０%的速度增长，而这也意味着big data(大数据)时代的到来.
大数据时代，在我个人看来，互联网发展到了一个快速增长的时期，网民已经不在是单纯的浏览互联网的信息或使用某些功能，而是更多的参与网络上的互动，社交，分享等更多的应用，由此也产生了大量的半结构化和非结构化的数据快速增长。而在我们身边也可以切身体验到这种变化，在给以往的项目程序来创建数据库，通常使用开源数据库mysql来存储数据，数据结构简单，单库数据量百兆级别，而短短的一段时间之后，我们更多用到是开源mysql和ttserver,sqs,memcache，nosql之间的交互使用，不仅mysql数据量大量增长，数据结构多元化，队列、memcache、nosql等数据存储也急剧增长，这些大量增长的数据同时也给我们带来了很多问题，我们的数据架构需要重新调整，服务器负载问题，故障率增长，运维工作增加等等。然而，在面对这么多问题情况下，许多企业已经开始尝试更多的数据存储，应用，开发适合自己的数据架构，我们也应该放手尝试更多的应用来找出适合自己的数据架构。
在这次大会中，我们选听了百度，腾讯，新浪的实践分享，让我感触很深，百度分享了数据中间层架构，用于将并发控制前移，保护数据库系统，提高高可用性，降低成本，他们采用了三层体系架构，就是将客户端和服务器之间增加了功能模块来数据访问，代理，并发控制，并采用了一主多丛，单机多实例，读写分离等传统功能，还有相应的优化工具，管理等不过这些功能都已经形成模块化，数据集群化。由此我也想到了我们部门的数据架构跟百度的中间层很类似，我忽然理解当时宴哥设计架构的初衷，我们的数据架构，主库、丛库采用虚拟IP，一主多丛，读写分离，丛库采用LVS进行并发控制，负载均衡，同样提高了高可用性，不过我们的数据架构并没有像百度那样形成模块化，并且还存在一些问题，我们在做主丛的时候，有些丛库并不是读的主库的虚拟IP,而是内网IP，这样就会出现一个问题，当主库崩溃临库切换后需要重新时行主丛配置，如果丛库一开始就读主的虚拟IP，这样问题就能很快解决。另外，我们的主丛切换还没有实现人工决策，完全自动切换，网络波动导致主丛延时，前端时间数据分拆实例后主丛切换机制等等，不过我们的架构存在着优势，便于优化，便于扩展，这些功能模块加载只是时间问题，我想这也是我们下一阶段的工作内容。
在大会的最后一天，我们还选听了NOSQL数据库专场，同样也学习了不少东西，在新浪微薄的分享中，介绍了采用NOSQL,redis的历程，redis是基于内存的键值存储，从先前的rdb到现在aof，还被废弃的虚拟内存vm，而存储机制的改变并没有让redis数据持久化变得完美，也没有解决网络抖动导致主丛需要重新拉全部数据的问题，在新浪微薄中，redis应用在了用户和系统通知，用户之间的好友关系，计数器等需要交互的底层服务，但是由于微薄庞大的用户和数据交互，百亿级别的数据量，既使新浪在采用了redis集群，ssd盘加大内存的情况下，相应的问题也没能得到缓解，那么redis适不适合做数据交互和大数据的存础，新浪大牛在分享中也提到大数据的概念，什么是大数据，一种是线下大数据，即在持久化的介质中存储的、用于数据挖掘的、结构化的数据；另一种是线上大数据，是放在内存中存储的、用于在线服务的、结构化或半结构化或混合结构的数据。如果一台机器能处理ＧＢ级别的数据，而面对是却是更高一个数量级的数据，这样的数据就被称为大数据。最后结论，如果数据规模在１００Ｇ以内,无论做存储还是缓存、交互，redis可以应付，在选择存储介质的时候要分清数据量的大小和数据的冷热，小而热的数据适合使用内存，大而冷的数据适合使用磁盘，大而热的数据是否适合使用SSD。分析现在，我们线上采用了memcache,tt,httpsqs队列多应用并存方式，占用资源有些混乱，以我们目前的情况，数据级别并没有微薄庞大，无论专题活动，还是新的项目需要，都不会达到redis的极限，redis完全适用，我们也会逐步尝试并选用来应对小数据量的数据交互和存储。
参加这次大会，学习东西很多，也有很多感触，不仅感受到了数据库前沿的变化，也看到众多知名企业先进的技术和分享，网友们曾将架构师比作Dream Maker，数据库人才则是美好梦想的Dream Supporter，很高兴我们参加了这个梦一般的大会，最后感谢公司领导给予我们这次机会和支持，非常感谢。