IP地址查询数据库来源收集
有一段时间没有更新博客了,刚才看到最新的一篇《IP地址查询API来源收集》还是1月份写的,现在正好在搜索一些IP地址查询的数据库,就接着记录一篇吧。
这是数据库分类的页面,点击下面标题查看详细文章内容:
有一段时间没有更新博客了,刚才看到最新的一篇《IP地址查询API来源收集》还是1月份写的,现在正好在搜索一些IP地址查询的数据库,就接着记录一篇吧。
以前在Drupal站中需要数据库查询的时候都是优先考虑使用Views而不是自己写SQL语句,这确实方便了许多。但如果要跨站查询非本站数据库的时候就没法调用其它站的Views了。以前曾经把需要的表复制到当前站再用Views,不过这样可能造成大量冗余的数据表。
前一段时间在网上搜了一下,Drupal的API中本来就准备了这站外数据库查询的接口,下面是一个例子:
最近还在设法降低Drupal网站的MySQL负载,前些天尝试了安装entity cache,一般情况下可以把一个页面的70-120个mysql查询减少10个左右,然后把memcache使用的内存从1G增加到2G,应该会有一些帮助。
2015年下半年到2016年初我们集中把以前的Drupal 6网站都升级到Drupal 7了,记得当时还是花费了相当大的时间精力来做这些事情。这已经过去近2年时间了,升级后的Drupal 7网站也都运行正常,有些升级后遗留的模块和数据库中的表我们也没有多管,数据库空间不够就加空间。
我们这边从一开始使用Drupal就是利用的其本身的数据库结构,page, node, taxonomy, term等等都是使用Drupal本身的概念,很少直接操作数据,需要大量已有数据(一般是csv格式文件)导入网站的时候,就用第三方模块node_import (Drupal 6)或者feeds (Drupal 7)来设置和进行导入,形成页面以及分类,再辅助设置Views进行需要的列表。
今年以来将我们以前托管或者租用的服务器全面转向阿里云,除了采用ECS服务器以外,还有一项重要的是采用了RDS数据库服务器,这对于服务的稳定性、各项指标的监控、调优等都有帮助。
不过随着近期更多数据库转到RDS上,空间的占用、IOPS的升高等问题也越来越明显,增加RDS空间、升级RDS规格肯定是有用的,但一味这样做的话,费用会明显飙升,还是得想办法优化。