发布网友 发布时间:2022-04-24 16:55
共4个回答
懂视网 时间:2022-04-09 23:12
跨切片查询
大部分切分实现不支持跨切片查询,这就意味着,如果您想利用不同切分的两个数据集,就必须处理额外的长度。(有趣的是,Amazon 的 SimpleDB 也禁止跨域查询)例如,如果将美国客户信息存储在切片1中,还需要将所有相关数据存储在此。如果您尝试将那些数据存储在切片2中,情况就会变得复杂,系统性能也可能受影响。这种情况还与之前提到的一点有关 — 如果您因为某种原因需要进行跨切分连接,最好采用一种可以消除重复的方式管理键!
很明显,在建立数据库前必须全面考虑切分策略。一旦选择了一个特定的方向之后,您差不多就被它绑定了 — 进行切分后很难随便移动数据了。
一个策略示例
因为切分将您绑定在一个线型数据模型中(也就是说,您无法轻松连接不同切分中的数据),您必须对如何在每个切分中对数据进行逻辑组织有一个清晰的概念。这可以通过聚焦域中的主要节点实现。如在一个电子商务系统中,主要节点可以是一个订单或者一个客户。因此,如果您选择 “客户” 作为切分策略的节点,那么与客户有关的所有数据将移动至各自的切分中,但是您仍然必须选择将这些数据移动至哪个切分。对于客户来说,您可以根据所在地(欧洲、亚洲、非洲等)切分,或者您也可以根据其他元素进行切分。这由您决定。但是,您的切分策略应该包含将数据均匀分布至所有切分的方法。切分的总体概念是将大型数据集分割为小型数据集;因此,如果一个特定的电子商务域包含一个大型的欧洲客户集以及一个相对小的美国客户集,那么基于客户所在地的切分可能没有什么意义。
注意
比如类似交易记录的历史表信息,如果一条记录中既包含卖家信息与买家信息,如果随着时间推移,买、卖家会分别与其它用户继续进行交易,这样不可避免的两个买卖家的信息会分布到不同的数据库切片上,而这时如果针对买卖家查询,就会跨越更多的切片,开销就会比较大。
切片并不是数据库扩展方案的银弹,也有其不适合的场景,比如处理事务型的应用就会非常复杂。对于跨不同DB的事务,很难保证完整性,得不偿失。
在进行切分之前,一定要确定应用程序的规模和增长对其有利。切分的成本(或者说缺点)包括对如何存储和检索数据的特定应用程序逻辑进行编码的成本。进行切分后,您多多少少都被锁定在您的切分模型中,因为重新切分并非易事。
如果能够正确实现,切分可以用于解决传统 RDBMS 规模和速度问题。切分对于绑定于关系基础架构、无法继续升级硬件以满足大量可伸缩数据存储要求的组织来说是一个非常成本高效的决策。
Database数据库切片模式
标签:strong 方向 记录 编程 安全 程序 水平 利用 传统
热心网友 时间:2022-04-09 20:20
你所理解的模式是数据库系统*模式结构中的模式,也叫逻辑模式。
在*模式结构中的模式是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。一个数据库只有一个模式(逻辑模式)。它是以某种数据模型为基础的。用DDL来严格定义。
在图片中的模式,仅仅是关系数据库系统的一个基本对象(P80),只是也叫“模式”。关系数据库中的模式只是一个命名空间而已(P81),不是*模式中的模式。既,不是全体数据的逻辑和特征的描述。
在关系数据库系统mysql中create schema 与create database 是一个效果,但那也不能说schema=database。
这里的模式确实仅有定义一个命名空间的作用。
个人理解,仅供参考。欢迎大佬们来讨论下
参考资料:《数据库系统概论》(第五版)王珊等著
热心网友 时间:2022-04-09 21:38
你理解的是内模式,人家讲的是外模试热心网友 时间:2022-04-09 23:12
你好,这个是怎么回事呀