正文
一、数据库缺少数据物理放置位置信息带来的优化器代价度量问题
在早期的分布式数据库的研究中，假定数据库管理员控制数据的物理位置。在云系统中，数据的物理位置由供应商控制，并不是客户。因此，数据的物理放置就通信代价方面来说可能不是最理想的，并且这可能导致大量的远程封锁请求和虚拟机之间的大量数据传送。高效的查询优化要求优化器能够准确度量操作的代价。由于缺乏数据的物理放置知识，因此优化器不得不依赖于可能非常不准确的估计，导致低劣的执行策略。因为远程访问相比本地访问要慢，所以这些问题可能会对性能产生重大影响。
二、云厂商跳过用户应用场景擅自复制用户数据带来的数据原子性或隔离性缺失问题
复制问题进一步加剧了基于云的数据管理的复杂性。云系统为了可用性而复制客户数据。事实上，如果没有维护特定级别的可用性，许多合约都有条款对供应商施加处罚。供应商实现这种复制是不具备对于应用的特定知识的。由于复制是在云控制之下的，并不在数据库系统的控制之下，因此当数据库系统访问数据时必须小心，以确保读取的是数据的最新版本。如果不能正确考虑这些问题可能导致原子性或隔离性特性的损失。在目前许多云数据库应用中，应用本身可能需要为一致性承担一些责任。
三、数据不在自家硬盘上导致的安全性和法律性问题
云计算用户必须愿意接受他们的数据被另一家组织机构掌握的事实。这可能会带来在安全性和法律责任方面的各种风险。如果云供应商遭受安全性攻击，客户数据可能泄露，导致客户面临来自其用户的法律挑战。然而客户不能直接控制云供应商的安全性。如果云供应商选择将数据（或数据的副本）存储在其他国家，这些问题将变得更加复杂。各种法律司法权在他们的隐私法中时不同的。例如，如果一家德国公司的数据被复制到纽约的服务器上，那么将采取美国的隐私法律，而不是德国的或欧盟的隐私法律。云供应商可能需要把客户数据发布给美国政府，尽管客户从不知道其数据将会卷入美国司法权管辖之内。
如今“云”的概念依然很火热，其实“云”很好理解，当然了，这里不说“云”是什么，只解释“云”的模式，简单来说就是服务供应商运行其自己的软件，但软件是运行在另一家公司提供的计算机上。这个计算机又是另一家公司通过虚拟化技术通过软件模拟出来的。理解了“云”干了什么事之后，就不能盲目的去“上云”而是要结合实际业务背景，去直接面对“云”带来的弊端，好进行取舍。
