在线 Rss 阅读器的数据库架构
我需要创建一个在线 Rss 阅读器（就像谷歌阅读器一样）作为一个更大项目的一部分。我已经使用 MS SQL 完成了测试版本。然而问题是我不知道如何有效地将提要项目存储在数据库中：每个提要项目都有 id（guid 或只是永久链接），而当我将它们全部存储在一个表中时，仅 300 000 后性能就非常糟糕 - 500 000 件商品。
所以我有问题：
1）最适合我的问题的数据库引擎是什么（我不仅接受RDMS，可能是BerkeleyDB或其他东西（请写下为什么我应该使用某些引擎）？
2）组织数据的最佳方式是什么（即模式）在数据库中？
3）解决这个问题最好的语言/框架是什么？
如果您能给我与性能相关的一般建议，我将非常高兴。
更新： 我的想法是使用 Feed url 的 CRC8 哈希将 Feed 空间分割为 255 个子空间。一旦计算出这个 CRC8，就将其用作存储该 feed 项目的表的名称。
@FractalizeR：主要问题是
使用给定的字符串查找已使用此 id 存储在数据库中的 feeditem (SELECT * FROM FeedItems.pid = pid)，
这里的主要问题是 pid 是任意长文本。
I need to create an online Rss Reader(just like google reader for example) as part of a more big project. I've already done test version using MS SQL. However the problem is that i don't know how to efficiency store feed items in database: each feed item has the id (guid or just permanent link) and while i store them all in one table performance is incredibly bad after just 300 000 - 500 000 items.
So i have questions:
1) What is the best DB engine for my problem(i accept not only RDMS, may be BerkeleyDB or something else(please write WHY i should use certain engine)?
2) What is the best way to organize data (that is schema) in DB?
3) What is the best language/framework for this problem?
And i'll be pleased if you'll give me general performance related advices.
UPDATE:
My idea is to split feeds space into 255 subspaces using CRC8 hash of Feed url. Once calculate this CRC8 used as the name of the table where items of this feed will be stored.
@FractalizeR: the main question is
with given string find feeditem which already stored in database with this id (SELECT * FROM FeedItems.pid = pid)
the main problem here is that pid is arbitrary long text.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在设计数据库之前，您需要问自己的第一个问题是：“最有可能向数据库提出哪些问题”。如果您能为我们提供这个问题的答案，我们就可以继续规划数据库。
数据库在某些问题上可能很慢，而在其他问题上却非常快。
The first question you need to ask yourself before designing a database is: "What questions to the database are most likely to be asked". If you will provide us with the answer to this question, we can proceed to planning database.
Database can be slow on one questions and extremly fast on others.