数据库“写时模式”与“读时模式”对比

schema on write与schema on read

• schema on write（写时模式）

        作用于数据源到数据汇聚存储之间，典型使用就是传统数据库。数据不管是在入库还是采用装载外部数据或者将一个查询的输出结果写入数据库或者是使用UPDATE语句，数据库存储对于在数据写入数据库时都需要对schema进行检查控制，对照模式进行检查，如果在加载时发现数据不符合模式，则被拒绝加载数据。

• schema on read（读时模式）

        作用于数据汇聚存储到数据查询分析之间，数据先存储，然后在需要查询分析的时候再为数据设置schema，底层存储不会在数据加载时进行验证，而是在查询数据时进行。

两种模式对比

• 业务角度分析

1. 对于一个成熟的业务，已有模型足够涵盖所有的数据集，变化较少，则可以使用写时模型，提前定义好所有数据模型（数仓作用）；
2. 对于一个新的或者探索性业务，由于业务需求不定，并且变动频繁，因此数据不适合绑定到预定的结构，则可以使用读时模式，快速迭代，尽快交付业务需求。

• 数据质量对比

1. 写时模式，会对存储的数据质量进行检查或檫除（ETL），确保数据在某个业务场景下明确定义的、精确的和可信的；
2. 读时模式，因为数据没有受到严格的ETL和数据清理过程,也没有经过任何验证,该数据可能充斥着缺失或无效的数据,重复和一大堆其他问题，可能会导致不准确或不完整的查询结果。如果在on read的时候进行ETL，由于同样数据不同schema，则会导致重复工作。

• 效率对比

1. 写时模式倾向于读效率，因为数据存储在合适的地方，并做了类型安全和清理优化工作，通常更高效。但这是经过数据摄入时，繁琐的预处理为代价换来的；
2. 读时模式更倾向于写效率，数据摄入不需要做其它处理，简单，快捷。但是就会导致on read时，解析和解释数据效率低下。

• 功能与系统

1. 写时模式更多用于对结构化数据的OLAP与OLTP，对应传统的数据库系统；
2. 读时模式基于非结构化数据，需要存储更多的数据，海量的分析需求，快速的需求响应，与大数据系统不谋而和。

总结

1. schema on read强调灵活自由，schema on write注重稳定和效率；
2. schema on read与schema on write不是二者取一，而是相辅相成，互相协助；
3. schema有其存在的意义，无论是结构化还是非结构数据分析挖掘，schema都是必须的过程。