大量的在线应用程序一旦你实现适当的分片可以考虑扩展解决问题——通过越来越硬件可以生长。正如我最近写了但是并不意味着它是最优的方式做事。
“古典”分片user_id包括分区,site_id易手持或相似。这使得数据或多或少地均匀地扩散到整个盒和使用任意数量的盒子。不过这可能不是最优的方法本身,因为并非所有的数据都属于同一用户是相等的。
考虑博客或论坛为例——最可能的职位会得到大部分的点击而一些书面年前访问的频率要少得多。通常可以平整这明显读通过使用缓存(如果事情经常访问他们从缓存)但你仍然必须处理写道:这取决于你的设计有重要的影响。
它不仅必须活跃的部分数据同样可以活跃用户和那些几乎是死了。
另一个有趣的类型的数据,我发现经常在同一“集群”没有良好的原因是一些日志或历史数据。想想维基百科页面版本历史例如,积累大量很少用户需要阅读,各种变化日志等其他类型的数据。
除了将“冷”“热”的数据是非常有意义系统操作单独的数据根据其重要性——例如,如果数据目前不可用维基百科页面版本仍然可以提供99%的读,甚至可能处理写队列创建新版本。
也许是有意义单独的数据表(或分区)水平得到更好的“集群”,因为数据通常是由页面缓存,而不是行和索引条目所有热数据在单独的表冷表比拥有更高效的缓存数据的混合,即使总大小仍然相同。
也常有意义独立服务器级别上的数据。保持热的和生产关键数据集小也可以使系统执行速度以及大量操作的好处——小数据库花费更少的时间来备份和恢复更容易做ALTER TABLE和复制不会落后。
还可以使用不同的硬件的不同部分数据——你可以把“热”数据快速RAID卷甚至SSD虽然地方档案数据缓慢但大量SATA(除非响应时间不会成为展示塞)
当然,并不是所有的应用程序需要使用这种技术但有重要类的应用程序可以大大受益于它。
如果MySQL本身将是一件很酷的LRU类型查询缓存如何如何物理存储数据的方法。那将是很酷。
它会。不过我想先在线碎片整理。
还要注意不像去年那么容易访问时间是数据组织的唯一重要因素,相反有很多其他的事情,如访问路径应该考虑。
嗯。甚至有选项就好了。一个配置选项(就像InnoDB复苏风格)可能会被很多人使用。
试图决定如何分区数据,自己似乎有点令人生畏。我很乐意与一个LRU-style的事情。我的意思是,我将memcached和之前使用的缓存数据库。但任何进一步优化MySQL是受欢迎的。
我认为黄金法则对于大型站点应该是不要让你的客人直接打你MySQL ?
如使用鱿鱼?
当然有层缓存——鱿鱼,memcache等但最后一些负载的数据库,您需要处理它。
老实说,我认为有些事情是mysql的范围,我认为你的应用程序应该足够聪明拉从一个缓存。事实上框架(. net, cakephp, rails等)建在缓存(文件,内存,mcache,等等)支持你只需要使用它。MySQL是非常强大的,我认为它需要做更多的主/从复制之外,决定你如何使用它的数据并不是它的工作。能够处理多个服务器,数据库和表的一个集群,并提供易于使用的移动数据的方法为优化(表和数据库)的访问可能的范围内。知道什么时候和为什么你的数据建立坚定地与您和您的应用程序。
弗兰克,
数据库是在很大程度上缓解开发过程和创建的数据库能帮助它越多越好。确定框架可以有自己的缓存,但是这个缓存不够好可能有不同的应用程序在所有情况下加上访问相同的数据。
数据库可能不需要去猜测你是如何使用它的数据但至少遵循你的建议。如果你仔细想想索引是但提示数据库——我要用这一列快速查找我想要这些。集群、分区或物理排序是另一个方法来加速某些访问路径。
有趣的方式对数据进行分区!
让说,由user_id分区,我认为是不分区的主要困难,但是负载balacing,例如80%的用户是不活跃的,怎么能做20%的活跃用户在所有传播最大的数据库服务器。性能?
Howa,
首先,我应该说这个问题经常被夸大——事实上一些用户可以比别人多100倍,那又怎样?大数量的说每箱300000用户一切均等的很好。
然而有一个不同的问题,是关于用户“组织”不是用户个人用户。考虑例如你决定把盒子一个接一个,把所有注册他们直到300.000注册。
这可能是次优的,因为你会发现用户更活跃注册后第一天,它可能更复杂的用户是通过一些营销行动可能持续的利益而从其他可能主要是在短的时间内离开。
这也是很自然的对一些用户停止使用服务的活跃用户比例下降。
所以你需要考虑,看看什么样的分配策略在你的情况中是有道理的。有很多方法来组织。