标签: bigtable

由于Google App Engine数据存储区基于Bigtable,我们知道这不是关系数据库,因此如何为使用此类数据库系统的应用程序设计数据库架构/数据模型？

阅读Nathan Hurst的NoSQL系统视觉指南,他包括CAP三角形:

• Consistency
• Availibility
• Partition Tolerance

SQL Server是一个AC系统,而MongoDB是一个CP系统.

这些定义来自加州大学伯克利分校教授埃里克·布鲁尔,以及他在PODC 2000(分布式计算原理)上的讲话:

可用性

可用性意味着 - 服务可用(完全运行或不运行).当您购买该书时,您希望获得回复,而不是某些关于该网站的浏览器消息是无法通信的.吉尔伯特和林奇在他们的CAP定理证明中提出了一个很好的观点,即当你最需要的时候,可用性最常让你失望 - 网站往往在繁忙的时期因为他们忙碌而瘫痪.可用但未被访问的服务对任何人都没有好处.

在MongoDB或BigTable的上下文中,系统不"可用"是什么意思？

你去连接(例如通过TCP/IP),服务器没有响应？您是否尝试执行查询,但查询永远不会返回 - 或返回错误？

不可用是什么意思？

背景

我们希望将不可变事件存储在(最好)托管服务中.一个事件的平均大小小于1 Kb,我们每秒有1-5个事件.存储这些事件的主要原因是,一旦我们创建可能对这些事件感兴趣的未来服务,就能够重放它们(可能使用表扫描).由于我们在谷歌云中,我们显然将谷歌的服务视为首选.

我怀疑Bigtable非常适合这个,但根据价格计算器,我们每月花费超过1400美元(这对我们来说是一个大问题):

看看像BigQuery这样的东西每月3美元的价格(如果我没有遗漏必要的东西):

即使无模式数据库更适合我们,我们也可以将事件存储为带有一些元数据的blob.

问题

我们可以使用BigQuery而不是Bigtable来降低成本吗？例如,BigQuery有一些称为流插入的东西,对我来说似乎是我们可以使用的东西.有什么东西会在短期或长期内咬我们,如果走这条路线我可能不会意识到这一点吗？

像Google BigTable和Amazon SimpleDB这样的新学校数据存储范例是专门为可扩展性而设计的.基本上,禁止连接和非规范化是实现这一目标的方法.

然而,在这个主题中,共识似乎是大型表上的连接不一定必须太昂贵,并且非规范化在某种程度上被"高估"为什么然后,这些上述系统不允许连接并强制所有连接在一起单表实现可扩展性？是否需要存储在这些系统中的大量数据(许多兆兆字节)？
数据库的一般规则是否根本不适用于这些尺度？是因为这些数据库类型专门用于存储许多类似的对象吗？
或者我错过了一些更大的图片？

我需要一种方法来跨越(可能)数百GB的数据进行键值查找.理想情况下基于分布式散列表的东西,与Java很好地协作.它应该是容错的,并且是开源的.

商店应该是持久的,但理想情况下会将数据缓存在内存中以加快速度.

它应该能够支持来自多台机器的并发读写(尽管读取将是100倍).基本上,目的是快速初始查找Web服务的用户元数据.

谁能推荐任何东西？

我正在将巴西股票市场数据导入SQL Server数据库.现在我有一张表格,其中包含三种资产的价格信息:股票,期权和远期合约.我仍然在2006年的数据,该表有超过50万的记录.我有更多12年的数据需要导入,因此该表肯定会超过一百万条记录.

现在,我的第一种优化方法是将数据保持在最小值,因此我将行大小减少到平均60字节,并使用以下列:

[Stock] [int] NOT NULL
[Date] [smalldatetime] NOT NULL
[Open] [smallmoney] NOT NULL
[High] [smallmoney] NOT NULL
[Low] [smallmoney] NOT NULL
[Close] [smallmoney] NOT NULL
[Trades] [int] NOT NULL
[Quantity] [bigint] NOT NULL
[Volume] [money] NOT NULL

现在,第二种优化方法是制作聚簇索引.实际上主要索引是自动clusted的,我用Stock和Date字段作为复合索引.这是独一无二的,我不能在同一天为同一股票提供两个报价数据.

clusted index确保来自同一股票的报价保持在一起,并且可能按日期排序.这第二个信息是真的吗？

目前拥有50万条记录,从特定资产中选择700条报价大约需要 200 毫秒.我相信随着桌子的增长,这个数字会越来越高.

现在对于第三种方法,我正在考虑将表格分成三个表格,每个表格针对特定市场(股票,期权和远期).这可能会将表格大小减少1/3.现在,这种方法有用还是无关紧要？现在这个表有50mb的大小,所以它可以完全适合RAM而不会有太多麻烦.

另一种方法是使用SQL Server的分区功能.我不太了解它,但我认为它通常在表很大时使用,你可以跨越多个磁盘来减少I/O延迟,我是对的吗？在这种情况下,分区是否有用？我相信我可以在不同的表中划分最新的值(最近几年)和最旧的值,寻找最新数据的概率更高,而小分区它可能会更快,对吧？

什么是使其尽可能快的其他好方法？该表的主要选择用途是用于从特定资产中寻找特定范围的记录,例如最近3个月的资产X.将会有另一个用法,但这将是最常见的,可能超过3k执行用户同时.

有人能提供一个关于如何在Bigtable中构建数据的真实示例吗？请从搜索引擎,社交网络或任何其他熟悉的观点进行讨论,这清楚而实用地说明了行 - >列族 - >列组合如何优于传统的规范化关系方法.

背景::::

我正在使用谷歌应用引擎(GAE)进行Java.我正在努力设计一个能够发挥大表优势和劣势的数据模型,这些是之前的两个相关帖子:

• 数据库设计 - 谷歌应用引擎
• 约会和订单项

我暂时决定在一个完全规范化的主干上,将非规范化属性添加到实体中,这样大多数客户端请求只能用一个查询来处理.

我认为完全规范化的主干将:

• 如果我在非规范化中编码错误,请帮助维护数据完整性
• 从客户端的角度启用一次操作中的写入
• 允许对数据进行任何类型的意外查询(假设有人愿意等待)

而非规范化数据将:

• 使大多数客户端请求能够非常快速地得到服务

基本非规范化技术:::

我观看了一个app引擎视频,描述了一种被称为"扇出"的技术.我们的想法是快速写入规范化数据,然后使用任务队列完成幕后的非规范化,而无需客户端等待.我已将视频添加到此处以供参考,但它只需一小时,而且无需观看它就能理解这个问题:http: //code.google.com/events/io/2010/sessions/high-throughput -data-管道,appengine.html

如果我使用这种"扇出"技术,每次客户端修改一些数据时,应用程序将在一次快速写入中更新规范化模型,然后将非规范化指令发送到任务队列,这样客户端就不必等待他们也完成了.

问题:::

使用任务队列更新数据的非规范化版本的问题在于,在任务队列完成对该数据的非规范化之前,客户端可以对刚刚修改的数据发出读取请求.这将为客户端提供过时的数据,这些数据与他们最近的请求混淆客户端并使应用程序显得有问题.

作为补救措施,我建议通过URLFetch异步调用应用程序中的其他URL来并行扇出非规范化操作:http://code.google.com/appengine/docs/java/urlfetch/ 应用程序将等到所有在响应客户端请求之前已完成异步调用.

例如,如果我有一个"约会"实体和一个"客户"实体.每个约会将包括其预定的客户信息的非规范化副本.如果客户更改了他们的名字,那么该应用程序将进行30次异步调用; 每个受影响的约会资源一个,以便更改每个客户的名字副本.

从理论上讲,这可以全部并行完成.所有这些信息都可以在大约花费1或2次写入数据存储区所需的时间内更新.在非规范化完成后,可以对客户端做出及时响应,消除客户端暴露于不一致数据的可能性.

我看到的最大的潜在问题是,应用程序在任何时候都不能有超过10个异步请求调用(此处记录):http://code.google.com/appengine/docs/java/urlfetch/overview .html).

建议的非规范化技术(递归异步扇出):::

我提出的补救措施是将非规范化指令发送到另一个资源,该资源递归地将指令拆分成相等大小的较小块,用较小的块作为参数调用自身,直到每个块中的指令数足够小以便完全执行.例如,如果具有30个关联约会的客户更改了其名字的拼写.我将使用指令更新所有30个约会来调用非规范化资源.然后,它将这些指令分成10组3条指令,并使用每组3条指令向其自己的URL发出10个异步请求.一旦指令集小于10,资源就会根据每条指令直接发出异步请求.

我对这种方法的担忧是:

• 它可以被解释为试图规避app引擎的规则,这会导致问题.(它甚至不允许URL调用自己,所以我实际上必须有两个URL资源来处理相互调用的递归)
• 它很复杂,有多个潜在的失败点.

我真的很感激这种方法的一些意见.

我正在为Google App Engine开发一个应用程序,该应用程序使用BigTable作为其数据存储区.

这是一个关于合作编写故事的应用程序.这是一个非常简单的爱好项目,我正在努力寻找乐趣.它是开源的,你可以在这里看到它:http://story.multifarce.com/

这个想法是任何人都可以写一个段落,然后需要由另外两个人进行验证.故事也可以在任何段落中分支,以便故事的另一个版本可以在另一个方向继续.

想象一下以下树结构:

每个数字都是一个段落.我希望能够选择每个独特故事情节中的所有段落.基本上,那些独特的故事情节是(2,7,2); (2,7,6,5); (2,7,6,11)和(2,5,9,4).忽略节点"2"出现两次,我只是从维基百科中获取了一个树形结构图.

我还提出了一个建议的解决方案图表:https://docs.google.com/drawings/edit？id = 1fdUISIjGVBvIKMSCjtE4xFNZxiE08AoqvJSLQbxN6pc&hl = en

如何设置一个结构既可以提高写入性能,又最重要的是用于阅读？

前段时间,我想为一个新的统计系统,为我们的数百万用户网站,为我们的客户记录和报告用户操作.

数据库设计非常简单,包含一个表,一个foreignId(200,000个不同的id),一个datetime字段,一个actionId(30个不同的id),还有两个包含一些元信息的字段(只是smallint).其他表没有约束.此外,我们有两个索引,每个索引包含4个字段,无法删除,因为当我们有较小的索引时,用户会收到超时.foreignId是最重要的字段,因为每个查询都包含此字段.

我们之所以选择使用SQL服务器,但是在实现之后关系数据库看起来并不完美,因为我们不能每天插入3000万条记录(它只是插入,我们不做任何更新),而且还做了很多随机读取数据库; 因为索引无法快速更新.Ergo:我们有一个大问题:-)我们暂时解决了这个问题

关系数据库似乎不适合这个问题!

像BigTable这样的数据库会是更好的选择,为什么？或者在处理这类问题时还有其他更好的选择吗？

NB.此时我们使用单个8核Xeon系统,4 GB内存和Win 2003 32位.据我所知,RAID10 SCSI.索引大小约为表大小的1.5倍.