Database Optimize patterns Most of websites and enterprise application rely on the database backing them to store the application and customer data. So at some point the database could be the main performance and scalability bottleneck for your system performance, so I ‘m here today to cure this!Database supporters and resisters:Database supporters: MySQL, SQL Server, and PostgreSQL:MySQL, SQL Server, PostgreSQL, and others is hard competitors, everyone have different philosophy, and features.For example, SQL Server have rich features such as: support UTF16 in the data types, triggers, roles and policies, and integration with .NET, etc. MySQL: Free and open source, many database engines. PostgreSQL: Free and open source, support object-oriented data model.What about the performance?The Database performance is important. In the real and trusted performance benchmark: MySQL faster than SQL Server, and PostgreSQL have good performance better than SQL Server, and almost like MySQL. Also PostgreSQL, MySQL have small footprint, and consume small system resource.Database resisters: HBase, MongoDB, Redis, and others:Does all application really need databases backing them?I believe there is no option can fit in all situations, so not all applications need database. The golden wisdom (in my opinion) said: Every challenge has its own solution.There are many scenario will agreed with Database resisters, such as: Web search engine, Caching, File sharing, etc. In the other hand there are a lot of scenarios agreed with Database supporters, such as: ERP, CRM, E-Commerce, etc.Tiny URL services for example, shouldn’t use Database at all because it’s require very simple needs map a small/tiny URL to the real/big URL. But what we can use beside or instead of Databases?There are a lot of tools that fallowing CAP, BASE model, instead of ACID model. CAP model is about:* Consistency – your data is correct all the time. What you write is what you read.* Availability – you can read and write and write your data all the time.* Partition Tolerance – if one or more nodes fails the system still works and becomes consistent when the system comes on-line.For example in any in-memory or in-disk caching system you will never need all the Database features. You just need CAP like system. Today there are a lot of Documents, and key-value based store systems, such as:* MongoDB Document oriented* CouchDB Document oriented (JSON)* Redis Key-value oriented* Tokyo Cabinet Key-value oriented* Memcached in-memory, Key-value orientedThe above list can work in many scenarios, and they provide good performance more than the Databases, and most of them support distributed, partitions, and they also provide good fault tolerance algorithm.I know after all this there are still people say; Why CAP model or key-value store system, the database is good?The Database is often a performance- and scalability limiting factor in most types of applications, the reality is that relational databases have not changed much in the last 30 years, and for a lot of purposes using a database is akin to running an interstellar spaceship while having an old Volkswagen engine in the engine room!So the first lesson today is: Consider use Key-value store system depend on your needs.Database Optimizing pattern:What to store into the Database?lot of people in our industry think about the Database as fundamental, default, primitive disk based store system, but this is wrong there are too many ways to store the data; beside that you shouldn’t store anything into the Database. In other word, don’t store non-relational data in relational data model.For example if you design a photo sharing website, you shouldn’t store the thumbnails photos into the Database because simply when some user search the brewer will send a lot of requests to view this photos, and making a lot of DB connections is not good, beside this the DBMS will make this process heavy because the DBMS is complex system by nature.So you should think twice before use the Database to store BLOB data.Field data types:In any DBMS you can found many kind of data types, such as: Date, Time, DateTime, Text, BLOB, VarChar, NVarCar (in SQL Server), and so on. If you choice the right data type this will make the database use lower disks space, and the insert/retrieve will run faster. But why I choice think about it? The Database by nature resides in disks and such disks are slow, so if you minimize the size of the stored data this will improve the write and read time. For example don’t use NVarChar data type except if you really need 16 bits Unicode (UTF 16). Also be watchful when you choice Text, NText, BLOB data type because mostly it will store in another location and the row will just hold the a reference to data position, so when you retrieve the data the DBMS will do a lot of seeks.The primary key and the indexes:We usually use it to optimize the retrieve, insert, update, and delete operations in the tables. Create a primary key on each table you create and unless you are really knowledgeable enough to figure out a better plan, make it the clustered index.It’s important to minimize the primary field size and make the inserting always at the end of the table (i.e. make the value of the primary key field always increasing); I suggest use integer and auto increment in the primary key field if it’s possible.To start with create your indexes; you need to plan an indexing strategy at the same time as you plan and design the database. First, and most important, is the clustered index (Primary key). As a rule, every table in an online transactional processing (OLTP) system should get a clustered index. You can only put one clustered index on a given table, so the proper selection of exactly what column or columns to place it on is extremely important.It makes sense to leave the cluster on the primary key if that primary key provides the natural access path, the most common field used to either search the table or relate the table to another.Changing the parameters slightly, if the access path is mostly through another column, says Company Name, this may make a more appropriate clustered index. Another situation is when the table is no longer at the top of the chain, but somewhere in the middle and the most likely avenue of selection for the data is going to come through the foreign key to a parent table. Then the foreign key column becomes a good candidate for the clustered index. A further wrinkle could be added by needing to get the related data in this child table, but based on a date. This would result in a clustered index composed of two columns: the foreign key and the date. As you can see, in a few sentences a number of options were laid out. You need to think this through as you design the system.You may also identify, either during design, testing or monitoring the production system, that other indexes are needed. While multiple indexes on any given table may be needed, you need to keep in mind that each index adds overhead to the system because these values have to be maintained as the data gets modified, which includes inserts, updates and deletes. Further, since indexes are stored by pointing to the clustered index (one of the many reasons you need a clustered index on the table) changes to the clustered index can result in a cascade through all the other indexes on a table. Because of all this, while indexes are good and necessary, restraint must be exercised in their application & use.Data retrieve, SP’s, and Ad-hoc queries:When you submit Ad-hoc query to the DBMS, a number of processes on the server go to work on that query. The purpose of all these processes is to manage the system such that it will provide your data back to you, or store it, in as timely a manner as possible, whilst maintaining the integrity of the data. The processes actually take a time, some time it’s take long time depend on your query complexity.So I suggest using SP (stored procedure) because most of those steps happen statically at compile time (i.e. creation time). For example you can in .NET – LINQ to SQL to import SPs and call it, and using a few changes you can also enforce the LINQ to SQL to use SPs in any insert, update, and delete operation for better performance.Minimize the Ad-hoc queries will make you gain some performance but we can’t enforce the developers to forget this important feature. Beside create SP’s for the complex queries and the usually insert, update, delete operations; I suggest monitoring and tuning the Ad-hoc queries execute plans at stabilization and testing stage.In general try to do the following:- It’s important to return/select the columns and rows you need only.- Avid using Like operation because it’s mostly require full table scan.- Avoid NOT IN, instead use a left outer join – even though it’s often easier to visualize the NOT IN.- Consider use set nocount on at the top of each SP (and set nocount off) at the bottom.- Avid Long-Running, and the distributed transactions.Caching:Caching is fundamental thing in reading intensive application, also caching is important in writing intensive application. If your DBMS support caching system, such as Query Caching in MySQL I suggest to turn it on.Caching the not rapidly changing data such as: Logged-in user’s roles, top most posts, configuration, and Categories into the client/application server memory also is important to minimize the traveling to the server.

Google网站架构分析 Google是可伸缩性之王。每个人都知道Google是因为他们对大量，复杂信息的快速搜索，但是Google的技术并不只是在搜索领域闪闪发光。他们构建大型应用的平台方式能够让他们以惊人的竞争速度在网络规模应用上面大展拳脚。Google的目标一直是构建更高性能更高规模基础设施来支持他们的产品。他们怎么做到的呢？参考资料以及信息来源视频：在Google上构建大型系统 (Video: Building Large Systems at Google)Google实验室：Google文件系统 (Google Lab: The Google File System)Google实验室：MapReduce：在大规模集群上简化数据处理 (Google Lab: MapReduce: Simplified Data Processing on Large Clusters)Google实验室：BigTable: (Google Lab: BigTable.)视频：BigTable: 一个分布式的结构化存储系统 (Video: BigTable: A Distributed Structured Storage System.)Google实验室：松散耦合的分布式系统的 Chubby Lock服务 (Google Lab: The Chubby Lock Service for Loosely-Coupled Distributed Systems.)Google是如何工作的 作者 David Carr发表于Baseline杂志 (How Google Works by David Carr in Baseline Magazine.)Google实验室：翻译数据：使用Sawzall并行分析(Google Lab: Interpreting the Data: Parallel Analysis with Sawzall.)可伸缩性大会上Dare Obasonjo的笔记 (Dare Obasonjo’s Notes on the scalability conference.)平台• Linux• 多种不同的语言： Python, Java, C++数据揭秘目前的情形：• 2006年估计有450,000个价格便宜的商用服务器• 2005年Google索引了80亿的web页面。到现在为止有多少，已经无法统计出来了。• 目前Google有超过200GFS的集群。一个集群能有1000甚至5000个机器。成百上千的机器从运行大到5peta字节存储的GFS集群检索数据。通过集群的总的读写吞吐量达到每秒400亿字节。• 目前在Google有6000个 MapReduce应用，并且每个月有几百个新的应用正在出现。架构的层次Google把他们的基础设施架构描述为三个层次栈：• 产品：检索，广告，电子邮件，地图，视频，聊天，博客• 分布式系统基础设施：GFS, MapReduce, 以及BigTable。• 计算平台：很多不同数据中心的很多机器• 确保公司员工容易低成本配置。• 看看每个应用基线的价格性能数据。把更多的钱花在硬件上以期不丢失日志数据，但是在其他类型的数据上花少一点。既然这样处理，实际上他们就不会丢数据。使用GFS（Google文件系统）的可靠存储机制• 可靠的可伸缩存储是任何应用的一个核心需要。GFS就是他们的核心存储平台。• Google文件系统- 大的分布式日志结构化文件系统，里面有大量数据• 为什么不用其他的而非要构建一个文件系统呢？因为他们需要控制所有的事情，而正是这个平台把他们和其他任何一个区分开来。他们需要：- 通过数据中心的高可靠性- 对于几千个网络节点的可伸缩性- 大的读写带宽需求- 支持十亿字节大的数据块- 高效的通过节点减少瓶颈的分布式操作• 系统有主服务器和分块服务器（chunk servers）- 主服务器在各种数据文件上保存元数据。数据以64MB大的块存储在文件系统中。客户机和主服务器对话来操作文件里的元数据，定位包含了磁盘上他们需要的数据的分块服务器。• 一个新的应用可以使用一个已经存在的GFS集群或者他们自己制作。去理解他们使用的通过数据中心的这个供应过程将是非常有趣的。• 主键是足够的基础设施来确保人们对他们的应用有多种选择。可以调整GFS以适应个人应用需要。使用MapReduce对数据做一些事情• 既然你有了一个好的存储系统，你怎样使用如此多的数据呢？假如说你有很多TB的数据存储在1000台机器上。数据库不能扩展或者有效地扩展到这样的规模。这时就要用到MapReduce了。• MapReduce是一个编程模型和用来处理和产生大规模数据集。用户指定一个映射函数处理一个键/值对来产生中间的键/值对集合，还指定一个缩小函数来合并所有的与同一中间键相关的中间值。许多现实世界的任务在这个模型里被表示出来。用这个函数风格写的程序自动并行化并且在一大集群商务机器上执行。运行时系统关心分割输入数据的细节，通过一系列的机器安排程序的执行，处理机器事故，以及管理所需的机器内部通信。这使得没有任何并行和分布式系统经验的程序员能够容易地利用一个大的分布式系统的资源。• 为什么使用MapReduce呢？- 在大量机器上分割任务的极佳方式- 处理机器故障- 在不同类型的应用上工作，如搜索和广告。几乎每个应用都有映射简化类型之类的操作。你可以预计算有用的数据，统计字数，分类几TB的数据，等等。- 计算可以自动地更加靠近IO源。• MapReduce 系统有三个不同类型的服务器。- 主服务器分配用户任务以映射和减少服务器。它也跟踪任务的状态。- 映射服务器接收用户输入，在它们上面实行映射操作。结果写入中间文件。- 化简服务器接收由映射服务器产生的中间文件并在它们上面实行化简操作。• 例如，你想要统计所有网页中字符的个数。你可以把存储在GFS中的页面放入MapReduce。这些都将在1000秒内发生，包括机器同步和协调，任务安排，事故处理和数据传输将会自动完成。- 步骤如下：GFS -> Map -> Shuffle -> Reduction -> 把结果存回GFS- 在MapReduce 里，一个映射把一个视图映射到另一个，产生一个键值对，在我们的例子里是单词和数量。- Shuffling 聚合键的类型- 化简把所有的键值对加起来产生最后的结果。• Google索引管道有大概20个不同的映射化简。一个管道把数据看做记录的一个整体束和聚合键。第二个映射-化简进来把那个结果拿走做其他的一些事情。等等。• 程序可以很小。可以小到20到50行的代码。• 一个问题是stragglers。Stragglers是一种比其他都要慢的计算。Stragglers会发生是因为慢的IO（比如一个糟糕的控制器）或者从一个临时的CPU尖峰信号。解决办法是运行多个同样的计算，当一个完成时就销毁所有其他的计算。• 在映射和化简之间转换的数据被压缩。这样做是因为服务器不受CPU约束，花时间在数据的压缩和解压缩上还是有意义的，可以节省花在带宽和I/O上的时间。在BigTable中存储结构化数据• BigTable 是一个大型的容错和自我管理系统，包括太（万亿）字节的内存和皮字节的内存。它每秒能够处理几百万的读写。• BigTable是一个构建在GFS之上的分布式散列机制。它不是一个关系数据库。它不支持联结或者SQL类型查询。• 它提供查找机制，可以通过键来访问结构化的数据。GFS存储不透明数据和许多应用所需的结构化数据。• 商业化数据不能伸缩到这个层次，它们不在1000个机器上工作。• 通过控制它们自己的低层次存储系统，Google得到更多的控制和有力的工具来改进它们的系统。例如，如果它们想要使得分布数据操作更简单的特征，它们可以在里面构建。• 当系统运行的时候，机器可以增加和减少，而整个系统还会正常工作。• 每个数据条存储在一个可以使用行键，列键或者时间邮票访问的单元中。• 每行存储在一个或者更多个tablet中。一个tablet是数据形式的64KB块的序列叫做SSTable。• BigTable 有三个不同类型的服务器：- 主服务器分配tablet到tablet服务器中。它们跟踪的位置，当需要时还会重新分配任务。- Tablet 服务器处理tablet的读写请求。当tablet超过规模限制（通常是100MB – 200MB）时，它们将它分开。当一个tablet服务器出故障时，会有100个tablet服务器每个捡起一个新的tablet，所以系统就恢复了。• 一个位置组可以被用作与几比特的数据相关的物理存储，为了有一个更好的参考位置。• Tablets尽可能在RAM里被缓存。硬件• 当你有很多个机器时，你如何构建它们以使花费代价最小电能消耗最少呢？• 使用超便宜的商业硬件，拼命利用它们在上面构建软件。• 增加 1,000-fold 计算机电力，如果你使用容易出事故的基础设施而不是构建在高度可靠的部件之上的基础设施时，可以有33倍更低的花费。你必须使用这一策略在不可靠之上构建可靠。• Linux，内部的架构设计，PC类主机板，低端存储。• 性能基线中每瓦的价格没有越来越好。存在着很多的电力和其他问题。• 使用混合收集和它们自己的数据中心。杂类• 很快找出改变而不是等着提问和回答。• 库是构建程序的主要方式。• 一些是以服务的形式提供的应用，比如crawling。• 基础设施处理应用程序的版本，所以它们就能够发布，不用担心破坏事情。Google未来的方向• 支持地理位置分布的集群• 为所有的数据创建单一的全局名字空间。当前数据由集群分离开的。• 更多更好的数据和计算的自动化迁移。• 解决当你用网络分割耦合大范围的复制时产生的一致性问题（例如，即使一个集群已经因为维修或是其他一些临时停电等原因而下线时，还能继续提供服务）Goolge告诉我们的经验• 基础设施是一个很有竞争性的优势。它当然是属于Google的。它们能更快更便宜地提供和生产新的网络服务，这在一定程度上是无人能比的。许多公司采取了完全不同的方式。许多公司把基础设施看做一种花销。每个组将使用完全不同的技术，而且他们很少有计划如何更经济地构建系统。Google把他们自己看做一个系统工程公司，以一个非常新的方式来看待构建软件。• 跨越多个数据中心仍是一个未解决的问题。大多数网站是一个至多是两个数据中心。如何在大量数据中心上充分分配网站，我们说，非常复杂。• 看一看Hadoop (产品)如果你没有时间来从头开始构建所有这个基础设施的话。Hadoop 是一个这里讲的一些主意的开源实现。• 一个平台方式被忽略的优点是初级开发人员可以在平台上很快自信地构建健壮的应用。如果每个项目需要创建同样的分布式基础设施轮，你将会陷入困境，因为知道如何这样做的人员相对稀少。• 协同工作并不总是废话。通过使系统中所有部件一起工作，一个改进会有助于所有的改进。改善文件系统，每个人都会立刻明显受益。如果每个项目使用一个不同的文件系统，那么就没有整个展的持续的改进。• 构建不需要降低系统性能的自我管理系统。这可以让你更容易地平衡各服务器的资源，动态增加更多空间，允许机器下线，以及更从容地处理升级。• 创建一个进化式基础设施。花时间在并行处理上会有回报的。• 不要忽视了学院。学术界有很多好的创意并没有转入生产环境里。Google所做的大部分先于艺术，不只是先于大规模配置。• 考虑压缩。当你有大量CPU可以挥霍和IO限制时，压缩是一个很好的选择。

负载均衡必须要考虑的八个方案 1、HTML静态化其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。2、图片服务器分离大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。3、数据库集群和库表散列大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。4、缓存缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。5、镜像镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。6、负载均衡负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。7、硬件四层交换第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚 IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。8、软件四层交换大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。FROM：CU