MySQL 内存表、Memcached 还是其他？
目前数据集增长超过 100 万，需要不断查找/更新用户特定数据。 寻找具有高 TPS 的最快且可扩展的选项。 Memcache/memcacheddb 与 mysql 内存表对于实现和扩展选项来说是一个很大的混乱。 任何人都可以提供适当的扩展/tps 和性能信息来确定哪一个？
A dataset growing currently >1 million which requires constant lookup / updation of user specific data.
looking for fastest and scalable option with high TPS.
Memcache/memcacheddb vs mysql memory tables are a big confusion for implementation and scaling options.
Can any one provide proper scaling / tps and performance information for which one to land on?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这些数据的完整性重要吗？如果是这样，您可以立即排除 memcached 和 MySQL 内存表，因为它们都没有持久存储到持久存储中。 memcachedb 至少是持久的，但它无法提供与普通 (R)DBMS 相同的可靠性保证。
Does the integrity of this data matter? If it does, you can immediately rule out memcached and MySQL memory tables, as neither one is persisted to durable storage. memcachedb is at least persisted, but it doesn't make the same sorts of reliability guarantees that a normal (R)DBMS would.
如果你有一个很大的数据集，你就不会通过向它扔硬件来扩展它。由于你没有说你的增长率是多少，所以很难提出任何建议。
如果您需要扩展写入 - 您可以对表进行分区。
如果您需要扩展读取 - 您创建 master >多从机复制集群。
此外，还有一个名为 TokuDB 的引擎可用于 MySQL - 更多信息请访问 www.tokutek.com。对于某些事情（更新、热索引添加等）来说它的速度非常快，但在大规模更新方面却不是那么出色。值得一看。
If you've got a large dataset, you don't scale it by throwing hardware at it. Since you didn't say what's your growth rate, it's difficult to suggest anything.
If you need to scale writes - you partition your table.
If you need to scale reads - you create master > multiple slaves replication cluster.
Also, there's an engine called TokuDB available for MySQL - more info at www.tokutek.com. It's extremely fast for certain things (updates, hot index addition and similar) but not that excellent when it comes to mass updating. It's worth checking out.