问题标签 [bigtable]

我正在尝试设计表格以建立追随者关系。

假设我有一个包含用户、主题标签和其他文本的 140char 记录流。

用户关注其他用户，也可以关注主题标签。

我在下面概述了我设计这个的方式，但是我的设计有两个限制。我想知道其他人是否有更聪明的方法来实现相同的目标。

这方面的问题是

1. 为每条记录复制关注者列表
2. 如果添加或删除了新的关注者，则必须更新“所有”记录。

编码

有没有更聪明的方法来做到这一点？

你们知道是否有一个应用程序可以让我以简单的方式使用 GET、PUT、DELETE HTTP 方法？

我想针对 Google 的 BigTable 运行它。

非常感谢。

我注意到谷歌应用引擎似乎有相当长的停机时间，他们将数据存储区置于只读模式。这种停机时间通常是在中午。这是仅在早期开发过程中发生的事情，还是我可以预料到总是会发生的事情？

我正在开发一个应用程序来帮助小型企业处理他们的运营。它所做的一件事是预约，另一件事是路由电话。我想就如何处理数据存储处于只读状态的时间提出一些建议，例如：

• 如果我们的客户正在与客户通话并且正在取消约会并且数据存储处于只读状态怎么办？要求客户稍后回来保存是不可接受的，尤其是在中午时。
• 如果有来电，并且由于数据库写入不可用，应用程序无法存储记录或正确路由呼叫怎么办？

通常如何处理这些类型的问题？

将机器添加到运行以下任一机器的机器集群时，性能（读取查询/秒）会增加什么因素：

• 类似 Bigtable 的数据库
• MySQL？

谷歌关于 Bigtable 的研究论文表明，使用 Bigtable 可以实现“近线性”缩放。此页面以 MySQL 的营销术语为特色，表明 MySQL 能够线性扩展。

真相在哪里？

我们已经运行了一些脚本，它们使用 LogParser 将 IIS 日志转储到 SQL Server 数据库中。

然后我们可以查询它以获取有关命中、使用等的简单统计信息。将其链接到错误日志数据库和性能计数器数据库以比较使用与错误等时也很好。

仅在一个系统上实现了这一点，在过去的 2-3 周内，我们已经拥有一个 5GB 的数据库，其中包含大约 1000 万条记录。

这使得对该数据库的任何查询都非常缓慢，如果我们继续按原样记录，无疑会导致存储问题。

任何人都可以建议我们可以用于这些数据的任何替代数据库，这些数据库对此类日志更有效吗？我对 Google 的 BigTable 或 Amazon 的 SimbleDB 的任何体验都特别感兴趣。

这些中的任何一个都适合报告查询吗？计数、分组依据、数据透视？

我正在使用谷歌应用引擎并使用低级 java api 来访问大表。我正在构建一个有 4 层的 SAAS 应用程序：

• 客户端网络浏览器
• RESTful 资源层
• 业务层
• 数据访问层

我正在构建一个应用程序来帮助管理我的移动汽车美容公司（以及其他类似的公司）。我必须代表这四个独立的概念，但不确定我目前的计划是否是一个好的计划：

• 约会
• 订单项
• 发票
• 付款

预约： “预约”是指员工为了提供服务而需要在的地点和时间。

行项目： “行项目”是服务、费用或折扣及其相关信息。可能进入约会的行项目示例：

发票： “发票”是客户承诺支付的一个或多个行项目的记录。

付款： “付款”是对已收到的付款的记录。

在此应用程序的先前实现中，生活更简单，我将所有这四个概念都视为 SQL 数据库中的一个表：“约会”。一个“约会”可以有多个行项目、多个付款和一张发票。发票只是根据行项目和客户记录生成的电子邮件或打印件。

10 次中有 9 次，效果很好。当一位客户预约一辆车或几辆车并自己付款时，一切都很美好。但是这个系统在很多条件下都不起作用。例如：

• 当一位客户预约了一次，但预约中途下雨导致detailer第二天要回来，我需要两次预约，但只有一个line item，一张发票和一份付款。
• 当办公室的一群客户都决定在同一天完成他们的汽车以获得折扣时，我需要一个预约，但需要多张发票和多笔付款。
• 当一位客户用一张支票支付两次预约时，我需要两次预约，但只需要一张发票和一张付款。

我能够通过稍微捏造一些东西来处理所有这些异常值。例如，如果一个细部必须在第二天回来，我只需在第二天再预约一个项目，上面写着“完成”，费用将为 0 美元。或者，如果我让一位客户用一张支票支付两次约会，我会在每个约会中放入拆分付款记录。这样做的问题是它为数据不一致创造了巨大的机会。数据不一致可能是一个严重的问题，尤其是对于涉及财务信息的情况，例如第三个示例，其中客户用一张支票支付了两次约会费用。付款必须直接与提供的商品和服务相匹配，以便正确跟踪应收账款。

建议结构：

下面是用于组织和存储这些数据的规范化结构。也许是因为我缺乏经验，我非常重视数据规范化，因为这似乎是避免数据不一致错误的好方法。使用这种结构，可以通过一个操作完成对数据的更改，而不必担心更新其他表。但是，读取可能需要多次读取以及内存中的数据组织。稍后我想，如果存在性能问题，我可以在“约会”中添加一些非规范化字段，以便更快地查询，同时保持“安全”规范化结构完好无损。非规范化可能会减慢写入速度，

表：

以下是将给定约会列表的所有四个实体（表）联系在一起所需的一系列查询和操作。这将包括关于每次预约安排了哪些服务、每次预约的总费用和天气或每次预约未收到付款的信息。这将是加载日历以进行约会安排或经理获取运营整体视图时的常见查询。

• 查询“开始时间”字段位于给定范围之间的“约会”列表。
  • 将返回的约会中的每个键添加到列表中。
• QUERY 对所有“Line_Items”的约会键列表字段包括任何退货约会
  • 将所有行项目中的每个 invoice_key 添加到 Set 集合中。
• 查询发票集合中的所有“发票”（这可以使用应用引擎在一个异步操作中完成）
  • 将返回的发票中的每个键添加到列表中
• 查询所有“付款”，其中 invoice_key_list 字段包含与任何返回的发票匹配的键
• 在内存中重新组织，以便每个约会都反映为其安排的 line_items、总价格、总估计时间以及天气是否已支付。

...如您所见，此操作需要 4 个数据存储查询以及一些内存中的组织（希望内存中会很快）

任何人都可以评论这个设计吗？这是我能想到的最好的，但我怀疑可能有更好的选择或完全不同的设计，我没有想到这可能会在一般情况下或特别是在 GAE（谷歌应用引擎）的优势、劣势和能力下更好地工作.

谢谢！

使用说明

大多数应用程序的读取密集度更高，有些应用程序的写入密集度更高。下面，我描述了一个典型的用例并分解了用户想要执行的操作：

经理接到客户的电话：

• 读取- 经理加载日历并查找可用时间
• 写入- 经理向客户查询他们的信息，我将其想象为一系列异步读取，因为经理输入每条信息，例如电话号码、姓名、电子邮件、地址等......或者如果有必要，也许一个在客户端应用程序收集所有信息并提交之后，在最后写入。
• 写入- 经理记下客户的信用卡信息并将其作为单独的操作添加到他们的记录中
• 写入- 经理向信用卡收费并验证付款是否通过

经理拨出电话：

• 读取管理器加载日历
• 读取经理为他要呼叫的客户加载约会
• Write Manager 点击“Call”按钮，发起一个调用并写入一个新的 CallReacord 实体
• 读取呼叫服务器响应呼叫请求并读取 CallRecord 以了解如何处理呼叫
• 写入呼叫服务器将更新的信息写入呼叫记录
• 调用关闭时写入，调用服务器向服务器发出另一个请求以更新 CallRecord 资源（注意：此请求不是时间关键的）

接受的答案:: 前两个答案都非常周到和赞赏。我接受了一个票数很少的人，以便尽可能不完美地平衡他们的曝光率。

我有几个实体，其属性编号在 40 到 50 之间。所有这些属性都未编入索引。这些实体是更大的实体组树结构的一部分，并且总是通过使用它们的键来检索。没有任何属性（除了 key 属性）被索引。我正在使用 Objectify 来处理 BigTable 上的实体。

我想知道在从 BigTable 读取或写入具有大量属性的实体时是否会对性能产生任何影响。

由于这些大型实体仅通过它们的键获取，从不参与任何查询，我想知道是否应该序列化实体 pojo 并存储为 blob。在 Objectify 中使用 @Serialized 注释非常简单。我知道通过序列化我的实体并将其存储为 blob，我使 blob 对任何其他程序或非 Java 代码完全不透明，但这不是问题。

我还没有对性能差异进行基准测试，但在这样做之前，我想知道是否有人以前这样做过或有任何建议/意见要分享。

背景：：：：

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

• 数据库设计——谷歌应用引擎
• 约会和行项目

我暂时决定使用一个完全规范化的主干，并将非规范化的属性添加到实体中，以便大多数客户端请求只需一个查询即可得到服务。

我认为完全标准化的主干将：

• 如果我在非规范化中编码错误，请帮助维护数据完整性
• 从客户端的角度来看，在一个操作中启用写入
• 允许对数据进行任何类型的意外查询（只要愿意等待）

而非规范化数据将：

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

基本的非规范化技术:::

我观看了一段描述称为“扇出”技术的应用引擎视频。这个想法是快速写入规范化数据，然后使用任务队列在后台完成非规范化，而无需客户端等待。我已在此处包含视频以供参考，但它长达一个小时，无需观看即可理解这个问题： http ://code.google.com/events/io/2010/sessions/high-throughput -data-pipelines-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，资源就会根据每条指令直接发出异步请求。

我对这种方法的担忧是：

• 它可以被解释为试图规避应用程序引擎的规则，这会导致问题。（它甚至不允许 URL 调用自身，所以我实际上必须有两个 URL 资源来处理相互调用的递归）
• 它很复杂，有多个潜在故障点。

我非常感谢您对这种方法的一些意见。

我想使用 Java 的低级 api 对具有预定义键的实体进行批量放置。

您可以批量获取：

然而，批量放置似乎都想分配自己的密钥：

文档页面：http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/datastore/DatastoreService.html#put(java.lang.Iterable)

我正在尝试批量获取实体集合，更新它们，然后将它们批量放回数据存储区。我应该能够在不更改其键值的情况下做到这一点是有道理的，不是吗？

1. 我可以知道在“nosql”中存在限制，就像我们应该“非规范化”我们的表/实体的 bigtable 一样？

2. 任何允许我们编写一次代码并可以用于谷歌应用引擎 bigtable 和 nosql 的 api 包装器？（类似于休眠）