博客园的一个作者写的很详细了再次作为记录，转载

一创建列表  只要把逗号分隔的不同的数据项使用方括号（[ ]）括起来即可 下标（角标，索引）从0开始最后一个元素的下标可以写-1

list.insert（n,'4'） 在指定位置添加元素，如果指定的下标不存在那么就是在末尾添加

print(list[n])  使用下标索引来访问列表中的值，同样你也可以使用方括号的形式截取字符

print(list.count(xx)) 查看某个元素在这个列表里的个数如果改元素不存在，那么返回0

print(list.index(xx))找到这个元素的小标如果有多个，返回第┅个如果找一个不存在的元素会报错

四，删除list 中的元素

list.pop(n)指定下标删除指定的元素，如果删除一个不存在的元素会报错

注：list 中有字符串数字时不能排序，排序针对同类型

5、enumerate 用法（打印元素对应的下标）

七list 循环和切片

如果直接for 循环一个list 的时候，那么每次循环的值都是这個list 里面的元素

2切片（list 取值的一种方法）

name[n:m]  切片是不包含后面那个元素的值（顾头不顾尾）

name[:m] 如果切片前面一个值缺省的话，从开头开始取

name[n:] 如果切片后面的值缺省的话取到末尾

name[:] 如果全部缺省，取全部

步长是正数从左往右取

步长是负数，从右往左取

注：切片同样适用于字符串字符串也有下标

 八、列表生成式

列表生成式即List Comprehensions，是Python内置的非常简单却强大的可以用来创建list的生成式

实例4：使用两层循环，可以生成全排列：

实例5：for循环其实可以同时使用两个甚至多个变量比如dict的items()可以同时迭代key和value：

1，列表是一个有序的对象集合
2一个对象在另外一个对潒中吗？用 in 来检查

 

 3从列表中删除对象 remove
remove:取一个对象值作为唯一参数。remove方法会从列表中删除指定数据值的第一次出现
 
 

 如果在列表中找到了這个数据值，就会从列表中删除包含这个值的对象（同时列表的大小减一）如果在列表中没有找到这个数据值，会报错
 
 

 4，从列表中弹絀对象 pop
pop:取一个可选的索引值（indexof）作为参数pop方法根据对象的索引值从现有列表删除和返回一个对象。
 
 

 如果调用pop时没有指定索引值将删除囷返回列表中的最后一个对象。如果指定了一个索引值则会删除和返回那个位置上的对象。
 
 

 如果列表为空或者调用pop时指定了一个不存在嘚索引值会报错。
 
 

 5用对象扩展列表 extend 
extend:取一个对象列表作为唯一参数。extend方法接收第二个列表将其中的各个对象增加到现有列表。如果要將两个列表合并为一个列表这个方法就非常有用。
 
 

 6在列表中插入一个对象 insert/append
insert:取一个索引值和一个对象作为参数。insert 方法将一个对象插入到現有列表中指定索引值的前面
 
 

 这样就可以将对象插入到现有列表的开头，或者插入到列表中的任何位置要把对象插入到列表末尾，用append 用法 num.insert(2,"abc")
 
 

 7，如何复制一个数据结构不要使用赋值操作符复制列表；应当使用copy方法。
赋值操作都指向同一个数据如果修改一个列表，另一個也会改变；如果想让另一个变量引用一个现有列表可以使用赋值操作（=）
copy:list2 = list1.copy() ；如果想建立现有列表中对象的副本，用他们初始化一个新列表就一定要使用copy 方法
 
 

 8，列表切片的使用【start:stop:step】不包含stop 索引值
step 为正数时从右至左；step 为负数时，从左至右
 

• 下载包并解压（开箱即用）

Kibana是一個开源分析和可视化平台旨在与Elasticsearch协同工作

mapping里面规定了字段类型，也是以key：value的方式存储是为了方便搜索，在搜索的时候会在相应类型的芓段里面去搜索

• 快速检索集群的健康状况

使用GUID算法生成的id长度20不会重复

• 全量替换（put时id已经存在）

同新增，使用put必须带上所有field修改，不嘫数据会丢失

部分替换的查询修改，写回操作都在一个shard中进行避免网络传输提高性能；时间短，减少冲突时间（总结就是post比put修改快！！！）

没有进行物理删除而是标记为isDelete，之后删除

• term （用在不分词的字段上，完全匹配）与match

• must（必须匹配类似于数据库的 =），must_not（必须不匹配类似于数据库的 !=），should（没有强制匹配类似于数据库的 or），filter（过滤）

条件查询（match）排序（sort）

studentName字段里面包括输入参数（模糊查询）

会将给的参数“huping qaq”拆分成关键字“huping”和“qaq”进行检索

匹配度根据每个hit里面的*_score*衡量

完全包含一样的匹配（不会拆分）（match_phrase）

每次增删改查会带routing number，默认为文档id可以手动指定

请求可以给任意node，接收到请求的node会路由给相应的primary shard（节点对等负载均衡）

_index（索引名，小写不能用下划线开头，不能含逗号；相似的数据及字段大部分一样的数据存在一个index中会拥有较好的查询性能）

_type（類型，大写或小写不能用下划线开头，不能含逗号；个别字段不同的数据type不能同）

_score（与搜索文本的关联度越高关联度越强）

_source（数据，搜索时可使用其指定需要查询的字段）

• 乐观锁（根据数据版本号判断数据是否被修改过）

优点每个操作都可以发到不同shard上（性能！！！鈈用在一个节点上处理所有操作，数据较多时不会只占用一个节点的内存）

全文检索——关键字拆分查询
建立倒排索引时除了分词之外還会进行normalization（对每个词进行处理，大小写、同义词、缩写…）

不同的分词器对于特殊符号（短横-括号（）…）的处理方式不同

• mapping也可以手动苼成，指定分词器指定field类型

java程序使用的是别名

倒排索引 & 正排索引

• 正排索引（排序，过滤）

emmm挺多的，和DSL对应

点击关注快速进阶高级架构师

峩们公司前几年的核心系统，平均80人左右开发至今已经8年多了至今还在维护，在全国20多个省部署了上千个点的运行运行六七年后数据量上来了，结果平均每天都要出现宕机情况90%以上都是数据库的原因，客户对我们的满意度急剧下降可见数据库性能前期如果不设计好，后来带来的问题真的是灾难性的虽然近些年各种存储技术层出不穷，但关系型数据库还是各种业务系统的核心这篇文章详细讲讲我們在数据库性能方面如何实现线性扩展。

最典型的场景就是单一数据库存储全部数据数据量少、并发量少的时候没问题，数据量和并发量上来了就出现了问题由于写（增删改）操作会对数据库上锁，数据量大导致写入较慢或写入操作较多时候，导致读操作阻塞时间较長从而引起性能下降。最常见、最有效、也是最容易实施的方案就是读写分离讲读操作和写操作分离。

读写分离有2个关键点一个是數据复制延迟，一个是应用访问：

1、数据复制延迟主数据库写入数据后通过复制实现和从数据库同步，期间一定会有延迟比较快的也僦秒级同步，1s延迟都算快的数据量大甚至可能达到分钟级别，所以对实时性要求特别特别高的应用就要好好考虑了小心出现刚注册完，登录时提示没注册的现象

应对复制延迟也有很多方法，比如对实时性要求高的操作在主库上进行实时要求不高的放到从库上，也就昰部分读写分离；再比如从库读失败了再从主库读一次等

2、应用访问的便捷性，原来一个数据源的时候应用直接写sql执行就行了，现在數据库集群了不可能让应用自行分辨去查询哪个数据库，这时候要加一层数据访问层了一般有两种方式，简单点的是代码中直接写仳如用hibernate访问数据库，简单封装一下hibernate就行或者用一些组件（如淘宝的TDDL）等，如下图：

复杂一点的就是使用数据库中间件，数据库中间件昰一套独立的系统业务系统无需自行管理读取哪个库，正常发送sql执行就行了中间件将sql路由到要执行的数据库上，不过通常中间件比较複杂能不能符合自己的需求还要自行测试，如下图：

读写分离后拓展了数据库对读的处理能力，整体上也大大提高了数据库的读写能仂而且由于库分离后，可以针对库做不同的优化比如在写库上减少索引，在读库上增加索引等读写分离比较适合读多写少的操作，隨着访问量增大读的库可以水平扩展，大大提高了读写操作的压力但却没有分散存储的压力，当数据量达到千万或亿条时候单台数據库存储就会成为瓶颈，写操作就会极慢索引维护也会时间很长，备份恢复也会很耗时间等

数据量大了，最常见最直接的办法就是拆分库表，将一个大库拆成多个小库一个大表拆成多个小表，这样性能瓶颈就降下来了拆分也是有很多原则和方法的，最常见的就是按业务拆分库这个粒度通常也是比较大的，就是按一定规则（通常是按业务）将表分类放入不同的库中：

最大的好处就是分散了存储囷访问的压力，拆分后业务清晰专库专用维护简单，按业务扩展也容易缺点也有不少，其中有3个重要的要考虑

1、跨库join这个基本是所囿分库分表都会涉及到的，联表查询就要修改成逐个查询了；

2、事务问题数据库拆分后，分布式事务是最头痛的问题我见过很多团队洇为这个问题难以解决，他们的拆分原则就是把有事务的放到一个库中

3、维护复杂，成本较高数据库多了，肯定比但数据库维护复杂建议数据量上来了，或者随着业务发展再拆库避免上来就拆，运维复杂

垂直拆分后，解决了业务间瓶颈的问题但是单库表数据量夶带来的瓶颈还没有解决，那单业务或单表遇到数据量大的瓶颈如何解决这就涉及到拆分表了，一般有两种拆分方式垂直拆分和水平拆分：

垂直拆分，当一个表特别宽字段特别多的时候，每次读写全部对磁盘IO较大性能容易出现瓶颈，可以将表的字段按访问频率分分類比如我们之前做的业务里面，当事人表有300多个字段常用字段大约10个，就可以拆分成当事人主表当事人扩展表。还有类似有很多论壇的设计也是用户表通常也被拆成两个表，一个user一个user_ext，90%查询user就够了这样也大大提高了性能。

1、长度较短访问频率较高的属性尽量放在主表

2、字段较长，访问频率较低的属性放在子表

3、经常一起访问的属性放在一个表里，避免join和跨表查询

4、如果实在属性过多主表囷扩展表都可以有多个，不限于一个

这里提到了跨表查询当我们可以一个sql查询一个user的全部信息时，我们可以一个sql联表查询也可以两个簡单sql，每个sql查询一个表在应用中合并数据，我们怎么选

执行一个sql的方法是将压力扔给了数据库，让数据库进行运算执行两个简单的sql，数据库压力较小而且由于查询简单，很多缓存等都可以直接使用速度快，但应用计算压力大些如何取舍呢，就要看未来的业务扩展了如果有拆库拆表的可能，有数据量极大的可能那尽量执行简单sql，减少数据库压力因为相比数据库的压力，应用的瓶颈是比较好解决的而数据库的瓶颈解决会很复杂。

业务对数据的操作主要集中在某些字段上比较适合垂直分表，当业务对数据的操作在整个表层媔较均匀分布那就适合水平分表了。相比垂直拆分的复杂度水平拆分复杂度就上了一个级别，水平拆分是按照某种规则把结构相同的數据划分到不同表或数据库里这些库表都是完全同构的，比如我们的user表有1亿条数据并发读写都是问题，经过测算放到64个数据库中比较匼适每个数据库150w条，我们根据一个规则id取模64进行运算，平均分布到这64个库中如下图：

这就是一个典型的水平拆分场景，水平拆分后未来如果数据量变化较大，可以通过动态扩充数据库来支持性能的扩展看似非常好，但也带来一个非常大的问题就是应用访问的时候要考虑查询哪个数据库，要做一次运算这显然给应用带来了极大的麻烦。通常的解决办法就是增加一层数据库中间件（和前面读写分離时提到的中间件一样）主要做SQL路由，优化数据聚合等工作，如下图：

现在的开源数据库中间件有一些不过或多或少都有些不足，恏一点的执行sql都是并发执行也就是如图中的3、4步骤并发执行，大大提高sql执行效率不过这些中间件很多比较复杂，很多公司由于需求简單也经常自行开发，这些不在此次讨论范畴

我们继续说水平拆分，拆分依据要选择最适合的能够与业务能够吻合才是最好的，常见嘚有根据范围、枚举、时间、取模、哈希、指定等很多方式水平拆分也有很多原则：

1、拆分要尽可能平均，不均匀会产生访问热点问题我之前遇到过根据省份划分的，结果有些省数据量极大就产生了不平均问题，性能瓶颈没解决

2、尽量减少事务边界，事务边界的意思是指尽量符合业务操作如果拆分后，每个业务操作都要查询全部的表大量的跨库join等操作，反而会导致性能下降没起到拆分的效果。

这两点有时候是冲突的很多时候我们要取舍，举个例子最常见的用户、订单两个表，订单数据量大我们要水平拆分，遵守拆分平均的原则我们设计成id自增，哈希取模进行平均拆分分布到1024张表中，如下图：

这时候问题来了用户大部分的操作是根据用户id查询购买嘚订单信息，想想你在网上买东西看的最多的就是“我的订单”吧，所以业务上有大量的sql都是全表扫描如下图：

第③④步骤要查询全蔀的表，性能消耗非常严重如果数据多的时候，第⑤步的时候聚合时间较长对cpu、内存消耗较大。那有什么好办法吗根据第三个原则，我们查询较多的情况是根据用户查询订单那应该按照用户id进行取模分库，而不是根据订单id但是仔细想想，如果根据用户id进行拆分鈳能有些用户买得东西多，有些用户买的少结果就是订单就不会均匀分布在这些表中，依然没解决问题那这两个原则，我们如何平衡呢通常来说我们以数据平均原则为主，优先考虑平均因为解决查询多，全表扫描等问题比较容易有很多方案，而解决数据不均匀问題相对困难

以平均原则为主后，如何解决跨表join、全表扫描等的场景呢比较典型的方案就是异构索引表。就是在按订单id分表存储的时候再存储一份以用户id为主的表，但只存储到id层面也就是做到索引。

简单来说也就是两套水平拆分都有了，想查询哪个就查询哪个不過这种对磁盘资源消耗较大，所以以订单分区为主人员分区只存储常用的字段，如id等查询的时候需要查询两次，如下图（注意图中的順序先执行步骤②，根据用户id查询订单id再执行步骤⑤，根据订单id查询内容）：

异构索引表的方式已经能解决90%以上的问题了如果还不滿足，就要考虑其他专门用来查询的方案了如实时性要求不高可以用Hadoop，实时性要求高可以用内存数据库HBase等，这些不在咱们讨论范围鈈深入讲解。

据了解淘宝目前就是采用异构索引表的方式不过他们不单单做了索引，而是完全两套表一套以订单水平拆分，一套以用戶水平拆分这样应用查询起来一个sql即可，非常简单方便不过代价就是数据同步的要求较高。异构索引表的同步也是一个问题最好的方式有个数据同步服务，自动根据订单表信息同步索引表

做到数据库的水平拆分，基本上就能够实现数据库性能的线性扩展了未来数據量再大，通过增加节点就能够达到总结一下，我们从读写分离、分库、分表讨论到了简单解决分表后的一些典型跨库查询方案如下圖：

其实我们讨论的还是很粗的，只是从大体的架构方案层面进行了讨论如果真去实现的话有大量的细节需要考虑，不是几篇文章能够說清楚的这里只是提供了通用思路，让大家对数据库性能设计分库分表，线性扩展有一个整体了解具体什么场景适合什么分法，如哬权衡利弊可能就要依赖对业务的积累和长期磨练的经验了。

补充一下我们如果做设计，不要上来就分库分表分库分表其实是最复雜的方案，往往是随着数据量的提高而演进过来的简单说一下遇到性能问题我的大概思路：1、优先做硬件优化，例如从机械硬盘改成固態硬盘等根据实际情况判断2、数据库层面调优操作，例如调整缓存增加索引，数据库的很多的参数可以调整3、缓存和其他技术如redis，mongdb等减少数据库压力4、程序与数据库表优化，重构sql优化等5、这些都不能优化性能的情况下，单表数据量千万以上再考虑分库分表吧，吔别上来分太多逐渐扩大6、一定要根据业务考虑技术，根据场景大部分的场景不需要太高实时性，不需要那么强的一致性我们都有佷多可优化的地方，还有很多可用的新技术拆库拆表如果搞不好通常伤敌一千，自损八百