高可用性和数据库设计

这是我脑海中长期存在的问题之一.Facebook或拥有超过一亿用户的任何此类网站/应用程序如何维护数据库？

我相信一切都不能放到一个数据库中.如果是这种情况,是否应该有多个数据库处理不同的部分？不同的部分如:一个状态数据库,一个用于照片,一个用于用户......

数据库模式可以建立关系吗？

如果平均一个用户有10个文本更新,50亿行(至少),这应该是Facebook实际处理的数据的10%,那么用户数量将增加5亿.

我在某处读到Facebook有1800多个sql实例,其中800多个是memcached.这些数据库实例应该相同吗？这些如何设计？

Facebook和其他拥有庞大数据库的大公司采用数据库分区.

分区是在多个子表上分配表,这些子表可能驻留在不同的数据库或服务器上,以提高读/写性能.SQL Server分区通常在表级别完成,并且在分发相关表组时,数据库被视为已分区.表通常是水平或垂直分区的.

水平分区(也称为分片)可提高整体读/写性能

水平分区涉及将不同的行放入不同的表中.也许邮政编码小于50000的客户存储在CustomersEast中,而邮政编码大于或等于50000的客户存储在CustomersWest中.然后,两个分区表是CustomersEast和CustomersWest,而可以在两个分区表上创建具有联合的视图,以提供所有客户的完整视图.

水平分区是一种数据库设计原则,数据库表的行分别保存,而不是按列分割(对于规范化).每个分区都构成分片的一部分,分片又可以位于单独的数据库服务器或物理位置.

这种分区方法有许多优点.每个表中的总行数减少了.这减少了索引大小,这通常可以提高搜索性能.数据库分片可以放在单独的硬件上,多个分片可以放在多台机器上.这样就可以在大量计算机上分发数据库,​​这意味着数据库性能可以分布在多台计算机上,从而大大提高了性能.此外,如果数据库分片基于数据的某些真实世界分段(例如,欧洲客户与美国客户),则可以轻松自动地推断出适当的分片成员资格,并仅查询相关分片.

实际上,分片比这更困难.尽管通过手工编码已经做了很长时间(特别是在行具有明显分组的情况下,如上例所示),但这通常是不灵活的.需要自动支持分片,无论是为其添加代码支持还是分别识别要分片的候选者.

在分布式计算用于分离多个服务器之间的负载的情况下(出于性能或可靠性原因),分片方法也可能是有用的.

碎片与水平分区相比

水平分区按行拆分一个或多个表,通常在模式和数据库服务器的单个实例中.它可以通过减少索引大小(以及搜索工作量)提供优势,前提是有一些明显的,健壮的,隐式的方法来识别将在哪个表中找到特定行,而不需要首先搜索索引,例如经典示例'CustomersEast'和'CustomersWest'表格,其邮政编码已经指明了它们的位置.

分片超出了这个范围:它以相同的方式对有问题的表进行分区,但是它可以在可能的多个模式实例中进行分区.显而易见的优点是,现在可以跨多个服务器(逻辑或物理)分割大型分区表的搜索负载,而不仅仅是同一逻辑服务器上的多个索引.

跨多个隔离实例拆分分片需要的不仅仅是简单的水平分区.如果查询数据库需要查询两个实例,只需检索一个简单的维度表,那么效率的希望提高就会丢失.除了分区之外,分片因此在服务器之间拆分大的可分区表,而较小的表则一起复制到它们中.

这也是为什么分片与无共享体系结构相关的原因 - 一旦分片,每个分片可以存在于完全独立的逻辑模式实例/物理数据库服务器/数据中心/大陆中.不需要保持共享访问(从分片之间)到其他分片中的其他未分区表.

这使得跨多个服务器的复制变得容易(简单的水平分区不能).它对于全球分布的应用程序也很有用,因为数据中心之间的通信链路可能会成为瓶颈.

显然,模式实例之间还需要一些通知和复制机制,以便未分区的表保持与应用程序需求紧密同步.这是分片系统体系结构中的一个复杂选择:方法范围从使这些有效只读(更新很少和批处理),到动态复制表(以降低分片的一些分配优势为代价)和许多选项之间.

垂直分区可改善对数据的访问

在垂直分区表中,将从主表中删除列,并通过名为denormalization的过程将列放在子表中.这种类型的分区允许您在数据库页面上放置更多行,使表格更窄以提高数据访问性能.因此,单个I/O操作将返回更多行.通过垂直分区数据,您可能不得不求助于连接以返回非规范化列.

当然,除了分区之外,还有复制,可以提供多个数据副本.

对关系数据库模式的影响

Sharding会破坏你的关系数据库 - 这是一件好事.分片背后的想法是根据某些标准将数据分发到多个数据库.例如,这可以是主键.键以1开头的所有实体都转到一个数据库,其中2个转到另一个数据库,依此类推(通常使用键上的模数函数,或者基于业务数据的组,如客户位置或函数).分片存在几个原因,主要的两个原因是性能更好,崩溃数据库影响更小 - 只有名称以S开头的人才会受到数据库崩溃的影响.

在数据存储方面,关系数据库是几十年来的首选工具.但他们所做的不仅仅是存储数据.甚至阅读操作也可以分成几个功能.至少有三种数据库读取查询:

数据图构建查询:通过这些,您可以从数据库,客户以及地址等处获取数据.

聚合查询:8月份存储了多少订单,按产品类别汇总

搜索查询:给我所有住在纽约的客户

现在,Sharding消除了第二个和第三个查询,并将数据库减少为数据存储.由于分片是不同系统上的不同数据库,因此无法跨系统聚合查询(与群集相比),而无法使用一个查询进行搜索(只有几个查询 - 每个数据库一个).数据库导致了搜索和检索链接在一起并应该一起处理的概念.大多数人认为检索和搜索是一回事.这阻碍了技术的发展.Sharding,S3,Dynamo,Memcached最近改变了这个先例.Qi4j成名的Rickard说:

实体真的很酷.我们决定将存储从索引/查询中分离出来,有点像互联网如何与网站和谷歌一起工作,这使得实现真正简单的存储成为可能.不必处理查询会使事情变得更加容易.

因此,存储和搜索是两个不同的事情,任何相当大的网络相关公司处理它们是不同的.

人们谈论分裂存储和搜索一段时间了.像Lucene这样的搜索引擎推动了数据库的搜索.但主要是商店和搜索的概念很普遍.Sharding作为一种更高性能和更低风险的机制将进入许多网络公司,并将数据库减少到存储机制并放弃聚合(数据仓库和报告)和搜索部分.那些可以更好地填充像Mondrian这样的真实数据仓库服务器和基于Lucene的搜索服务或像Sesame这样的语义引擎.存储可能会从关系数据库转移到Amazon Simple DB或JDBM或NoSQL 等简单存储.