我们能给的
远比您想的更多
隐私条款信息保护中，请放心填写
400-9158-965
互橙各地办事处可统一调度，上门服务
显然，针对信息量较小的网站，select和update作用使得我们可以轻松处理遇到的困难，因为本身数据处理量较小，提升几个检索就能解决问题。但对于规模性网站，每日可能会解决上百万条数据。在这种情况下，若是有不够理想的多对多关系设计，在初期可能没问题，但随着用户数量的增长，信息量会呈几何级提升，这时进行数据select和update的成本会变得十分高。
一些网站选择使用缓存来应对高并发和大数据处理，但缓存在实际应用中也会带来问题。在整个应用程序中，缓存是全局共享的，但当我们同时对缓存进行修改时，如果有两个或多个请求需要更新缓存，应用程序可能会出现崩溃。因此，我们需要良好的数据并发处理策略和缓存策略。
此外，数据库的死锁问题也常常困扰我们。在高并发场景下，死锁的发生几率极高，这时，磁盘缓存就变成了一个严重问题。
对于支持文件上传的网站，随着硬盘容量的增加，我们对文件的存储和索引方式的考虑也应更为深入。一个常见的做法是按照日期和类型存储文件。然而，当文件变成海量数据时，如果一块硬盘存储了500G的小文件，无论在维护还是使用中，磁盘I/O都会成为一个巨大问题。即使你的带宽足够，你的磁盘可能也无法承受。如果又涉及到文件上传，磁盘容易被过度使用。
采用raid和专用存储服务器可能能解决当前的问题，但我们还需考虑如何解决各地的访问问题，比如服务器在北京，而用户在云南或新疆的访问速度可能会受影响。如果采用分布式系统，我们还需规划好文件索引和架构。
因此，我们必须承认，文件存储是一项挑战。
许多人可以轻易地设计出符合第三范式的数据库，其中充满了多对多的关系，甚至使用GUID来替换INDENTIFY COLUMN。但是，在这个多对多关系盛行的2.0时代，第三范式需要被重新评估。我们必须尽可能地降低多表联合查询的数量。
显然，索引是提高数据库查询效率的一种经济实用的方法。然而，在高UPDATE的情况下，update和delete所付出的成本会大得让人无法想象。笔者曾经遇到过一种情况，更新一个聚焦索引需要10分钟，这对于网站来说，大概率是无法接受的。
索引和更新本质上是对立的，在我们进行架构设计时，必须要考虑这个问题，而且可能会花费大量时间来处理。
由于2.0网站的高互动性，CDN的实践效果往往很差，因为内容需要实时更新。为了保证各地的访问速度，我们需要面对一个大问题，即如何有效实现数据同步和更新，以及如何实现各地服务器的实时通信。
对于HTTP协议，数据包都是以明文形式传输的，我们可以通过加密来对其进行保护，但这对于G问题来说可能不够安全，因为加密过程可能就是明文。
当你的网站流量不大时，可能没人会关心;但一旦流量上去，各种非法手段如外挂和群发便会接踵而来。我们可以采用更高级别的判断，甚至应用HTTPS来达到，但是这样做，付出的将是大量的数据库、I/O及其CPU成本。针对群发，根本就无法预防。
