这些将被索引并在网络应用程序中随机访问，例如SO问题。SimpleDB 每个属性有 1024 字节的限制，但您可以使用多个属性，但听起来不优雅。
示例：博客文章;Facebook 状态消息;recipes（在博客应用程序中;类似 facebook 的应用程序;recipe 网站）。
如果我要在 Amazon AWS 上构建这样的应用程序，我应该在哪里/如何存储文本片段？
您可以将所有实际文件放在 S3 中，然后使用 Amazon RDS 或 Heroku 上的 Postgres 或任何当时适合您的文件来索引它们。
此外，您可以让客户端直接从 S3 下载多 kB 文本简介，因此您的应用程序可以只向消息传递 URL，从而创建一个大规模并行服务器 - 即使主服务器只是一台机器上的单个线程，从 S3 资产 URL 构建页面。S3可以存储所有资产，如图像等。
优势很大。这也解决了备份等问题。并允许您使用许多索引和搜索方案。例如，可以使用谷歌进行搜索...
我想说的是，你会想看看Amazon RDS，在云中运行像MySQL这样的关系数据库。单个 DynamoDB 读取容量单位只能（一致）读取 1KB 项目，这可能不适合您。
或者，您可以将文本文件存储在 S3 中，并将指向这些文件的指针放在 SimpleDB 中。这取决于许多更具成本效益的因素：您每天添加多少文件，这些文件预计更改的频率，请求它们的频率等。
就个人而言，我认为使用 S3 不是最好的方法。如果您将所有问题和答案存储在单独的文本文件中，则您会看到许多请求，即使是一个简单的页面。更不用说搜索了，这将要求您从 S3 获取所有文件并搜索它们。因此，对于搜索，无论如何都需要一个数据库。
您可以使用 SDB 来保存索引，但坦率地说，我只会在 Amazon RDS 上使用 MySQL（我认为现在有两个月的免费试用期），您可以在其中完成关系数据库可以做的所有好事，并且还提供对全文搜索的支持。RDS 应该能够扩展到每天的大量访问者：您可以轻松地一直扩展到具有 68 GB 内存和 26 个 ECU 的高内存四重超大型数据库实例。
据我所知，SO也是建立在关系数据库之上的：https://blog.stackoverflow.com/2008/09/what-was-stack-overflow-built-with/
DynamoDB 可能是您想要的，他们的文档中甚至有一个论坛使用案例： Amazon DynamoDB 中的示例表和数据
问题中没有足够的信息来为"我应该在哪里存储我将要使用的文本？
根据您构建应用程序的方式以及对速度、冗余、延迟、卷、可伸缩性、大小、成本、健壮性、可靠性、可搜索性、可修改性、安全性等的要求，答案可能是以下任何一项：
-
将文本放在附加到实例的 EBS 卷上的文件中。
-
将文本拖放到 MySQL 或 RDS 数据库中。
-
将文本拖放到分布在多个实例中的分布式文件系统中。
-
将文本上传到 S3
-
将文本存储在 SimpleDB 中
-
将文本存储在 DynamoDB 中
-
在弹性缓存中缓存文本
在这方面还有许多变体，例如将主副本存储在 S3 中，在 ElastiCache 中和本地磁盘上缓存副本，使用 DynamoDB 中的特定键对其进行索引，并使其在云搜索中可搜索。