如何在 MongoDB 中高效存储和查询原始 JSON 流？
我想将原始 JSON 流（通过 Twitter 或《纽约时报》）有效地存储在 MongoDB 中，以便稍后可以使用 Lucene 或 Hadoop 索引数据（《纽约时报》文章或推文/用户名）。在 Mongo 中存储数据最明智的方式是什么？我应该直接输入 JSON，还是有更好的东西？我只使用一台机器作为 mongodb，有 3 个副本集。
是否有一种有效（智能）的方式来编写查询或存储我的数据以更好地优化搜索查询？
I would like to store the raw JSON stream (either via Twitter or the NYTimes) efficiently in MongoDB, so that I can later index the data (NYTimes articles, or Tweets/usernames) with either Lucene or Hadoop. What's the smartest way of storing data in Mongo? Should I just pipe in the JSON, or is there something better? I am only using a single machine for mongodb, with 3 replica sets.
Is there an efficient (smart) way of writing queries, or storing my data to better-optimize the search-queries?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这完全取决于您需要进行什么样的查询以及您的应用程序的使用模式。
将每条推文存储在 Mongo Document 中非常简单，其中包含：发件人、时间戳、文本等。
根据您需要进行的查询，您将需要在这些字段上创建索引（更多信息：http://www.mongodb.org/display/DOCS/Indexes">http://www.mongodb.org/display/DOCS/Indexes" mongodb.org/display/DOCS/Indexes）
对于全文搜索，您可以对推文的文本进行标记/解析/词干，并为每条推文存储一个标记数组，您可以对其进行索引以快速查询。
如果您需要更强大的全文搜索功能，您还可以使用 Lucene 对其进行索引，并将 objectId 存储在每个 lucene 文档中 - 但这引入了本质上拥有 2 个数据存储的复杂性。
同样，如果不了解详细信息，这里实际上没有正确的答案用例。
This totally depends on what kind of queries you need to make and what the usage pattern of your application will be.
It would be pretty simple to store each tweet in a Mongo Document containing: sender, timestamp, text, etc.
Depending on what queries you need to make, you will need to create indexes on these fields (more info: http://www.mongodb.org/display/DOCS/Indexes)
For full text search, you could tokenize/parse/stem the text of the tweets and store an array of tokens with each tweet which you can index to make queries on it fast.
If you need more powerful full text search features, you could also index them with Lucene and store the objectId in each lucene document - but this introduces the complexity of essentially having 2 data stores
Again, there's really no right answer here without knowing the details of the use case.