|
正如我在几次演讲中所说，改进系统的最好方法是首先不要做“愚蠢的事情”。我并不是说你或你的开发人员是“愚蠢的”，很容易忽视这些类型的决策的含义，而没有意识到它们对可维护性有多糟糕，更不用说扩展了。作为一名顾问，我一直看到这些东西，我还没有看到它对任何人都有效。 图像、文件和二进制数据您的数据库支持 BLOB，所以将文件塞进去一定是个好主意，对吗？不，不是！地狱，与许多数据库语言绑定一起使用甚至不是很方便。 在数据库中存储文件存在一些问题：
最后两个才是真正的杀手。将缩略图存储在数据库中？太好了，现在你不能使用nginx或其他轻量级的Web服务器来提供它们。 帮自己一个忙，在数据库中存储磁盘上文件的简单相对路径，或者改用 S3 或任何 CDN 之类的东西。 临时数据使用情况统计信息，指标，GPS位置，会话数据 任何仅在短时间内对您有用或经常更改的内容。如果您发现自己使用 cron 作业删除了某个表的一小时、一天或几周，那么您为该作业使用了错误的工具。 使用redis，statsd / graphite，Riak任何其他更适合该类型工作负载的东西。同样的建议也适用于不会存活很长时间的临时数据的聚合。 当然，可以使用反铲在花园里种植一些西红柿，但是在车库里拿起铲子比用反铲安排时间让它到达你的地方并挖掘要快得多。为手头的工作使用正确的工具。 日志从表面上看，这个似乎还可以，“我可能需要在未来的某个时候对它们使用复杂的查询”的论点似乎赢得了人们的支持。将日志存储在数据库中并不是一个可怕的想法，但将它们存储在与其他生产数据相同的数据库中才是可怕的。 也许您对日志记录很保守，通常每个 Web 请求只发出一个日志行。这仍然会为站点上争用用户可能使用的资源的每个操作生成日志插入。将日志记录提高到详细或调试级别，然后看着生产数据库着火！ 相反，使用诸如Splunk，Loggly或普通的旧旋转平面文件之类的内容来记录日志。有几次你需要以奇怪的方式检查它们，甚至不得不写一些代码来找到你的答案，很容易被它放在你的系统上的持续资源所抵消。 日志要想做复杂的分析，可以用ELK比较好。 转自： |
|
|
