微博 请问你是怎么优化数据库的？
51CTO综合报道】围脖，织围脖——这是什么？冬天到了，织条围脖保暖吗？错，这是网络流行用语。这还是大家的生活方式，生活态度。“找我？来我微博啊！”最近身边的朋友都在织啊织，你不织？你就是“奥特曼”。那么大家是否知道微博的开发模式吗？数据库是如何部署的？又是如何优化的？这些问题一出，必要找达人为我们解惑。51CTO有幸请到新浪首席DBA杨海潮先生来为我们解一解上述的疑惑。
专访人物介绍
杨海潮，新浪首席DBA，在大规模高并发，海量访问有丰富的管理经验。热衷于数据库设计，性能优化，分布式部署方案和高可用性方面的研究。
之前从事大访问量网站的部署以及优化工作，加入新浪后主要负责整个公司的数据库管理工作。
51CTO：新浪现在的开发模式还是LAMP吗？
杨海潮：目前大部分业务还是使用LAMP方式，也有部分采用LNMP方式。
51CTO：新浪数据库是如何部署的？
杨海潮：目前NoSQL和MySQL是结合使用的，根据应用的特点选择合适存储方式。
51CTO：Sharding策略是很好的数据库扩展方案，但是这种方案也不是万能的，新浪是如何选取sharding的形式，来适应不同的应用场景？
杨海潮：如图：
sharding只用于数据量大同时有性能瓶颈的库，大部分库不进行sharding处理。
对于数据量比较大的库，在一开始就考虑sharding策略，例如索引数据和内容数据分开设计，每类数据库根据业务逻辑选择恰当的partitioning key，拆分成一定数量的表。
然后随着压力的增加进行垂直拆分，垂直拆分后的库再遇到性能瓶颈时首先考虑用硬件来解决。
当硬件解决不了时才开始考虑水平拆分。
在选择sharding方案时仔细考虑业务逻辑。对于读密集型应用，基本上通过增加slave来解决，对于写密集型应用才进行垂直和水平拆分工作。
51CTO：跨越越多的sharding，带来的开销就越大，这个数量是如何控制的？
杨海潮：目前我在设计之前就避免跨表操作，选择适当的paritioning key，也即合适的拆分维度，避免对后期业务的影响。
根据业务逻辑的重要程度，如果业务逻辑是查询某一个用户的信息，那么会按用户进行拆分，那么保证一个用户的数据是落在一张表里面。按时间维度进行拆分，那么会分析数据的冷热程度，把80%以上的数据放在一个表，避免过多的跨表查询。
在这种拆分维度满足不了业务需求时，我们会利用空间换时间的思想，同一份数据按多种维度进行拆分，让每种业务逻辑的查询语句都有很高的效率。
51CTO：很多用户都会把sharding和partitioning混淆，您能讲讲您是怎么区分sharding与partitioning的异同。
杨海潮：sharding通常是指垂直拆分和水平拆分，是一个总体的概念，mysql的partitioning是实现sharding的一种技术。
51CTO：新浪现在采用SQL+NoSQL结合的数据库部署，那么对于两种数据库，分别是如何进行优化的呢？
杨海潮：目前NoSQL和MySQL是结合使用的，根据应用的特点选择合适存储方式。譬如：关系型数据，例如：索引使用MySQL存储，非关系数据库，例如：一些K/V需求的，对并发要求比较高的放入NoSQL产品存储，或者通过关系数据复制到NoSQL(redis)来显示不同的应用需求。
针对MySQL做的优化比较多，从硬件使用SSD,Fusion-IO,Cachecade等），文件系统(尝试XFS)，调整IO调度，优化参数，调整索引到减少应用对数据库的访问和交换等。
NoSQL(redis)通过修改源码满足自己的业务需求：完善它的replication机制，加入position的概念，让维护更容易，同时failover能力也大大增强。改善Hashset在rdb里面的存储方式，提升复杂数据类型的加载速度。
51CTO：如何保证数据库的安全性的呢？
杨海潮：主要通过几个方面进行考虑：