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脚本，并将其应用于现有数据库。
• 快照和回滚 。 如果出现问题，可以制作数据快照，应用新的架构版本，然后回滚到先前创建的快照之一。

真的很难实施吗？

翻译自: https://www.javacodegeeks.com/2019/11/sql-as-a-service.html

sql2008 sql服务