使用多个键值存储
我正在使用 Ruby on Rails，并且遇到一种情况，我想知道是否适合使用某种键值存储而不是 MySQL。我的用户有很多列表，每个列表都有很多单词。有些列表有数百个单词，我希望用户能够复制列表。这是一项繁重的 MySQL 任务，因为它必须一次创建这数百个单词对象。
作为替代方案，我正在考虑使用某种键值存储，其中键只是单词。单词列表可以存储在 mysql 的文本字段中。每个列表都可以是一个新的键值数据库？看起来以这种方式复制键值数据库会比必须通过数据库更快。一般来说，这似乎可能会更快。想法？
I am using Ruby on Rails and have a situation that I am wondering if is appropriate for using some sort of Key Value Store instead of MySQL. I have users that have_many lists and each list has_many words. Some lists have hundreds of words and I want users to be able to copy a list. This is a heavy MySQL task b/c it is going to have to create these hundreds of word objects at one time.
As an alternative, I am considering using some sort of key value store where the key would just be the word. A list of words could be stored in a text field in mysql. Each list could be a new key value db? It seems like it would be faster to copy a key value db this way rather than have to go through the database. It also seems like this might be faster in general. Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用关系数据库解决此问题的一般方法是拥有一个列表表、一个单词表和一个将两者相关联的表-单词表。你说得对，会有一些开销，但不要高估它；由于表结构已定义，每条记录的实际存储开销非常小，并且可以非常快速地插入记录。
如果您想要非常快的复制，您可以允许列表在写入时复制。这意味着单个列表可以被多个用户引用，或者被同一用户多次引用。仅当用户尝试添加、删除或更改条目时，您才实际复制列表。当然，这是不成熟的优化，从简单开始，只有在您发现有必要时才添加这样的复杂性。
您可以按照您的建议使用键值存储。我会避免尝试在 MySQL 文本字段之上构建一个更少的内容，你有一个很好的理由，它会使任何类型的按键搜索非常慢，因为它需要字符串搜索。像 CouchDB 或 Tokyo Cabinet 这样的键值数据存储可以很好地做到这一点，但它很可能会占用更多空间（因为每个记录都必须定义自己的结构，并且每个单词必须单独记录在每个列表中）。我认为性能更好的唯一维度是如果您需要大规模可扩展的读取和写入，但这仅与最大的系统相关。
我会天真地使用MySQL，只有当你需要性能并且可以证明这种方法实际上会更快时才进行这样的更改。
The general way to solve this using a relational database would be to have a list table, a word table, and a table-words table relating the two. You are correct that there would be some overhead, but don't overestimate it; because table structure is defined, there is very little actual storage overhead for each record, and records can be inserted very quickly.
If you want very fast copies, you could allow lists to be copied-on-write. Meaning a single list could be referred to by multiple users, or multiple times by the same user. You only actually duplicate the list when the user tries to add, remove, or change an entry. Of course, this is premature optimization, start simple and only add complications like this if you find they are necessary.
You could use a key-value store as you suggest. I would avoid trying to build one on top of a MySQL text field in less you have a very good reason, it will make any sort of searching by key very slow, as it would require string searching. A key-value data store like CouchDB or Tokyo Cabinet could do this very well, but it would most likely take up more space (as each record has to have it's own structure defined and each word has to be recorded separately in each list). The only dimension of performance I would think would be better is if you need massively scalable reads and writes, but that's only relevant for the largest of systems.
I would use MySQL naively, and only make changes such as this if you need the performance and can prove that this method will actually be faster.