在数据库发展的早期，数据库产品和技术被分为两类，一类是面向事务的OLTP（Online Transaction Processing），另一类是侧重分析的OLAP（OnlineAnalytical Processing）。OLTP通常用于联机交易系统中，例如电子商务中的订单交易和金融业中的账户交易，涉及频繁的插入、更改、删除操作和大量小规模查询，并发执行语句很多，但查询需要扫描的数据量或者返回的数据行数并不多。OLTP业务对系统的实时性要求较高，对数据的一致性的要求更为严格。如果在同一个事务中对两个账户操作，将资金从一个账户转账到另一个账户，那么一个账户余额减少和另一个账户余额增加必须是同时成功或者失败。对OLTP系统的考量主要是单个语句的执行时间和单位时间内完成的事务数量（Transaction Per Second, TPS）。OLTP的最终用户往往是业务系统的用户，也就是企业的最终用户或者业务终端。OLAP系统通常用在数据仓库和决策分析中，例如一段时期内的订单交易特点分析和违规的账户交易检测。这涉及批量的数据导入，少量的更改和删除操作，小量、大规模查询，虽然并发度不高，但查询涉及的数据量往往很多，甚至触及过去几年的历史数据和面向多个维度的汇总分析。OLAP的最终用户往往是企业内部分析、决策和管理人员。
在企业实际操作中，这两类系统也经常分开部署，主要的原因有两个，一是系统的资源限制，二是两者对产品的技术要求不同。在数据库产品出现的早期，系统多是单机系统，CPU、内存、磁盘容量和速度都有限，支持单纯的OLTP或者OLAP已经让系统资源吃紧，将两者混合在一起恐怕会带来1+1<1的效果。在技术实现上，OLTP系统的瓶颈往往是磁盘，主要优化手段包括索引和缓存。借助索引可以更快速地定位到相关记录，减少磁盘访问；借助缓存可以将频繁访问和最近访问的数据块放在内存，从而减少磁盘访问次数。而OLAP系统的瓶颈往往在CPU和磁盘。CPU的优化主要利用多核或者多机并行，磁盘的优化手段更加多样，包括分区技术、压缩技术和列式存储等
事务型和分析型系统的分开带来很多问题，一个问题是数据同步，另一个问题就是业务系统的复杂化。企业的联机应用需要访问和生成的数据被存储在一个事务型系统中，这些数据持续变化；历史数据和部分加工处理过的汇总数据保存在分析型系统中。事务型系统汇总的数据通常需要借助ETL定期更新到分析型系统中。ETL的数据量和同步速度决定了数据的实时程度，如果ETL作业需要一个晚上才能完成，也就意味着最新的数据只能在第二天的分析型系统中看到，这就是典型的T+1分析报表产生的根本原因。T+1意味着数据分析至少存在一天的延迟。对于有些业务，这样的延迟会产生一系列连锁反应，如果对于时效要求较高的业务能够在更短时间内或者近乎实时地完成分析，将给业务决策带来更多选择和先机。如果结合历史数据和实时数据的综合分析结果需要再次反馈给事务型系统，那么这样的改进好处更多。
面对这样的数据存储和布局，企业的业务系统也要相应地区分单一操作是针对什么系统、需要访问的数据来自哪里、生成的数据保存到哪里、被哪些系统访问处理、延迟是怎么样的、数据在事务型和分析型系统中的模型分别是什么、它们的对应关系是怎样的，等等。面对如此分散的数据分布和多样化的数据模型，应用的开发和维护人员需要考虑太多的问题，设计的应用在处理核心业务逻辑之外，同时需要处理所有这些问题，才能保证数据在不同时间段和不同情况下的有效性。复杂的业务系统也给运维工作带来了挑战，对应用的可靠性、容错能力和故障诊断机制都有很多的要求。
除了事务型和分析型系统之外，很多企业也部署各种各样的数据产品。从横空出世的全部或者部分抛弃ACID的NoSQL开始，到回归拥抱ACID的NewSQL，从文档型的MongoDB，到键值型的Solr和ElasticSearch，不断涌现的数据产品给不同行业、不同场景的用户提供了丰富的选择，也带来了选择的困难。通常，用户在面对一个问题时，很喜欢将一个新的数据产品引入到自己的系统中，因为这个新产品恰恰能解决他的问题。但随着时间的推移，系统中的数据产品越来越多，数据的分布就更加零散，数据的流通更难、时效性更差。用户在引入一个数据产品时，最重要的考量是这个数据产品是否适合他的业务要求和负载特性。这样一个一个业务考虑下来，即使一些业务可以共享一个数据产品，但还是有相当多的业务要使用不同的数据产品。在企业中引入多个数据产品后，不仅会造成数据孤岛并让业务逻辑更加复杂，也给开发和运维人员的技能增加了很多要求，他们要学习、掌握多种数据产品的用法、功能和问题诊断等，自然而然会占用他们大量时间。
有没有一种普适性的数据产品可以很好地支撑多种业务场景和不同的负载需求？这是很多用户经过这么多年的困扰后提出的一个共同问题。如果有这样一款产品，那么整个数据布局将得到极大的简化，很多此前不可能实现的业务也将变得容易，从而帮助企业更好地实施运营和改善用户体验。
理论上是存在这样的数据产品的。曾经制约混合负载部署的一些问题最近几年已得到改进。硬件资源的性能持续提高，单个服务器的CPU、内存和存储能力已相当可观，企业的数据中心和网络速度也足以支撑成千上万台服务器平稳运行。分布式数据产品的技术能力也已经非常成熟，在一个有上千台机器的大型集群中已经可以部署、运行单一数据产品来为企业的核心生产业务服务。各个数据产品也互相学习，取长补短，从而可以支持更加多样化的业务负载