nosql电子商务

㈠ 如何实现NewSQL，NoSQL与OldSQL的混合部署

在大数据时代，“多种架构支持多类应用”成为数据库行业应对大数据的基本思路，数据库行业出现互为补充的三大阵营，适用于事务处理应用的OldSQL、适用于数据分析应用的NewSQL和适用于互联网应用的NoSQL。但在一些复杂的应用场景中，单一数据库架构都不能完全满足应用场景对海量结构化和非结构化数据的存储管理、复杂分析、关联查询、实时性处理和控制建设成本等多方面的需要，因此不同架构数据库混合部署应用成为满足复杂应用的必然选择。不同架构数据库混合使用的模式可以概括为：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三种主要模式。下面通过三个案例对不同架构数据库的混合应用部署进行介绍。
OldSQL+NewSQL 在数据中心类应用中混合部署
采用OldSQL+NewSQL模式构建数据中心，在充分发挥OldSQL数据库的事务处理能力的同时，借助NewSQL在实时性、复杂分析、即席查询等方面的独特优势，以及面对海量数据时较强的扩展能力，满足数据中心对当前“热”数据事务型处理和海量历史“冷”数据分析两方面的需求。OldSQL+NewSQL模式在数据中心类应用中的互补作用体现在，OldSQL弥补了NewSQL不适合事务处理的不足，NewSQL弥补了OldSQL在海量数据存储能力和处理性能方面的缺陷。
商业银行数据中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL数据库满足各业务系统数据的归档备份和事务型应用，NewSQL MPP数据库集群对即席查询、多维分析等应用提供高性能支持，并且通过MPP集群架构实现应对海量数据存储的扩展能力。

商业银行数据中心存储架构
与传统的OldSQL模式相比，商业银行数据中心采用OldSQL+NewSQL混合搭建模式，数据加载性能提升3倍以上，即席查询和统计分析性能提升6倍以上。NewSQL MPP的高可扩展性能够应对新的业务需求，可随着数据量的增长采用集群方式构建存储容量更大的数据中心。
OldSQL+NoSQL 在互联网大数据应用中混合部署
在互联网大数据应用中采用OldSQL+NoSQL混合模式，能够很好的解决互联网大数据应用对海量结构化和非结构化数据进行存储和快速处理的需求。在诸如大型电子商务平台、大型SNS平台等互联网大数据应用场景中，OldSQL在应用中负责高价值密度结构化数据的存储和事务型处理，NoSQL在应用中负责存储和处理海量非结构化的数据和低价值密度结构化数据。OldSQL+NoSQL模式在互联网大数据应用中的互补作用体现在，OldSQL弥补了NoSQL在ACID特性和复杂关联运算方面的不足，NoSQL弥补了OldSQL在海量数据存储和非结构化数据处理方面的缺陷。
数据魔方是淘宝网的一款数据产品，主要提供行业数据分析、店铺数据分析。淘宝数据产品在存储层采用OldSQL+NoSQL混合模式，由基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom组成。由于OldSQL强大的语义和关系表达能力，在应用中仍然占据着重要地位，目前存储在MyFOX中的统计结果数据已经达到10TB，占据着数据魔方总数据量的95%以上。另一方面，NoSQL作为SQL的有益补充，解决了OldSQL数据库无法解决的全属性选择器等问题。

淘宝海量数据产品技术架构
基于OldSQL+NoSQL混合架构的特点，数据魔方目前已经能够提供压缩前80TB的数据存储空间，支持每天4000万的查询请求，平均响应时间在28毫秒，足以满足未来一段时间内的业务增长需求。
NewSQL+NoSQL 在行业大数据应用中混合部署
行业大数据与互联网大数据的区别在于行业大数据的价值密度更高，并且对结构化数据的实时处理、复杂的多表关联分析、即席查询、数据强一致性等都比互联网大数据有更高的要求。行业大数据应用场景主要是分析类应用，如：电信、金融、政务、能源等行业的决策辅助、预测预警、统计分析、经营分析等。
在行业大数据应用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在结构化数据分析处理方面的优势，以及NoSQL在非结构数据处理方面的优势，实现NewSQL与NoSQL的功能互补，解决行业大数据应用对高价值结构化数据的实时处理、复杂的多表关联分析、即席查询、数据强一致性等要求，以及对海量非结构化数据存储和精确查询的要求。在应用中，NewSQL承担高价值密度结构化数据的存储和分析处理工作，NoSQL承担存储和处理海量非结构化数据和不需要关联分析、Ad-hoc查询较少的低价值密度结构化数据的工作。
当前电信运营商在集中化BI系统建设过程中面临着数据规模大、数据处理类型多等问题，并且需要应对大量的固定应用，以及占统计总数80%以上的突发性临时统计(ad-hoc)需求。在集中化BI系统的建设中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在复杂分析、即席查询等方面处理性能的优势，及NoSQL在非结构化数据处理和海量数据存储方面的优势，实现高效低成本。

集中化BI系统数据存储架构
集中化BI系统按照数据类型和处理方式的不同，将结构化数据和非结构化数据分别存储在不同的系统中：非结构化数据在Hadoop平台上存储与处理;结构化、不需要关联分析、Ad-hoc查询较少的数据保存在NoSQL数据库或Hadoop平台;结构化、需要关联分析或经常ad-hoc查询的数据，保存在NewSQL MPP数据库中，短期高价值数据放在高性能平台，中长期放在低成本产品中。
结语
当前信息化应用的多样性、复杂性，以及三种数据库架构各自所具有的优势和局限性，造成任何一种架构的数据库都不能完全满足应用需求，因此不同架构数据库混合使用，从而弥补其他架构的不足成为必然选择。根据应用场景采用不同架构数据库进行组合搭配，充分发挥每种架构数据库的特点和优势，并且与其他架构数据库形成互补，完全涵盖应用需求，保证数据资源的最优化利用，将成为未来一段时期内信息化应用主要采用的解决方式。
目前在国内市场上，OldSQL主要为Oracle、IBM等国外数据库厂商所垄断，达梦、金仓等国产厂商仍处于追赶状态;南大通用凭借国产新型数据库GBase 8a异军突起，与EMC的Greenplum和HP的Vertica跻身NewSQL市场三强;NoSQL方面用户则大多采用Hadoop开源方案。

㈡ newsql和nosql的区别和联系

TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。

TiDB 具备如下特性：

• 高度兼容 MySQL

  大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。

• 水平弹性扩展

  通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。

• 分布式事务

  TiDB 100% 支持标准的 ACID 事务。

• 真正金融级高可用

  相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。

• 一站式 HTAP 解决方案

  TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。

• 云原生 SQL 数据库

  TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，配合TiDB Operator 项目可实现自动化运维，使部署、配置和维护变得十分简单。

TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过TiSpark 项目来完成。

TiDB 对业务没有任何侵入性，能优雅地替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大地提升研发的生产力。

㈢ 你身边的数据库系统有哪些请列举3到5个

1、MySQL

MySQL是一个快速的、多线程、多用户和健壮的SQL数据库服务器。MySQL服务器支持关键任务、重负载生产系统的使用，也可以将它嵌入到一个大配置(mass- deployed)的软件中去。

2、SQL Server

SQL Server 提供了众多的Web和电子商务功能，如对XML和Internet标准的丰富支持，通过Web对数据进行轻松安全的访问，具有强大的、灵活的、基于Web的和安全的应用程序管理等。

3、Oracle

Oracle产品系列齐全，几乎囊括所有应用领域，大型，完善，安全，可以支持多个实例同时运行，功能强。能在所有主流平台上运行。完全支持所有的工业标准。采用完全开放策略。可以使客户选择最适合的解决方案。对开发商全力支持。

(3)nosql电子商务扩展阅读：

数据库的发展现状：

在数据库的发展历史上，数据库先后经历了层次数据库、网状数据库和关系数据库等各个阶段的发展，数据库技术在各个方面的快速的发展。

特别是关系型数据库已经成为目前数据库产品中最重要的一员，80年代以来， 几乎所有的数据库厂商新出的数据库产品都支持关系型数据库，即使一些非关系数据库产品也几乎都有支持关系数据库的接口。这主要是传统的关系型数据库可以比较好的解决管理和存储关系型数据的问题。

随着云计算的发展和大数据时代的到来，关系型数据库越来越无法满足需要，这主要是由于越来越多的半关系型和非关系型数据需要用数据库进行存储管理，以此同时，分布式技术等新技术的出现也对数据库的技术提出了新的要求，于是越来越多的非关系型数据库就开始出现；

这类数据库与传统的关系型数据库在设计和数据结构有了很大的不同， 它们更强调数据库数据的高并发读写和存储大数据，这类数据库一般被称为NoSQL（Not only SQL）数据库。 而传统的关系型数据库在一些传统领域依然保持了强大的生命力。

㈣ 数据库有哪些类型

数据库有两种类型，分别是关系型数据库与非关系型数据库。

数据库，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、截取、更新、删除等操作。

关系型数据库主要有：

Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL等等。

非关系型数据库主要有：

NoSql、Cloudant、MongoDb、redis、HBase等等。

(4)nosql电子商务扩展阅读：

非关系型数据库的优势：

1、性能高：NOSQL是基于键值对的，可以想象成表中的主键和值的对应关系，而且不需要经过SQL层的解析，所以性能非常高。

2、可扩展性好：同样也是因为基于键值对，数据之间没有耦合性，所以非常容易水平扩展。

关系型数据库的优势：

1、可以复杂查询：可以用SQL语句方便的在一个表以及多个表之间做非常复杂的数据查询。

2、事务支持良好：使得对于安全性能很高的数据访问要求得以实现。

㈤ 为什么要用NoSQL数据库管理系统

一、首先看看传统关系型数据库的瓶颈：

1. 无法应对每秒上万次的读写请求，硬盘IO此时也将变为性能瓶颈

2. 表中存储记录数量有限，横向可扩展能力有限，纵向数据可承受能力也是有限的，面对海量数据，势必涉及到分库分表，难以维护。大数据查询SQL效率极低，数据量到达一定程度时，查询时间会呈指数级别增长

3. 难以横向扩展，无法简单地通过增加硬件、服务节点来提高系统性能。对于需要24小时不间断提供服务的网站来说，数据库升级、扩展将是一件十分麻烦的事，往往需要停机维护，数据迁移，为了避免服务间断，如果网站使用服务器集群，则根据集群策略，需要相应的考虑主从一致性、集群扩展性等一系列问题

二、然后看看NoSQL数据库的优点：

1. 海量数据下，读写性能优异

2. 数据模型灵活

3. 数据间无关系，易于扩展

三、NoSQL数据库分类：

1，键值存储数据库。代表数据库：Redis

适用场景：会话信息，用户配置信息，购物车

2，列存储数据库

代表数据库：BigTable，Cassandra，HBase

适用场景：事件记录，内容管理，博客平台

不适合需要ACID事务的场合

3，文档型数据库

代表数据库：MongoDB

适用场景：事件记录，内容管理，博客平台，网站分析，实时分析，电子商务应用

4，图数据库：可以使用图结构相关算法，比如最短路径寻址

代表数据库：Neo4j

适用场景：社交网络，推荐引擎，基于位置的服务

㈥ 数据分析和数据收集 需要什么方法

一般听到数据分析和数据可视化的比较多，数据收集听到相对较少。数据收集一般指数据存储在各业务系统中，或者手动录入数据库里。这里就要提到一个功能叫数据填报。数据填报功能是亿信华辰新推出的一款产品，一站式数据分析平台—ABI中数据采集的一个特色功能。数据填报功能可对报表进行数据回填设置，对缺失的数据进行补录，也可以制作全新的填报表单用于录入数据，真正的实现了数据分析填报一体化。回填报表支持导入excel数据，让大数据量填报不再是困扰，同时支持数据审核，确保数据正确性。
亿信华辰一站式数据分析平台—ABI，是一款全能型产品，融合了数据源适配、ETL数据处理、数据建模、数据分析、数据填报、工作流、门户、移动应用等核心功能。其中数据分析和数据可视化又是亿信ABI的长处也是其核心功能。亿信ABI拥有多种特色分析手段，除了中国式复杂报表、dashboard、大屏报表外，ABI还支持自助式分析，包括拖拽式多维分析、看板和看板集，业务用户通过简单拖拽即可随心所欲的进行探索式自助分析。同时，类word即席报告、幻灯片报告，让汇报展示更加出彩。亿信ABI的数据可视化也是丰富多彩，其报表中内置了上百种可视化元素和图形。不仅支持80多种统计图，还囊括了世界、中国各省市的地图及gis地图，通过设计与搭配，可衍生出成千上万种可视化效果。同时abi还支持动态炫酷的酷屏分析，独特的3D全景视角，自由快捷制作各类交互式常规屏和大屏报表，将创意变为现实。

㈦ 搭建一个日点击量百万以上的 电子商务网站，它的硬件设备投资大概会是多少

百万级访问量网站的技术准备工作
当今从纯网站技术上来说，因为开源模式的发展，现在建一个小网站已经很简单也很便宜，所以很多人都把创业方向定位在互联网应用。这些人里大多数不是很懂技术，或者不是那么精通，而网站开发维护方面的知识又很分散，学习成本太高，所以这篇文章将这些知识点结合起来，系统的来说，一个从日几千访问的小小网站，到日访问一两百万的小网站，中间可能会产生什么问题，以及怎么才能在一开始做足工作尽量避免这些问题。

你的网站因为努力经营，访问量逐渐升高，在升高的过程中，问题也可能开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的，而还有相当大的一部分成本是因为代码重构、架构重构，甚至底层开发语言更换引起的，最坏的情况就是数据丢失，所有努力付之一炬。这类成本支出大多数在一开始就可以避免，先打好基础，往后可以省很多精力，少操很多心。

对于不同的初期投资成本，技术路线的选择是不同的。这里假设网站刚刚只是一个构想，计划第一年服务器硬件带宽投入5万左右。对于这个资金额度，有很多种方案可选择，例如租用虚拟主机、租用单独服务器，或者流行的私有云，或者托管服务器。前两种选择，网站发展到一定规模时需迁移，那时再重做规划显然影响更大。服务器托管因为配置自主、能完全掌握控制权，所以有一定规模的网站基本都是这种模式。采用自己托管服务器的网站，一开始要注意以下几点——

一、开发语言
一般来说，技术人员（程序员）都是根据自己技术背景选择自己最熟悉的语言，不过不可能永远是一个人写程序，所以在语言的选择上还要是要费些心思。首先明确一点，无论用什么语言，最终代码质量是看管理，因此我们从前期开发成本分析。现在国内流行的适用于网站的语言，大概有java、php、.net、 python、ruby这五大阵营。python和ruby因为在国内流行的比较晚，现在人员还是相对难招一些。.net平台的人相对多，但是到后期需要解决性能问题时，对人员技能的要求比较高。剩余的java、php用人可以说是最多的。java和php无法从语言层面做比较，但对于初期，应用几乎都是靠前端支撑的网站来说，php入门简单、编写快速，优势相对大一点。至于后端例如行为分析、银行接口、异步消息处理等，等真正需要时，就要根据不同业务需求来选择不同语言了。

二、代码版本管理
稍微有点规模的网站就需要使用代码版本管理了。代码版本管理两点最大的好处，一是方便协同工作，二是有历史记录可查询比较。代码版本管理软件有很多，vss/cvs/svn/hg等，目前国内都比较流行，其中svn的普及度还是很高的。

假设选了svn，那么有几点考虑。一是采用什么树结构。初期可能只有一条主干，往后就需要建立分支，例如一条开发分支，一条上线分支，再往后，可能要每个小组一个分支。建议一开始人少时选择两条分支，开发和线上，每个功能本地测试无误后提交到开发分支，最后统一测试，可以上线时合并到上线分支。如果每人都建自己的分支，合并时会浪费很大精力，对于几乎每天都要修改几次的WEB应用来说，所费时间太多。

向服务器部署代码，可以手工部署也可以自动部署。手工部署相对简单，一般可直接在服务器上svn update，或者找个新目录svn checkout，再把web root给ln -s过去。应用越复杂，部署越复杂，没有什么统一标准，只是别再用ftp上传那种形式，一是上传时文件引用不一致错误率增加，二是很容易出现开发人员的版本跟线上版本不一致，导致本来想改个错字结果变成回滚。如果有多台服务器还是建议自动部署，更换代码的机器从当前服务池中临时撤出，更新完毕后再重新加入。

三、服务器硬件
在各个机房里，靠一台服务器孤独支撑的网站数不清，但如果资金稍微充足，建议至少三台的标准配置，分别用作web处理、数据库、备份。web服务器至少要8G内存，双sata raid1，如果经济稍微宽松，或静态文件或图片多，则15k sas raid10。数据库至少16G内存，15k sas raid 10。备份服务器最好跟数据库服务器同等配置。硬件可以上整套品牌，也可以兼容机，也可以半品牌半组装，取决于经济能力。当然，这是典型的搭配，有些类型应用的性能瓶颈首先出现在web上，那种情况就要单独分析了。

web服务器可以既跑程序又当内存缓存，数据库服务器则只跑主数据库（假如是MySQL的话），备份服务器所承担就相对多一些，web配置、缓存配置、数据库配置都要跟前两台一致，这样WEB和数据库任意一台出问题，很容易就可以将备份服务器切换过去临时顶替，直到解决完问题。要注意，硬件是随时可能坏掉的，特别是硬盘，所以宁可WEB服务器跟数据库服务器放在一起，也一定不能省掉备份，备份一定要异机，并且有异步，电力故障、误操作都可能导致一台机器上的所有数据丢失。很多的开源备份方案可选择，最简单的就是rsync，写crontab里，定时同步。备份和切换，建议多做测试，选最安全最适合业务的，并且尽可能异地备份。

四、机房
三种机房尽量不要选：联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。机房要尽可能多的实地参观，多测试，找个网络质量好，管理严格的机房。机房可以说是非常重要，直接关系到网站访问速度，网站访问速度直接关系到用户体验，访问速度很慢的网站，很难获得用户青睐。

五、架构
在大方向上，被熟知的架构是web负载均衡+数据库主从+缓存+分布式存储+队列。在一开始，按照可扩展的原则设计和编程就可以。只是要多考虑缓存失效时的雪崩效应、主从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存失效、数据库复制中断、队列写入错误、电源损坏，在实际运维中经常发生，如果不注意这些，出现问题时恢复期可能会超出预期很长时间。

六、服务器软件
操作系统Linux很流行。在没有专业运维人员的情况下，应倾向于择使用的人多、社区活跃、配置方便、升级方便的发行版，例如RH系列、 debian、ubuntu server等，硬件和操作系统要一起选择，看是否有适合的驱动，如果确定用某种商业软件或解决方案，也要提前知晓其对哪种操作系统支持最佳。web服务器方面，apache、nginx、lighttpd三大系列中，apache占有量还是最大，但是想把性能调教好还是需要很专业的，nginx和 lighttpd在不需要太多调整的情况下可以达到一个比较不错的性能。无论选择什么软件，除非改过这些软件或你的程序真的不兼容新版本，否则尽量版本越新越好，版本新，意味着新特性增多、BUG减少、性能增加。一个典型的php网站，基本上大多数人都没改过任何服务器软件源代码，绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6，python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog，看看升级说明，结合自己情况评估测试一下，越早升级越好，升级的越晚，所花费的成本越高。对于软件包，尽量使用发行版内置的包管理工具，没有特殊要求时不建议自己编译，那样对将来运维不利。

七、数据库
几乎所有操作最后都要落到数据库身上，它又最难扩展（存储也挺难）。数据库常见的扩展方法有复制、分片，设计时要考虑到每种应用的数据如何复制、分片，当然这种考虑一般会推迟到技术设计时期。在初期进行数据库结构设计时，要根据不同的业务类型和增长量预期来考虑是否要分库、分区，并且尽量不要使用联合查询、不使用自增ID以方便分片。复制延时问题、主从数据库数据一致性问题，可以自己写或者用已有的运维工具进行检测。

用存储过程是比较难扩展的，这种情形多发生于传统C/S，特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式，是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。

另外，现在流行一种概念叫NoSQL，可以理解为非传统关系型数据库。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，于是就产生了很多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次的写操作，内存型的甚至5万以上。在设计时，可根据业务特点和性能要求来选择是否使用这类数据库。例如 MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库结构再开发的模式。但是当你决定采用一项技术时，一定要真正了解其优劣，例如可能你所选择的技术并不能支持你所需要的事务和数据一致性要求。

八、文件存储
存储的分布几乎跟数据库扩展一样困难，不过只有百万的PV的情况下，磁盘IO方面一般不会成大问题，一两台采用SATA做条带RAID的机器可以应付，反而是自己做异步备份比较复杂，因为小文件多。如果只有一台机器做存储，可以做简单的优化，例如放最小缩略图的分区和放中等缩略图的分区，根据平均大小调整一下块大小。存储要规划好目录结构，否则文件增多后维护起来复杂，也不利于扩展。同时还要考虑将来扩容，例如采用LVM，或者把文件根据不同规则散列到不同机器。磁盘IO繁重的情况下更容易出现故障，所以要做好备份，若发现有盘坏掉，要马上行动更换，很多人的硬盘都是坏了一块之后，接二连三的坏下去。

为了将来图片走cdn做准备，一开始最好就将图片的域名分开，且不用主域名。因为很多网站都将cookie设置到了.domain.ltd，如果图片也在这个域名下，很可能因为cookie而造成缓存失效，并且占多余流量，还可能因为浏览器并发线程限制造成访问缓慢。

九、程序
一定硬件条件下，应用能承载多少访问量，很大一部分也取决于程序如何写。程序写的不好，可能一万的访问都承载不了，写的好，可能一两台机器就能承担几百万PV。越是复杂、数据实时性要求越高的应用，优化起来越难，但对普通网站有一个统一的思路，就是尽量向前端优化、减少数据库操作、减少磁盘IO。向前端优化指的是，在不影响功能和体验的情况下，能在浏览器执行的不要在服务端执行，能在缓存服务器上直接返回的不要到应用服务器，程序能直接取得的结果不要到外部取得，本机内能取得的数据不要到远程取，内存能取到的不要到磁盘取，缓存中有的不要去数据库查询。减少数据库操作指减少更新次数、缓存结果减少查询次数、将数据库执行的操作尽可能的让你的程序完成（例如join查询），减少磁盘IO指尽量不使用文件系统作为缓存、减少读写文件次数等。程序优化永远要优化慢的部分，换语法是无法“优化”的。

然而编程时不应该把重点放在优化上，应该关注扩展性。当今的WEB应用，需求变化非常之快，适应多种需求的架构是不存在的，我们的扩展性就要把要点放在跟底层交互的架构上，例如持久化数据的存取规则、缓存的存取规则等，还有一些共用服务，例如用户信息等。先把不变的部分做完善，剩下的部分就很容易将精力放在业务逻辑上面了。