10

我正在构建一个移动应用程序（iPhone/Android）并希望将应用程序数据存储到亚马逊的 SimpleDB 上，因为我们不想托管自己的服务器来提供这些服务。我一直在浏览所有文档，元素值的最大存储大小为 1024 字节。

在我的例子中，我们需要存储 1024 到 10K 的文本数据。

我希望了解其他项目在像我们的项目这样有更大的存储需求时是如何使用 SimpleDB 的。我读到可以存储指向文件的指针，然后存储在 S3（文件系统）中。不确定这是否是一个好的解决方案。

在我看来，我不确定 SimpleDB 是否是正确的解决方案。任何人都可以评论他们所做的事情或提供不同的方式来思考这个问题吗？

4

5 回答 5

14

有多种方法可以存储 10k 文本数据，但是否可以接受将取决于您还需要存储什么以及您打算如何使用它。

如果您需要存储任意大的数据（尤其是二进制数据），那么 S3 文件指针可能很有吸引力。SimpleDB 在此方案中添加的价值是能够针对您存储在 SimpleDB 中的文件元数据运行查询。

对于限制为 10k 的文本数据，我建议将其直接存储在 SimpleDB 中。它可以轻松放入单个项目中，但您必须将其分布在多个属性中。基本上有两种方法可以做到这一点，每种方法都有一些缺点。

一种方法更灵活且搜索友好，但需要您触摸数据。您将数据分成大约 1000 字节的块，并将每个块作为属性值存储在多值属性中。对多值属性没有排序，因此您必须在每个块前面加上一个用于排序的数字（例如 01）

将所有文本存储在一个属性中这一事实使得使用谓词中的单个属性名称进行查询很容易。您可以为每个项目添加不同大小的文本，从 1k 到 200+k 不等，并且会得到适当的处理。但是您必须注意，您的前置行号可能会对您的查询产生积极影响（例如，如果您正在搜索的01每个项目都将匹配该查询）。

在 SimpleDB 中存储文本的第二种方法不需要您在文本块中放置任意排序数据。您可以通过将每个文本块放置在不同的命名属性中来进行排序。例如，您可以使用属性名称：desc01 desc02... desc10。然后将每个块放置在适当的属性中。您仍然可以使用这两种方法进行全文搜索，但是使用此方法搜索会更慢，因为您需要指定许多谓词，并且 SimpleDB 最终将通过单独的索引搜索每个属性。

可能很容易将这种类型的工作视为一种 hack，因为对于数据库，我们习惯于在数据库中为我们处理这种类型的低级细节。SimpleDB 专门设计用于将此类事物从数据库中推送到客户端，作为提供可用性作为一流功能的一种手段。

如果您发现关系数据库将您的文本分成 1k 块以作为实现细节存储在磁盘上，那么它看起来不像是 hack。问题是 SimpleDB 客户端的当前状态是，您必须自己实现很多这种类型的数据格式化。这是理想情况下将在智能客户端中为您处理的类型。目前还没有任何免费的智能客户端可用。

于 2009-06-11T13:49:58.173 回答
1

如果您担心成本，您可能会发现将文本放在 S3 中并在 SimpleDB 中放置带有指针的元数据更便宜。

于 2009-06-12T17:49:54.360 回答
1

您可以将 10k 文本放在 S3 上，然后创建一个属性，将 10k 文本的所有唯一单词作为多个值。然后搜索会很快。但是，没有短语搜索。

一个“行”（名称）中的一个属性可以存储多少个值？我查看了文档，没有答案出现在我身上。

——汤姆

于 2010-02-12T22:23:00.950 回答
0

即将发布的Simple Savant（我创建的 SimpleDB 的 C# 持久性库）将支持 Mocky 描述的属性跨越和使用 Lucene.NET 对 SimpleDB 数据的全文搜索。

我意识到您可能不是在 C# 中构建您的应用程序，但由于您的问题是搜索 SimpleDB 和全文索引时的最佳结果，因此似乎值得一提。

更新：我上面提到的 Simple Savant 版本现在可用。

于 2010-01-29T16:23:57.370 回答
0

SimpleDb 很简单。其中的所有内容都是一个字符串。该文档非常简单明了。并且有很多使用限制。如：

  • 您只能SELECT * FROM ___ WHERE ItemName() IN (...)在ItemName.IN
  • 您一次只能PUT（更新）25 条记录。
  • 所有读取都基于计算时间。因此，如果您使用 a 执行 aSELECT可能LIMIT会1000返回类似800（甚至什么都没有）以及nextToken您需要在其中提出额外请求（使用nextToken）的内容。这意味着 nextSELECT可能实际上会返回限制计数，因此来自两个 s 的返回行的总和SELECT可能大于您的原始限制。如果您选择很多，这是一个问题。此外，如果你这样做，SELECT COUNT(*)你会遇到类似的问题。它会返回一个计数以及一个nextToken. 而且您需要不断迭代这些nextTokens 并对返回的计数求和以获得真实的（总）计数。
  • 所有这些计算时间将在很大程度上受到存储中较大数据的影响。
  • 如果您最终拥有大量记录，您可能不得不将记录分片到多个域
  • 如果您在单个域上发出太多请求，亚马逊将限制您的请求

因此，如果您打算使用大量的字符串数据，或者有很多记录，那么您可能需要寻找其他地方。SimpleDb 非常可靠，并且按照文档说明工作，但它可能会引起很多麻烦。

在您的情况下，我会推荐MongoDb 之类的东西。它也有自己的问题，但对于这种情况可能会更好。但是，如果您有很多记录（数百万或更多），然后尝试将索引添加到太多记录，如果它在 Spindel 而不是 SSD 上，您可能会破坏它。

于 2012-03-10T01:06:53.740 回答