云数据库的出现，正在悄无声息的，深刻的推动了这一趋势的到来：一些服务，如亚马逊的 S3、谷歌的 BigQuery、Snowflake、Databricks，尽管已经能够很轻松的存储不同数据源的不同数据类型，大量数据计算的问题似乎已经得到了解决，但还有一些企业，希望它们能够存储更多更全面的信息，从而获得更好的用户体验和商业收入。
现在是创建一家数据库公司最好的时机。
数据库公司在过去 10 年中，已经筹集了超过 87 亿美元，其中近一半的资金，即 41 亿美元，是在过去 24 个月内筹集的，相比于 2019 年的 8.49 亿美元，增加了很多（根据私募股权基金统计）。 根据 Snowflake 和 Databricks 的天价估值，和 2021 年 160 亿美元的收入，这并不奇怪，这缘于市场的增长。这个市场在过去四年里翻了一番，达到近 900 亿美元，预计在未来四年里将再次翻番。可以说，这是一个绝佳的机会。
下图是 2021 年数据库融资的清单。
20年前，你只有一个选择，那就是关系型数据库。
今天，随着云、微服务、分布式应用、全球规模、实时数据、深度学习的出现，新的数据库架构出现了，这是为了满足处理超算的性能要求。不同的系统用于快速读取，和快速写入。专门用于支持临时分析的系统，或用于非结构化、半结构化、事务性、关系性、图形或时间序列的数据。当然，也有用于缓存、搜索、基于索引、事件的数据。
每个人都有不同的性能需求，包括高可用性、横向扩展、分布式一致性、故障转移保护、分区容忍、无服务器和完全管理。
因此，企业平均需要用七个或更多不同的数据库中存储数据（比如 Snowflake 作为你的数据仓库，Clickhouse 用于临时分析，Timescale 用于时间序列数据，Elastic 用于搜索数据，S3 用于日志，Postgres 用于交易，Redis 用于缓存或应用数据，Cassandra 用于复杂工作负载，Dgraph 用于关系数据或动态模式）。这一切的前提，是假设你的服务部署在云中，并且你已经从头开始建立了一个现代数据堆栈。
与 5-10 年前相比，这些服务和平台的性能和稳定性是无可比拟的。同时，数据库层的可扩展性和碎片化也逐渐开始带来新的挑战。例如，在不同的模式和系统之间进行同步，编写新的 ETL 作业来衔接多个数据库的工作负载，持续的交叉通信和连接问题，在这么多不同的系统中管理动态扩展集群的开销，或者在新集群或系统上线时进行数据传输。每一个都有不同的扩展、分支、传播、分片和资源要求。
更重要的是，每月都有新的数据库出现，用于解决企业大规模生产中的下一个挑战。
新时代的数据库
因此，现在的问题，未来的数据库，真的需要像今天一样，被反复重新定义吗？
我认为，不应该是这样的。
与此同时，我希望下一代数据库的外观与上一代有很大不同。它们应该具有以下能力。
- 最重要的计算、查询和基础设施，可以位于商品存储层之上。
- 不需要对基础数据进行迁移或重组。
- 不需要重新编写或解析查询。
- 在多个存储引擎之上工作，无论是列式、非关系式还是图式。
- 将配置、可用性和规模的复杂性转移到代码中。
- 允许应用程序调用一个单一的接口，无论底层数据基础设施如何。
- 作为无服务器或管理服务，开箱即用。
- 在单人和多人模式下，为开发者优先的体验而构建。
- 为现有（蓝海）和新（绿地）项目提供第 0 天的价值。
许多由来已久的问题正在推动这个未来的数据库：
- 没有人愿意将数据迁移到一个新的数据库。每一个新的数据库引入到一个组织中，其成本是你已经拥有的数据库数量的 N² 问题。迁移到一个新的架构、模式、配置，以及需要重新优化的再平衡、查询规划、扩展、资源需求等等，往往是 [价值/（时间+成本）]接近零的问题。这可能是一个惊喜，但今天仍有数十亿美元的 Oracle 实例仍在为关键的应用程序提供动力，而且它们很可能不会消失。
- 大部分的杀手锏不会出现在存储层。计算和存储的分离，已经极大的提高了性能，现在，它允许使用超级便宜的原始存储，和精细调整的、可弹性扩展的计算/查询/infra 层。存储层可以成为数据基础设施的中心，并以各种不同的方式被多种工具利用，以解决路由、解析、可用性、规模、翻译等问题。
- 数据库正在慢慢地分拆成高度专业化的服务，摆脱过去那种过于复杂的、被锁定的方法。没有一个数据库可以完全解决交易和分析用例；具有快速读写、高可用性和一致性；同时解决边缘的缓存问题，并根据需要进行水平扩展。但是，在存储引擎的基础上将其分解成一系列的层，可以引入一系列新的服务，以提供新的性能和保障水平。例如，可以根据用户、查询和数据意识优化缓存的动态缓存服务；根据数据分布查询需求和数据变化率管理分片；通过连接池和资源管理实现高可用性和水平扩展的代理层；解决模式间异步和同步传播的数据管理框架；或者 GraphQL 和关系型数据库之间的翻译层。这些多维度的问题可以作为程序化的解决方案，在代码中构建，与数据库本身解耦，并且性能明显更好。
- 目前为止，人们一直在规模和简单性之间权衡。Postgres、MySQL 和 Cassandra 都非常强大，但很难搞好。Firebase 和 Heroku 超级容易使用，但不能扩展。这些数据库技术拥有庞大的安装基础和强大的引擎，并经受住了 Facebook 和 Netflix 级别规模的时间考验。但是根据你的需求，调整它们往往需要一个博士和一个数据库专家团队，就像 Facebook、Netflix、Uber、Airbnb 的团队一样。对于我们其他人，就会在一致性和隔离性、分片、锁定、时钟偏差、查询规划、安全、网络等方面挣扎。像 Supabase 和 Hydras 这样的公司可以用标准的 Postgres 安装，在上面建立强大的计算和管理层次，既可以有 Postgres 的拓展性，也可以有 Firebase 或 Heroku 的简单性。
- 30 多年来，数据库索引模型一直没有改变。今天，我们仍然使用通用的、一刀切的索引，如 B 树和哈希表，而对于数据，却像黑箱一样摸不透。稍微具备一些数据意识，例如利用累积分布函数（CDF），正如我们在 Learned Indexes 中看到的那样，可以导致更小的索引，更快的查找，增加并行性，并减少 CPU 的使用。我们甚至还没有开始展示下一代的索引，这些索引已经适应了我们数据的形状和变化。
- 几乎没有机器学习被用来提高数据库性能。相反，今天我们定义静态规则集和配置，以优化查询性能、成本建模和工作量预测。这些组合的、多维的问题集对人类来说太复杂了，无法配置，是完美的机器学习问题。磁盘、内存和 CPU 等资源被很好地描述，查询历史被很好地理解，数据分布也可以被定义。我们可以看到查询性能、成本和资源利用率提高了 10 倍，而且再也看不到嵌套循环连接。
- 数据平台和工程团队不希望成为DBA、DevOps或SRE。他们希望他们的系统和服务能够开箱即用，而不必考虑资源、连接池、缓存逻辑、吸尘、查询规划、更新索引等问题。今天的团队希望有一套强大的端点，易于部署，并能正常工作。
- 对操作实时数据的需求正在推动对混合系统的需求。交易系统可以快速地将新的记录写入一个表，并具有很高的准确性、速度和可靠性。一个分析系统可以在一组表和数据中快速搜索，以找到答案。随着流式数据和分析系统对更快响应的需求，HTAP（混合交易/分析处理）系统的想法正在出现——特别是对于那些具有高度操作性的用例——意味着非常高水平的新写入/记录和更灵敏的遥测或分析业务指标。这引入了一种新的架构模式，即交易和分析数据和系统开始相互接近，并不统一。
一类新的数据库
一类新的云数据库公司正在出现，有效地将传统的数据库单体堆栈解构为核心分层服务；存储、计算、优化、查询规划、索引、功能等等。像 ReadySet、Hasura、Xata、Ottertune、Apollo、Polyscale 和其他公司就是这一运动的例子，并迅速成为新的开发者标准。
这些新的非捆绑式数据库专注于解决缓存、索引、规模和可用性等硬问题，并开始消除性能和稳定性之间的分歧。更快速的数据库，永远稳定的，能够处理大规模数据，并具有数据意识，模糊了传统的操作和分析系统之间的分界线。未来看起来一片光明。
最后
我的个人主页 里也同步进行了更新，欢迎来逛逛。
