亚马逊发布了Aurora系统，并允诺其会有许多引人注目的特性。让我们深入了解一下Aurora系统，并探索一下其分支结构。

    结构：

    Aurora的整体设计是这样的，利用一个master节点提供写服务，Slave节点展开在master节点周围，用于读，这听起来像MySQL-读操作是可扩展的。亚马逊还撰写了很多关于Aurora存储功能的说明，但是关于其结构细节的内容却少的可怜。也许他们将使用了SSDs的AWS DynamoDB作为对数据引擎透明的后端存储。因为扩展读操作需要用到AWS基础设施中的共享磁盘，所以Aurora只能工作在AWS上。

    扩展：

    通过允许15副本（Slave读操作节点），Aurora在多种工作负载情况都具有良好的可扩展性。然而，对于写操作的扩展细节是不明确的。最终系统性能会受到主节点写操作性能的制约。这里还没有提及内存中写入的处理，因此写入操作将限制于存储基础架构，其通常建议使用SSD，但横跨多个Availability Groups，又回到那个延迟的问题。

    可用性：

    亚马逊承诺同时提供多个“ 副本 ”（Slave读操作节点）和“基于恢复时间点的增量备份。” 但是，没有规定副本推送至写操作Master节点的延迟； 所以，如果丢失了写操作Master节点，将会产生一个（应用程序）的延迟，之后才能继续写操作。相应地，基于时间点的恢复也有显著延时：“……重建数据库到你保存的任意时刻直到最后5分钟前。“因此，如果您的实例挂掉，所有最后五分钟的事务都将丢失？Aurora试图通过将故障转移到其他副本，以缓解这种巨大的延时，即“Reserved Instance” “热插拔”硬件已经在云技术中出现了！

    复制：

    延迟是一个有趣的问题。亚马逊已经表示，他们的复制是异步的。这并不奇怪，因为如果不这么做，他们将在Master节点上看到巨大的写入延迟。他们声称复制是毫秒级的-但是具体是如何处理的并不为人所知。如果DynamoDB对他们来说是一个共享的磁盘存储，他们是如何处理Slave节点上缓存一致性的？这是另一个还未解决的有趣问题。

    性能：

    亚马逊承诺“Aurora性能是同等硬件条件下MySQL V5.6速度的五倍。”这听起来十分不错，但我们真的能看到实际的数字么？在特定平台运行测试的细节呢？大家都知道“可达到”是有一点回旋余地的。不幸的是，目前，Aurora是“有限预览，”所以我们都必须等待。

    事务延迟：

    如果需要多个“规定数量”的写操作和读操作（Slave节点）保持同步，Slave节点完全同步的延迟是多少？例如，如果应用程序是从Slave节点副本读取，然后Master节点被更新，这次事务是如何完成的？顾客添加一个电子商务网站上某个商品到购物车，一旦他们查询其购物车（例如，在Slave读操作节点上），他们可以选择更改所购商品数量或颜色。如果此时有customer2刚刚购买了某一个颜色的全部商品，customer1会话中是否会反映出最新的可用数量？或者应用程序有个机制来处理此类问题。这些是电子商务网站部署要解决的关键问题。

    总体而言，亚马逊的Aurora发布时给出了很多的承诺，比如“速度与高端数据库的可靠性，”但对于系统内部细节描述不多。具体来说，可能出现的各种延迟是否会影响到事务并发和应用程序的可用性？作为参考，NoSQL数据库可以提供惊人的速度和高可用性； 他们只需要'丢掉'事务支持，就能做到这一点。

    Aurora是采用SQL语法的加强版NoSQL数据库引擎？或者它是一个具有完全ACID属性、兼容MPP事务和MVCC功能的NewSQL数据库引擎？

    只有时间才能给我们答案，但至少可以肯定一点，那就是ClustrixDB是一个完全对ACID兼容，支持MVCC功能的数据库，在云计算的AWS，Rackspace和其他数百个全球实例上已经部署成功，每月处理万亿级的事务。

    本文出自：http://www.searchdatabase.com.cn/showcontent_86667.htm

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。