我应该主要使用哪个数据库来进行一次写入/多次读取操作？
我正在构建一个应用程序，需要查询大量写入一次且不再更改的数据。我应该使用 MySQL 还是应该使用 SimpleDB 或 BigTable 之类的东西？ （我需要写一次，读很多遍）
谢谢。
编辑：我想使用 Heroku，对我来说大的是超过 5MB。 “数千行”占用超过 5MB。这就是为什么我想知道是否应该使用 CouchDB、SimpleDB 还是 MongoDB，以免支付 Heroku 收取的 15 美元费用。有什么建议可以克服这个问题？谢谢大家的评论！
I'm building an application that needs to query a lot of data that is written once and not changed anymore. Should I use MySQL for that or should I use something like SimpleDB or BigTable? (I need to write once, read many times)
Thank you.
Edit: I want to use Heroku, big for me is more than 5MB. "Thousands of rows" take more than 5MB. That's why I'm wondering if I should use CouchDB, SimpleDB or MongoDB in order not to pay the $15 that Heroku charges. Suggestions to overcome this? Thank you all for the comments!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
“大量数据”是什么意思？数千、数百万、数十亿行？每行有多少列和哪些列？您会使用许多连接还是简单的选择？
如果您的表很简单或者需要使用复杂的 JOIN，我会选择您熟悉的任何 SQL。
如果您的结构很复杂并且面向文档的数据库能够满足您的需求，我会选择 MongoDB（首选）或 CouchDB。
编辑：根据您的评论 - 数千行并不算多。使用您最喜欢的数据库并根据需要设置尽可能多的缓存（阅读有关必要缓存量的更多信息或开始新主题）。或者使用 Memcached，但我建议使用数据库缓存，因为它对您来说也很高效且轻松。祝你好运！
What does it mean "a lot of data"? Thousands, millions, billions of rows? How many and what columns per row? Will you use many joins or simple selects?
If your tables are simple or you need to use complicated JOINs, I would pick any SQL you're familiar with.
If your structure is complicated and if document oriented database would suit your needs, I would pick MongoDB (preferred) or CouchDB.
Edit: According to your comment - thousands of rows is not that much. Use your favourite database and set as much cache as it needs (read more about necessary cache amount or start a new topic). Or use Memcached but I suggest to use database cache as it's efficient too and painless for you. Goog luck man!
对于“一次写入，多次读取”，非规范化数据库（不会浪费周期进行连接等）是一个不错的选择。
因此，您应该设计表，使这些读取必须执行最少数量的 I/O 和连接。您可以对任何数据库执行此操作。重要的是表的结构。
AFAIK、SimpleDB 和 BigTable 都是分布式数据库，如果您的用户分布在不同的地理位置（从而绕过网络延迟），它们可以提供非常好的查询速度。如果 I/O 延迟不是瓶颈，它们不会提供太多优势。
For "write once, read many times", de-normalized database (that does not waste cycles to do joins etc.) is a good choice.
So, you should design your tables such that these reads have to do minimum number of I/Os and joins. You can do that with any database. It is the structure of your tables that matters.
AFAIK, SimpleDB and BigTable are distributed databases and offer very good query speeds if your users are distributed geographically (thereby bypassing the network latencies). They will not offer much advantage if the I/O latency is not the bottleneck.
比选择数据库引擎更重要的是表结构。您应该阅读 OLAP 数据库结构。另一个考虑因素是您编写的语言，确保对您要使用的数据库的 API 有良好的支持。 CouchDB 会很好，因为由于缺乏关系/事务，它的开销非常低。
More important than your choice of database engine is your table structure. You should read up on OLAP database structure. Another consideration is the language you are writing in, make sure there is good support for the API of the database you want to use. CouchDB would be good as it has very low overheads due to the lack of relations/transactions.
您拥有的数据量很小。任何 DBMS 都会处理几千行。我建议您首先查看一种流行的 SQL DBMS - 例如您已经提到过的 MySQL。您需要根据功能需求做出选择，而不是关心数据大小。
The amount of data you have is tiny. Any DBMS will cope with a few thousand rows. I suggest you look first at one of the popular SQL DBMSs - such as MySQL, which you already mentioned. You need to make the choice based on the functional requirements rather than be concerned with the data size.
对于这种小规模用例来说，单独的数据库是多余的。只需将数据序列化为平面文件，然后将其读入您所选择的语言的地图数据结构中即可。
A separate database is overkill for this kind of small scale use case. Just serialise your data into a flat file and then read it in to the map data structure of choice in your language.
我认为您应该使用非事务性和面向文档的数据库，例如 MongoDB 或 CouchDB 。
I think you should use non transactional and document oriented database like MongoDB or CouchDB .