年末，开始总结本年的（去年2018）的一些心得，记录在此。
存储对象
数据最终是要存储的，无论是内存还是磁盘，但终究还是磁盘（有点儿绝对？？），许多时候内存并不可靠，核心在于断电后数据丢失，恢复数据是一个大问题，因此如果你想恢复数据，那么终究还是要落盘的。
存储的对象一般有KV，文档，文件（mysql的结构化数据本质上是对这些存储对象再解释），它的底层是文件，只是不同的业务对文件的解读不同罢了，因此无论上层业务多复杂，最终都是文件。
问题在于如何解释数据决定一个存储系统的核心架构。由此也演化出种种架构。
当业务的逻辑对象和存储对象越接近，一般性能越好，所以KV存储对接KV业务效果一般都不差，如redis；文档存储对文档业务，如Elasticsearch，文件存储对文件业务，如ceph。
反过来，如果我们用KV存储对接文档业务，那么必须要经过kv<---->document的转换，这是有代价，导致性能下降，当然你也可以通过其他的手段弥补，比如更快的硬件，网络以及算法，不过总体上看战术上的勤奋不能弥补战略上的懒惰。这里需要解释的是，并不意味着这种错位对接不可行，要看业务场景，很多时候这也许是最优的选择，比如基于KV的newSQL架构。
说到这里，我有一个问题，我们是怎么理解KV的？以下是我的看法，欢迎批评。
KV的本质是信息的总量太大，直接使用这些表达起来太复杂，不具可行性，比如人的名字和人个体的关系，人是很复杂的（任何生命体，算了，到了量子领域，任何宏观事物都复杂到不可描述），在信息传递过程中为了减少信息传递的总量（信道带宽有限），必须约定一个特征来代表信息本身。从这个角度出发，key就是value的一个特征，它屏蔽了value的复杂，用一个极简的简单的描述表达复杂的事物。因此在计算机世界里，几乎所有的信息都有一个地址信息，这个地址就是key，向前推演一步，任何索引，什么二级索引，全文索引其本质都是信息体的特征，因为有时候仅仅一个特征不能很方便的代表一个信息体，多个特征一般有两个目的，一个是差异化区分信息体，另一个是加速检索信息体。
总结一下，如何处理业务对象到存储对象的关系决定你系统的核心架构。功能，性能的演化也由此展开。
数据分片
之前谈过一次数据分片，数据分片的原因是单机的处理能力有限。一般数据分片有两种分片规则，一个散列化，一个范围切割。
之前大家都觉得散列化有两个问题，一个是业务层面的范围查询支持能力不足，一个是散列分裂很麻烦。其实似乎也不完全是这样，还是有一些解决办法的，散列内部有序化就是一个解决范围查询的很不错的思路，其实散列分裂也可以采用类似的思路，即我们不是一个slot对应一个分片，而是N个连续的slot对应一个分片，这样分裂就容易多了，不过这里隐藏了一个信息，存储对象的slot信息的还原，一个存储起来，一个临时计算。
这里再谈一谈索引和分片的关系。索引一般分为全局索引和本地索引。全局索引一般在OLTP业务上使用的多，总体上看是处理逻辑似乎简单，方便维护，缺点是动辄就是分布式事务，跨分片读写，优点是啥？我个人理解主要是减少无效的访问（无关分片），TP的业务针对性很强，涉及到的数据点也少，这么做很划算。本地索引一般适合OLAP业务，这类业务一般涵盖几乎所有分片，因此全局索引的价值不大，不如本地索引高效，本地索引的问题在于涉及到分片分裂的时候比较麻烦，一般只能重建，针对范围切割的分片，本地索引总有一种无处安放的悲伤。首先似乎不适合和原始数据存储在一起，因此原始数据是有序的，索引显然就无序了，只好另外找个地方存储，那么问题来了，分片分裂的时候，这些索引如何删除呢？总不能一直占着地方，这是脏数据，肯定要及时清理，但是这种场景下如果不是一个分片的索引独立存储的话（跟其他的本地分片的索引存储在一起）很难拆分，需要特别的设计，基本上就是把分片摘要作为前缀处理才行。这里你也看到索引不适合分裂，只能销毁重建。这就决定了这种模式下的分裂只能是业务层面的分裂，无法做到底层存储层面的分裂（这种方式速度更快）。
因此数据分片策略应该在设计的时候就确定下来，并且想清楚这要做需要解决的问题和面临的困难以及代价。
我个人特别讨厌那种走一步看一步的设计研发模式，计算机发展到今天，几乎绝大部分时候我们不需要摸着石头过河了，等我们真到了那么一天，那么恭喜你，你已经是超级科技巨头了，那个时候你大把的银子和人才（或者说天才）去应对更加复杂的问题。
架构
架构是什么？我个人理解是这样，架构就是信息流动的方式。
架构的根本目的就是解决信息流动的原则框架，是河床。
架构需要原则的坚守，这并不意味这保守，守旧。我特别推崇linux的核心原则：一切都是文件。linux从诞生到现在，一直坚守这个原则。猴子搬玉米式的架构设计简直就是儿戏，对架构缺乏敬畏，或者说是一种无知的表现。有人说善变是应对这个瞬息万变时代的良药，我不反对，但我更坚信对一些核心认知的坚守才是根本的应对之道。
架构不是攒机器，拼凑一下就行，就像拿许多颜色的布料缝衣服一样，功夫不到的设计师设计出来的是补丁衣，乞丐服，高超的技师设计出来的是惊艳四座的礼服。
还是喜欢刘润老师的一句话：要解决这个问题，我们要看清这个问题的本质。
我觉得理解了架构的本质，我们才能满怀敬畏之心，如履薄冰，认识到自己的渺小，才有可能讲涛涛大江为我所用，“将千斤之石推上万仞之巅”，然后一把推下去……
记得曾经研究google的三大论文，反反复复，很多东西不能理解，随着项目的实践才慢慢体会到其中的奥秘，然后回头再看，内心充满敬畏，先行者的智慧真的不是我等屌丝可以望其项背的，不过幸运的是，这些智慧可以为我所用，成为我们事业的砖瓦。
因此我总是喜欢尝试去理解一个系统架构在设计的时候面临的困难和要解决的问题，它是如何平衡各种需求的，它是如何演化的。
就这样吧。