是Oracle还是MySQL还是他们自己构建的东西?
是Oracle还是MySQL还是他们自己构建的东西?
Answers:
Bigtable是一个分布式存储系统(由Google构建),用于管理结构化数据,该结构旨在扩展到非常大的规模:数千个商用服务器中的PB级数据。
Google的许多项目都将数据存储在Bigtable中,包括网络索引,Google Earth和Google Finance。这些应用程序在数据大小(从URL到网页到卫星图像)和延迟要求(从后端批量处理到实时数据服务)方面对Bigtable提出了截然不同的要求。
尽管需求千差万别,Bigtable已成功为所有这些Google产品提供了一种灵活的高性能解决方案。
一些功能
建筑
BigTable不是关系数据库。它不支持联接,也不支持类似SQL的丰富查询。每个表都是多维稀疏映射。表由行和列组成,每个单元格都有一个时间戳。一个单元可以有多个版本,并带有不同的时间戳。时间戳允许进行诸如“选择此网页的'n'个版本”或“删除早于特定日期/时间的单元格”之类的操作。
为了管理巨大的表,Bigtable在行边界处拆分表并将其另存为平板电脑。平板电脑大约200 MB,每台机器节省大约100平板电脑。此设置允许将来自单个表的平板电脑分散在许多服务器上。它还可以实现细粒度的负载平衡。如果一个表正在接收很多查询,则它可能会丢掉其他平板电脑,或者将忙碌的表移到另一台不太忙的计算机上。另外,如果一台机器出现故障,平板电脑可能会分布在许多其他服务器上,因此对任何给定机器的性能影响都将降至最低。
表存储为不可变的SSTable,并存储一条日志(每台计算机一个日志)。当机器的系统内存不足时,它将使用Google专有的压缩技术(BMDiff和Zippy)压缩某些平板电脑。次要压缩只涉及几块平板电脑,而主要压缩则涉及整个表系统并恢复硬盘空间。
Bigtable平板电脑的位置存储在单元格中。任何特定平板电脑的查找都由三层系统处理。客户端指向META0表,该表只有一个。META0表可跟踪许多META1平板电脑,其中包含要查找的平板电脑的位置。META0和META1都大量使用了预取和缓存,以最大程度地减少系统中的瓶颈。
实作
BigTable建立在Google文件系统(GFS)上,该文件系统用作日志和数据文件的后备存储。GFS为SSTables提供了可靠的存储方式,SSTables是Google专有的文件格式,用于持久存储表格数据。
BigTable大量使用的另一项服务是Chubby,这是一种高可用性,可靠的分布式锁定服务。Chubby允许客户端进行锁定,并可能将其与某些元数据关联,可以通过将保持活动的消息发送回Chubby来续订该元数据。锁存储在类似文件系统的分层命名结构中。
Bigtable系统中涉及三种主要的服务器类型:
来自Google研究论文的示例:
存储网页的示例表的一部分。行名是 反向URL。contentes列族包含页面内容,anchor列族包含引用该页面的所有锚点的 文本。“体育画报”和MY-look主页都引用了CNN主页,因此该行包含名为
anchor:cnnsi.com
和的 列anchor:my.look.ca
。每个锚单元有一个版本 ; 内容栏有三个版本,在时间戳t3
,t5
和t6
。
API
BigTable的典型操作是创建和删除表和列系列,写入数据以及从行中删除列。BigTable通过API向应用程序开发人员提供此功能。在行级别支持事务,但不跨多个行键。
这是该研究论文的PDF链接。
在华盛顿大学的一次演讲中,您可以找到一段显示Google Jeff Dean的视频,该视频讨论了Google后端使用的Bigtable内容存储系统。
Spanner是Google的全球分布式关系数据库管理系统(RDBMS),是BigTable的继承者。Google声称这不是一个纯粹的关系系统,因为每个表都必须有一个主键。
这是本文的链接。
Spanner是Google的可扩展,多版本,全球分布和同步复制的数据库。它是第一个在全球范围内分发数据并支持外部一致的分布式事务的系统。本文介绍了Spanner的结构,功能集,各种设计决策的基本原理,以及揭示时钟不确定性的新颖时间API。该API及其实现对于支持外部一致性和各种强大功能至关重要:过去的非阻塞读取,无锁只读事务以及整个Spanner的原子模式更改。
Google发明的另一个数据库是Megastore。这是摘要:
Megastore是为满足当今交互式在线服务的要求而开发的存储系统。Megastore以新颖的方式将NoSQL数据存储的可伸缩性与传统RDBMS的便利性相结合,并提供了强大的一致性保证和高可用性。我们在细粒度的数据分区内提供了完全可序列化的ACID语义。这种分区使我们能够以合理的延迟在广域网中同步复制每个写入,并支持数据中心之间的无缝故障转移。本文介绍了Megastore的语义和复制算法。它还描述了我们支持使用Megastore构建的各种Google生产服务的经验。
正如其他人提到的那样,Google使用了一种称为BigTable的本地解决方案,他们已经发布了几篇将其描述到现实世界中的论文。
阿帕奇(Apache)的人们已经实现了这些论文中提出的名为HBase的想法。HBase是更大的Hadoop项目的一部分,根据他们的站点,该项目“是一个软件平台,使人们可以轻松地编写和运行可处理大量数据的应用程序。” 一些基准相当令人印象深刻。他们的网站位于http://hadoop.apache.org。
尽管Google将BigTable用于其所有主要应用程序,但它们也将MySQL用于其他(可能是次要的)应用程序。
而且,很容易知道BigTable不是关系数据库(如MySQL),而是一个巨大的(分布式)哈希表,它具有非常不同的特性。您可以在Google AppEngine平台上自己玩BigTable(限量版)。
除了上面提到的Hadoop,还有许多其他实现试图解决与BigTable相同的问题(可伸缩性,可用性)。我看到一个漂亮的博客文章昨日上市的大部分在这里。
Google主要使用Bigtable。
Bigtable是用于管理结构化数据的分布式存储系统,该系统旨在扩展到非常大的规模。
有关更多信息,请从此处下载文档。
Google还将Oracle和MySQL数据库用于某些应用程序。
您可以添加任何更多信息,我们深表感谢。
Google also use Oracle
-需要参考。
Google服务具有多语言持久性架构。BigTable被YouTube,Google搜索,Google Analytics等大多数服务所利用。该搜索服务最初使用MapReduce作为其索引基础结构,但后来在Caffeine发布期间过渡到BigTable。
Google Cloud数据存储区在Google的生产环境中拥有面向内部和外部用户的100多个应用程序。Gmail,Picasa,Google日历,Android Market和AppEngine等应用程序都使用Cloud Datastore和Megastore。
Google趋势使用MillWheel进行流处理。Google Ads最初使用MySQL,后来又迁移到F1 DB(一个自定义的书面分布式关系数据库)。Youtube在Vitess中使用MySQL。Google在Google文件系统的帮助下,跨商品服务器存储了EB级数据。
资料来源:Google数据库:Google服务如何存储PB级至EB级的数据?