解决了NuoDB中的体系结构挑战？

Question

请参阅此视频：https://youtu.be/NsI51Mo6r3o?t=18m48s

这段视频的日期是9月。2013年。就技术而言，这是相当过时的。然而，在视频中，它提出了NuoDB面临的几个挑战。我想知道NuoDB在以下方面是否有所改进：

1. 加入过程中的竞赛条件。如果节点以错误的顺序连接，它们将以安静的拆分模式结束，如果稍后重新连接，则会丢失数据。
2. 数据库创建/模式操作中的争用条件
3. 以自动化的方式配置和启动系统很棘手
4. 当节点崩溃时，它不会带回存储管理器或事务管理器，这意味着数据可能突然变得不那么持久，因为您可能只有1或0的数据副本。
5. 在分区期间，事务由于cpu/存储传输资源而被阻塞。

Answer 1

是的，那是很久以前的事了-但那对我们的工程团队很有帮助。为了复制这些测试，我们做了大量的工作，并修复了它们暴露的问题。所有这些都写在一系列博客文章中。最好的起点是在这里：

http://dev.nuodb.com/techblog/network-failure-handling-roundup

这是其他人的保护伞柱，形成了全面的反应。

下一篇文章是稍后添加的，因此在上面的系列文章中没有链接，但仍然相关：

http://dev.nuodb.com/techblog/testing-network-failure-aws

关于您的第四点，关于重新启动崩溃的进程，NuoDB现在有了托管数据库的概念；这仅仅意味着它将自动遵守一个定义的SLA --从单个主机到最小冗余和多主机再到Geo分布式。这意味着数据库将自动重新启动或替换丢失的进程，以继续满足其SLA。您可以在数据库运行时更改SLA。