sql2008 sql服务_SQL即服务

sql2008 sql服务

自2007年以来，我一直在考虑这一点，大约在Amazon 推出 S3时。我什至尝试实现了几次，但是在设计阶段之后就失败了。我听说过一家初创公司也尝试这样做，但也失败了。我仍然不确定是否可以这样做，但是它肯定会成为云数据管理市场上的畅销产品。等等，您可能会说，Google Cloud SQL，AWS RDS，Microsoft Azure，Heroku PostgreSQL和其他许多呢？他们甚至不符合我的意思。

让我给你一个比喻。假设您要在云中存储一段二进制数据。我有两种解决方案。第一个是带有FTP的托管服务器。您每月付给我$ 5，我给您提供FTP访问服务器的能力，该服务器的磁盘为100Gb。您可以在那里上传文件并下载回来。效果很好。我还有第二个选择，即AWS S3 。您也可以通过其API上传和下载数据。而你付出为每个API请求，每个字节主办，每个字节传输，而不是月租费。您会选择哪一个？

显然，您将使用S3。为什么？两者之间的根本区别是什么？关键区别在于它们的SLA ：第一个带有FTP的服务器是服务器 ，第二个是服务的服务器 。

FTP服务器提供程序向您保证计算资源（CPU，磁盘，带宽等）的可用性，而S3向您保证数据的可用性。如果FTP服务器上的磁盘崩溃，它将及时进行更换，但是数据将丢失。如果磁盘已满，您将可以订购其他服务器，但是您有责任忘记。如果不使用磁盘空间，您仍需每月支付$ 5。等等。

正是由于这种差异，十多年前，AWS S3才是市场上的突破。他们在我们都习惯的旧的虚拟主机之上添加了一个新的服务层 。想法保持不变-仍然是我们上传和下载的云中数据-但SLA不同。我们不再需要担心磁盘溢出，为未使用的空间，常规备份，SSH终端以及更多其他事情付出过多的代价。他们只是给了我们一个简单的API，并保证数据在那里并且安全。

现在是2019年，对于关系数据我们仍然没有相同的数据。无论您选择哪个提供商，他们所做的只是为您提供一台安装了MySQL或PostgreSQL（或它们自己的版本）的计算机（或群集），并按小时收费。他们仍然为您提供“良好的旧FTP”，而无需在其之上附加服务层。

这就是我期望真正的云中关系数据SLA听起来像：

自动缩放 。不要让我们担心托管数据所需的资源量。只需为较大的数据集收取更多费用，并确保我们的请求在可预测的时间内返回即可。
按数据付费 。让我们为每个SQL请求，每个存储的字节和传输的每个字节付费。托管所有服务器需要多少服务器和磁盘-不必担心。
受限制SQL 。大多数项目不需要MySQL或PostgreSQL方言中的大多数命令。只需给我们INSERT ， SELECT ， UPDATE和DELETE并将其命名为一天即可。
索引。使用我们正在执行SQL查询的统计信息自动创建它们。
模式版本控制 。可以通过类似于Liquibase的方式来更新架构：我们创建一个新的ALTER TABLE或CREATE TABLE脚本，并将其应用于现有数据库。
快照和回滚 。如果出现问题，可以制作数据快照，应用新的架构版本，然后回滚到先前创建的快照之一。