我想我理解分片将你的切片数据(碎片)放回到易于处理的聚合中,这在上下文中是有意义的.它是否正确？
更新:我想我在这里挣扎.在我看来,应用程序层应该没有业务确定应该存储数据的位置.最好它应该是某种类型的分片客户端.两个回答都回答了什么,但不是为什么它是重要方面.除了明显的性能提升之外,它有什么影响？这些收益是否足以抵消MVC违规？分片在大规模应用中最重要,还是适用于小规模应用？
Sharding只是数据库"水平分区"的另一个名称.您可能希望搜索该术语以使其更清晰.
来自维基百科:
水平分区是一种设计原则,数据库表的行分别保存,而不是按列分割(对于规范化).每个分区都构成分片的一部分,分片又可以位于单独的数据库服务器或物理位置.优点是减少了每个表中的行数(这减少了索引大小,从而提高了搜索性能).如果分片基于数据的某些真实方面(例如,欧洲客户与美国客户),则可以轻松自动地推断出适当的分片成员资格,并仅查询相关分片.
有关分片的更多信息:
首先,每个数据库服务器是相同的,具有相同的表结构.其次,数据记录在逻辑上分成分片数据库.与分区数据库不同,每个完整数据记录仅存在于一个分片中(除非有备份/冗余镜像),所有CRUD操作仅在该数据库中执行.您可能不喜欢使用的术语,但这确实代表了将逻辑数据库组织成较小部分的不同方式.
更新:你不会打破MVC.确定正确的分片存储数据的位置的工作将由您的数据访问层透明地完成.在那里,您必须根据用于对数据库进行分片的条件来确定正确的分片.(因为您必须根据应用程序的某些具体方面手动将数据库分成几个不同的分片.)然后,在从数据库加载和存储数据以使用正确的分片时,必须小心.
也许这个使用Java代码的例子使它更清晰(它是关于Hibernate Shards项目),它在现实世界中如何工作.
解决" why sharding":它主要仅适用于具有大量数据的超大规模应用程序.首先,它有助于最小化数据库查询的响应时间.其次,您可以使用更便宜的"低端"计算机来托管您的数据,而不是一台大型服务器,这可能还不够.
如果您对DBMS的查询非常有限(例如,用户仅使用'where username = $ my_username'激活选择),则将所有以AM开头的用户名放在一台服务器上并且全部来自NZ在另一.通过这种方式,您可以获得某些查询的线性缩放.
简而言之:Sharding基本上是将表分配到不同服务器上的过程,以便平衡负载.
当然,它在现实中要复杂得多.:)
分片是水平的(行方式)数据库分区,而不是垂直(逐列)分区,即归一化.它将非常大的数据库分成更小,更快,更容易管理的部分,称为数据分片.它是实现分布式系统的一种机制.
为什么我们需要分布式系统？
增加可用性.
更容易扩展.
经济学:用单个大型计算机的力量创建一个小型计算机网络的成本更低.
您可以在这里阅读更多内容:分布式数据库的优点
分片如何帮助实现分布式系统？
您可以将搜索索引分区为N个分区,并在单独的服务器上加载每个索引.如果您查询一台服务器,您将获得结果的1/N. 因此,为了获得完整的结果集,典型的分布式搜索系统使用聚合器,该聚合器将累积来自每个服务器的结果并将它们组合.聚合器还将查询分发到每个服务器上.这个聚合器程序在大数据术语中称为MapReduce.换句话说,Distributed Systems = Sharding + MapReduce(虽然还有其他的东西).
下面的视觉表示. 
分片在大规模应用中最重要,还是适用于小规模应用？
当且仅当您的需求超出单个数据库服务器可以提供的服务时,分片才是一个问题.如果您拥有可分析数据并且具有极高的可伸缩性和性能要求,那么它就是一个膨胀工具.我想在我12年的时间里,我一直是一名软件专家,我遇到过一种可能从分片中受益的情况.这是一种适用性非常有限的先进技术.
此外,未来可能会变得有趣和令人兴奋,就像一个消除所有潜在性能限制的大型对象"云",对吧？:)
京公网安备 11010802040832号 | 京ICP备19059560号-6 