我应该在内存中、MS SQL 或第三方中实现键/值系统吗？
我想我已经做了足够的研究，知道我想要使用 NOsql 键/值路线。我已经尽可能多地阅读了，但仍然有以下问题：
我应该使用 amazon simpledb、google big table 或 microsoft azure 的解决方案吗？ （请注意，我是一个 .NET 网站）
为什么不简单地创建一个内存中的键/对象哈希表（假设内存足够充足来记录所有内容）？
如何在我的 SQL Server 中创建一个包含两列的表，一列是键，一列是值。键是主键，值是我想要的任何字符串。我必须提取该字符串并将其解析为有意义的内容。
我应该使用 Neo4j 图形数据库之类的东西吗？
我不清楚我应该走哪条路。
I think I've done enough research to know that i want to go with a NOsql key/value route. I've read up as much as i can and have the following questions still:
should i go with something like amazon simpledb, google big table or microsoft azure's solution? (note i'm a .NET site)
why not just simply create an in memory hashtable of keys/objects (assuming memory is abundant enough to story everything)?
how about creating a table in my SQL server with two columns, one a key and one a value. the key is the primary key and the value is a string of whatever i want. i'll have to pull the string out and parse it into something meaningful though.
shoudl i go with something like neo4j graph database?
it's unclear to me which path i should take.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的感觉是，如果您确实想要一个键值类型系统，请选择 noSQl 数据库。关系数据库不能很好地处理键值类型查询，它们是关系数据库中真正的性能杀手。如果您要走这条路，请使用正确的工具。
My feeling is if you really want a key value type system pick a noSQl database. Relational databases do not do a good job of handling key-value type queries and they are real performance killers in a relational database. IF you are going this route, use the right tool for it.