NoSQL调查 PART3：开放源码的失败
作者：互联网
前言
开源的概念对于推动一代NoSQL数据库平台是不可或缺的，每一个平台都有风险投资的支持者，其中许多平台现在已经成功上市；这就造成了一些有趣的困境。
但是：
- 这些大肆宣传的 "流动性事件 "是否创造了与开源理念（和使命）直接冲突的市场预期？
- 像AWS这样的超大规模公司愿意提供许多这些产品的 "商店品牌 "版本，会在多大程度上颠覆许多数据库供应商精心制定的计划？
- 在原本没有架构的产品上添加新功能，会不会给用户带来一系列长期的问题？
为了解决这些难题，让我们首先看看我们是如何走到这一步的。
我们是如何在130个传统的RDBMS替代品中脱颖而出的？
关于开源NoSQL数据库革命发生的原因，不用多说，在大约五年的时间里，也就是在2007年到2012年之间，创新和创造力的爆发使130多个数据库涌现。
为了说明问题，451集团能够制作一个伦敦地铁系统的模仿，显示所有技术之间的关系。
来自451Group
这些技术中的绝大多数，包括Volt Active Data，都在某种程度上是开源的。这在一定程度上是对传统RDBMS的高度专有性的反应，但它的副作用是使这些技术对早期采用者更有吸引力，他们认为如果他们能不受限制地访问源代码，就能消除使用新技术的大部分风险。
走进VC：当前的开源NoSQL市场
我们现在处于一个非常不同的情况。显然，这个行业永远无法维持130个参与者的超级饱和状态，随着时间的推移，数据平台已经开始消失或变得休眠。
我们也看到了风险资本的到来，他们愿意进行大量的投资。风险投资行业观察到一个巨大的市场正在被颠覆，并希望成为其中的一部分。通过参与其中，他们为最初的开发者提供了一个获得大量个人报酬的机会，同时也为支持开发者社区提供了资金。
这种商业计划通常是：
- 把钱花在营销和支持上，以启动一个开发者社区。
- 付钱给开发者来建立产品，尽管代码是开放源代码的。
- 鼓励开发者在StackOverflow等论坛上回答问题，以推动采用，并对开源项目的可行性建立信心。
- 向企业客户收费，以获得支持和扩展的功能集。
虽然这是一个相对标准的风险投资方法，但需要理解的关键是，风险投资公司将开源看作是通向流动性事件的一个步骤，而不是本身就是一个有价值的目标。正如MongoDB首席执行官Dev Ittycheria所说。
"我们开源并不是为了从社区获得帮助，让产品变得更好。我们开放源代码是一种免费策略；推动采用。"
作为一个总体战略，这种做法非常好，因为开发者可以部署企业级产品，而不需要经过收购过程。
但Ittycheria也明确表示，作为开源并不意味着宣誓对代码的所有权，他并使用了专利律师的语言来做。
"MongoDB是由MongoDB建立的。没有任何现有技术"。
在翻阅了MongoDB的所有贡献者之后，我想说这个说法99%是公平的。我的观点是，虽然代码很可能是开源的，但通常很少有社区参与。
在开源领域，风险投资带来了巨大的变化。风险投资公司要么大大加速了不可避免的洗牌，要么不公平地把骰子装到有利于他们的投资组合中。
除了Postgres这个光荣的例外，几乎所有的数据库都受到了影响。我们现在正在进入一个新的时代，传统的RDBMS产品的寡头垄断正在被新技术数据平台的不同寡头垄断所取代。它们有什么共同点？他们都有风险投资的资金，现在需要满足投资者的期望，而不是让开发者满意。例如，MongoDB现在的市值为340亿美元，这意味着他们需要每年赚取约17亿美元来让投资者满意。2021年，他们的营业额为5.9亿美元，亏损2.71亿美元。Confluent将自己定位为一个数据库，市值为170亿美元。他们面临类似的期望。
考虑到数据库市场的历史规模（350亿到500亿美元之间），以及将应用从传统的RDBMS中转移出来的极端困难，很明显，这些公司将不得不变得非常、非常擅长从财富500强中获取收入，以使股东满意。这是不幸的，因为超大规模公司对数据库市场的这一端有自己的计划。
进入超量程
还记得VC的开源商业计划吗？那个涉及到对小用户保持产品免费，并通过企业客户的收入来弥补的计划？嗯，那个计划没有预见到超大规模的公司向这些客户提供开源产品的托管版本。
作为他们DBaaS产品的一部分，他们包括支持，这意味着可以使用数据平台 "X"，而不需要与编写数据平台 "X "的人交谈或付钱。相反，向超大型服务器支付托管和支持费用，同时也被卷入他们更广泛的生态系统中。终端用户和超级服务器都很高兴，但原始代码开发者却留下了一个巨大的收入窟窿需要填补。
供应商通过做三件事来回应这些事件：
- 采用服务器端公共许可证（SSPL）。
- 托管他们自己的产品，以及
- 试图增加功能以占领更多的传统RDBMS市场。
现在让我们仔细看看每种策略——
SSPL 和 NoSQL
SSPL现在正被广泛采用。虽然供应商继续把自己描绘成开源美德的典范，但他们明确表示，新许可证的意图是 "限制云服务提供商将我们的软件作为服务提供"。
SSPL是对所发生的事情的合理反应，但它有一个令人不快的副作用。除了源代码不可避免地被分叉和开发者社区被撕裂的明显问题外，如果你是财富500强之一，大家都想成为你的客户，还有一个更严重的问题：SSPL的措辞可能会阻止你从私人或企业云中提供有关的开源数据库作为DBaaS，以及公共的。
为什么呢？
这个问题是，许可证说，如果你向 "第三方 "提供服务，你必须分享任何相关的源代码。究竟什么是 "第三方"？许多大公司由几十个甚至几百个不同的法律实体组成，其中任何一个都会成为许可证眼中的 "第三方"。这并不是我们空想的灾难。我们知道，至少有一个非常大的德国企业集团因为这个原因而放弃了他们企业云中的SSPL产品。
供应商托管的解决方案
开源NoSQL数据库供应商为应对超大规模而采取的第二个策略是托管自己的产品。MongoDB、DataStax和Couchbase正在走这条路线。虽然这给他们提供了一条获得收入的途径，但它确实让终端用户怀疑在这种情况下 "开源 "到底意味着什么。
更奇怪的是，当一些坚持认为只有在他们能控制源代码和自己做所有支持的情况下才会使用数据库的人，显然乐意使用对内部情况一无所知的DBaaS产品时，我们会遇到认知上的不一致。
我们也看到了 "纯托管"的产品，如Snowflake、MongoDB
Atlas和Couchbase Capella的出现。从长远来看，这取决于供应商是否能够获得与超大规模公司竞争所需的规模经济。用户还必须了解，从财务和延迟的角度来看，在你的DBaaS供应商的云和超大规模之间路由流量会带来什么成本。
增加更多的功能
第三种策略是为NoSQL产品增加更多的功能，以吸收更多传统RDBMS产品的市场。我们现在看到这种情况在大范围内发生，ACID交易和SQL被改造成较新的NoSQL数据平台。
这里是历史开始重演的地方。
当它们第一次出现时，早期的传统RDBMS产品比 "最先进"的产品快得多。但是，随着供应商增加了越来越多的针对特定用例的功能，复杂性、缓慢性和臃肿性就出现了，特别是因为许多这些用例要求数据平台以其设计时没有的方式行事。这也是我们首先在数据平台上进行革命的原因之一。
让我们看一下两个具体的例子——SQL和ACID事务：
· SQL改造
使用无模式结构来存储数据的全部意义在于，让开发者完全有权决定什么被存储，以什么格式，以及作为什么主记录的一部分。这些设计选择是在单个记录的层面上进行的，而不是 "表"。
那么，SQL解析器如何知道哪些 "表"是存在的，而其中一个表可能是在数以百万计的记录中，作为一个单独的条目出现在下面三层？如果我，作为一个开发者，在我插入的一个新的JSON对象中添加了一个新的'表'，数据平台如何知道把它添加到'表'的字典中？请注意，我并不是在质疑一个资金雄厚的上市公司缺乏资源或技能来做这件事。相反，我想说的是，任何实施都是混乱的，有副作用的，而且会拖累整个产品。
而这只是改造SQL时的冰山一角。我们现在看到的 "SQL "实现在外观上是符合要求的，但经常有很深的语义差异，kSQL对SELECT的实现就是这样的一个典型例子。它背后的想法确实很聪明，但实现起来却与普通的SQL用户所期望的有很大不同。
· ACID交易
ACID交易是另一个改造会出现问题的领域。Volt Active Data公司在规模上做ACID交易，所以我们知道很多关于架构的选择，需要在很早的时候就做出选择来实现。
这个问题不能用巧妙的编程或更多的CPU能力来解决。相反，你需要将事务的持续时间减少到绝对的最小值，这意味着要做出架构选择，减少网络旅行的次数，保证序列化，并将逻辑转移到数据库服务器
开发人员本能地不喜欢这样做，但科学和基准是站在我们这边的。如果你在编写数据平台时没有把ACID作为 "第一天"的问题，你会发现，如果不进行破坏性的重写，破坏现有的应用程序，你能做的最好的实现就是与传统的RDBMS产品的行锁定能力和不可扩展的ACID性能相匹配，而这样做会使其他一切都变慢。
这些只是NoSQL厂商面临的挑战的两个例子，如果他们试图与传统的RDBMS进行 "功能战"。底线是，老话说'万能的人是无能的人'，这句话在这里是成立的。
总结
除了Postgres这个光荣的例外，那些幸存的开源数据平台面临着真正的挑战。使他们获得巨大成功的资金现在要求他们找到收入来源，但通过提供 "商店品牌 "版本，超大规模的公司正迫使他们要么增加功能以扩大其产品的吸引力，而不管基本的架构是否合理，要么做一个 "硅谷 "式的支点，进入托管业务，同时修复与财富500强公司的关系，这些公司因部署SSPL而受到伤害。
说实话：开源数据平台的梦想可能不会消亡，但它并不顺利。答案是找到一个快乐的媒介：一个能够在规模上提供ACID交易的平台，而不在性能上做出妥协，或做出在快速变化的数据世界面前无法兑现的承诺或价值宣言。
Volt Active Data预见到了NoSQL开源的失败，并介入了帮助。我们并不要求你马上投身其中--你可以从我们的官网开始，多多了解我们。
如果您希望集成VOLT到您的技术栈中，请与我们联系！
sgao@voltactivedata.com
标签：RDBMS,NoSQL,数据库,开源,PART3,开发者,产品,开放源码 来源： https://www.cnblogs.com/VoltDB/p/16178368.html