你是懒女人么

相关文章

• No Related Post

   这几天真的是忙坏了,开心的事情是这些忙的事情都是有结果的,而且进展的算是顺利,虽然公司的待遇啥的没什么变动,可是小组的同事都很认真,很积极的去做每件他们能看得到的要做的事情,仅为此我感到相当的开心,和满足，因为这是让人感觉到希望和有动力的.

     其次的事情是,在某些事情上我开窍了.基本能站到一个高度上去处理事情了,不在是以前的那种以技术为中心, 我知道这是因为无形中需要多扮演一个角色的原因,当然这个角色没有任何人要求我去承担，只是我自己觉得那是我应有的一种责任.

    我现在的问题也很明显,还不够认真,还不够坚持,还需要更有耐心,还需要加强和人沟通的能力.等等``````,

    目前的小组里加上我只有三个成员了.都是那种法超多的,对技术保持着相当的热度的人,从解决问题的能力,和思考能力上, 都是很强大的, 最要紧的是大家理所当然的传承了,开放,公平,自由,的良好原则有意见,有想法,我们都会及时的进行头脑风暴,大大的增加了我们的协作的能力.和团体效能, 我相信我们都会成长到另一个高度的.

    遗憾的事情时,没有时间再去折腾单反了,也没有时间去找些女性朋友聊聊天,来发展我未来的娘子.

   工作上我很开心很充实,,生活上继续保持简单,

   认真的处理好和每一个有机会相遇,相识的人的关系.

    BTW:真心想找一个女朋友

OK ,就是这些~~

相关文章

• No Related Post

昨天是我第6次看这部片子了.概括性的说: 故事是想通过标题<当幸福来敲门>,来让你明白幸福当然是不会来自己敲门,而是需要自己努力的去追求.是一个个不断选择的过程.

面对同一件事情,有一种人的选择你是能看得到他的智慧的, 有一种人的选择你描述不出来他有哪里不妥当.还有一种人它的选择你可能是会所厌弃的.这就是传说中优秀的人和普通的人的区别.

第一个收获是终于明白了这个片名的含义，第二个收获是了解了剧情的演绎,所想传达给我们的东西是什么,当然还发现了这个片子的不足.

先说片名的由来. 根据剧情.我确认片名是来自男主角的妻子要告诉他要离他而去在雨中说的那段话

It was right then that I started thinking about Thomas Jefferson on the Declaration of Independence and the part about our right to life, liberty, and the pursuit of happiness. And I remember thinking how did he know to put the pursuit part in there? That maybe happiness is something that we can only pursue and maybe we can actually never have it. No matter what. How did he know that

(这个时候让我又开始想起了托马斯杰斐逊在独立宣言中，讲述的关于我们的生活自由以及追求幸福的那个章节,"幸福自己会来敲门" 我一直在思考这么个问题，他如何知道把“追求幸福”包括其中？也许幸福这个东西你是怎么也追不到的，也许我们从来都没有追到过它。但是他是如何知道的？

电影所想传达给我们的东西 让你明白幸福是不会自己来敲门的,而是需要自己坚持不懈的去努力的去追求的

剧情:

整个剧情他是分块的. 第一块了解人物背景,第二块了解人物是什么的一种人,有一种什么样的品质,第三块体会现实生活中这些品质会造成的影响,第四部份,体会成功的喜悦,并思考他的成功.

搭公车(第一块是故事的开始)-------> 犯傻(去证券所拿申请表第二块)------>疲于奔命(无工资的实习第三块)-追求到幸福(第四块)

剧情介绍:

引用这里<http://baike.baidu.com/view/684944.htm>

已近而立之年的克里斯·加德纳(威尔·史密斯)，28岁才第一次见到了自己的父亲，下定决心要给孩子做一个好爸爸。但事业不顺，生活潦倒，只能每天奔波于各大医院，卖骨密度扫描仪，偶然间认识到做证券经纪人并不是需要大学生文凭，只要懂数字和人际关系就可以做到后，就主动去找维特证券的经理Jay twistle，并凭借自己的执着、非凡的妙语，得到了一个实习的机会。

但是实习生有20人，他们必须无薪工作六个月，最后只能有一个人录用，这对克里斯·加德纳来说实在是难上加难。这时，妻子因为不忍穷苦的生活，独自去了纽约，克里斯·加德纳和儿子亦因为极度的贫穷而失去了自己的住所，过着东奔西跑的生活，他一边卖骨密度扫描仪，一边作实习生，后来还必须去教堂排队，争取得到教堂救济的住房。但是克里斯·加德纳一直很乐观，并且教育儿子，不要灰心，尤其在篮球场的那段话记忆犹新：别让人家跟你说，你成不了大器，即使我也不行。因为极度的贫穷，克里斯·加德纳甚至去卖血。功夫不负有心人，克里斯·加德纳最终凭借自己的努力，脱颖而出，获得了股票经纪人的工作，后来创办了自己的公司。

剧中经典台词:

-- what would you say if a man walked in here with no shirt and I hired him? what would you say?
He must have had on some really nice pants.

-- Don't ever let someone tell you, you can't do something. Not even me.

-- Maybe happiness is something that we can only pursue. And maybe we can actually never have it no matter what.
-- You got a dream, you gotta protect it. People can't do something themselves, they wanna tell you that you can't  do it. You want something? Go get it. Period.

---It was right then that I started thinking about Thomas Jefferson on the Declaration of Independence and the part about our right to life, liberty, and the pursuit of happiness. And I remember thinking how did he know to put the pursuit part in there? That maybe happiness is something that we can only pursue and maybe we can actually never have it. No matter what. How did he know that?

-- Hey dad, you wanna hear something funny? There was a man who was drowning, and a boat came, and the man on the boat said "Do you need help?" and the man said "God will save me". Then another boat came and he tried to help him, but he said "God will save me", then he drowned and went to Heaven. Then the man told God, "God, why didn't you saveme?" and God said "I sent you two boats, you dummy

-- Hey, don't ever let somebody tell you you can't do something

-- You got a dream, you gotta protect it.

-- People can't do something themselves they want to tell you you can't do it. You want something, go get it.
更多台词可以参看:

http://myenblog.com/u/Lovely/archives/2008/10131.htm

http://cgmingshy.blog.163.com/blog/static/83393489200941424313389/

相关文章

• No Related Post

在决定要花钱之前.最好是确定以下几个问题.

     一、我是否确定要做个这网站,是否是我真正的有预期的想要做.比如你确定不是因为一时冲动,或是仅是为了推动或是满足内心仅有这样的一种想法,

     二、必需有个足够的预期,你必先先想清楚,我是否在乎这个网站能否给我带来价值,当然这个价值是多方面的.比如有一定的的人会来访问,比如能为一定的人群提供帮助,得到一部份人群的认可.比如能挣到一定的流量,你希望的广告收入也可以很好的实现,等等

      三、我是否有足够的势力来运营这个网站,首先是技术势力, 比如针对IDC事物,服务器故障,应用服务器故障,你是否有一套完全可以解决的方案

      四、如何 产生有价值的东西,比如会有什么样的一种产品,如何生产你的产品,比如写技术文章,至少要确定是否真的可以生产出有质量的文章.能够得到哪些人的认可,这一点,从我的经验来看,这是需要一个团队的力量来进行的.

      五、可持续的运营,可持续的坚持.是否有充份的时间,和经历来处理运营中间的事物,这中间要面对的问题很多,比如前面提到的技术问题. 但其实技术从一个网站的运营来讲,是相当简单的.后续的难题,这个要看你对这个网站的预期了,达到什么样的一个状况,就是你预期的成功,这一点也很重要,否则你没有办法去坚持,        

     总结: 做个人博客也好,做咨讯网站也好,首先需要考虑的是确定你的网站的主题,定位在哪里,其实就是在准备上线之前,最好自己装个虚拟机先按照自己预期的方式运营一段时间,这样做的好处,一是可以了解营的难度,二是坚定自己的想法,三则是可以把不会的东西可以尽情的去学习,去借签,可以无数次重新过来.为你的适应和学习过程省钱.还有最重要的一点,就是一定要多花时间去鉴成功的人

      因为在起初想做个人博客的时候,就是因一时的新奇和冲动,除去了我的技术成本,(我是专业人士,所以这个不用额外去花时间),我对定位网站主题,运作方式.都是找很多牛人的网站进行行了很多的借鉴和学习的,希望以上的分享能想自己建博的人有所参考.

相关文章

• 2009年08月27日 -- iptables 引起 ssh 登陆变慢 (0)

In the last post i described how you can setup plproxy and create a basic horizontally partitioned cluster. Now we will take a look at another real life usage: building a read-only cluster for your database

Distributing read-only load

The simplest real world usage for plproxy would be it’s use for redirecting read-only queries to read-only replicas of master database. The replicated databases can be filled with data via Londiste that is part of the SkyTools package, setup tutorial can be found here or with Slony which is a more heavyweight solution but from my own experience also harder to setup and maintain though definitely at the time being better documented.
A typical read-only cluster could look like on the following schema. The databases with the letter (P) on them are connection poolers. We ourself use PgBouncer but pgpool is also a choice.
The poolers are needed to minimize the number of open connections to a database also execution plans are cached on a connection basis. Of course everything will work fine also without the poolers. Dashed bold arrows represent replicas.

In this setup the plproxy functions determine the database to which the query is redirected. Read&write queries go to master database and read-only queries are distributed based on the algorithm you define to read-only replicas.
Setting up replication itself is relatively easy once you have passed the painful skytools installation process.
First let us create both replicas from write database toward ro1 & ro2. ro1 configuration file looks like this:
replica1.ini

[londiste]
job_name = londiste_master_to_r1
provider_db = dbname=write
subscriber_db = dbname=ro1
# it will be used as sql ident so no dots/spaces
pgq_queue_name = londiste.write
pidfile = %(job_name)s.pid
logfile = %(job_name)s.log
use_skylog = 0

replica2.ini is basically the same only job name and database name need to be changed. Now let’s install Londiste on provider (write) and subscribers (ro1,ro2) and start the replication daemons:

mbpro:~/temp kristokaiv$ londiste.py replica1.ini provider install
mbpro:~/temp kristokaiv$ londiste.py replica1.ini subscriber install
mbpro:~/temp kristokaiv$ londiste.py replica2.ini subscriber install
mbpro:~/temp kristokaiv$ londiste.py replica1.ini replay -d
mbpro:~/temp kristokaiv$ londiste.py replica2.ini replay -d

The next thing you need to do is to setup the ticker process on the database where write is performed. The ticker creates sync events so running it with shorter intervals will reduce latency. My configuration file looks like this:
ticker_write.ini

[pgqadm]
job_name = ticker_write
db = dbname=write
# how often to run maintenance [minutes]
maint_delay_min = 1
# how often to check for activity [secs]
loop_delay = 0.1
logfile = %(job_name)s.log
pidfile = %(job_name)s.pid
use_skylog = 0

To start the ticker as a daemon just run:

mbpro:~/temp kristokaiv$ pgqadm.py ticker_write.ini ticker -d

Lets create a simple table that we will replicate from master to read-only’s

mbpro:~/temp kristokaiv$ psql -c "CREATE TABLE users (username text primary key, password text);" write
mbpro:~/temp kristokaiv$ psql -c "CREATE TABLE users (username text primary key, password text);" ro1
mbpro:~/temp kristokaiv$ psql -c "CREATE TABLE users (username text primary key, password text);" ro2

And add it to replication

mbpro:~/temp kristokaiv$ londiste.py replica1.ini provider add users
mbpro:~/temp kristokaiv$ londiste.py replica1.ini subscriber add users
mbpro:~/temp kristokaiv$ londiste.py replica2.ini subscriber add users

After some time the tables should be up to date. Insert a new record in the write database and check if it’s delivered to both read-only db’s.
The functions to insert and select from users table:

CREATE OR REPLACE FUNCTION public.add_user(
    in i_username text,
    in i_password text,
    out status_code text
) AS $$
BEGIN
    PERFORM 1 FROM users WHERE username = i_username;
    IF NOT FOUND THEN
        INSERT INTO users (username, password) VALUES (i_username, i_password);
        status_code = 'OK';
    ELSE
        status_code = 'user exists';
    END IF;
    RETURN;
END; $$ LANGUAGE plpgsql SECURITY DEFINER;

GRANT EXECUTE ON FUNCTION public.add_user(
    in i_username text,
    in i_password text,
    out status_code text
) TO plproxy;

CREATE OR REPLACE FUNCTION login(
    in i_username text,
    in i_password text,
    out status_code text
) AS $$
BEGIN
    SELECT 'OK' FROM users u WHERE username = i_username AND password = i_password INTO status_code;
    IF NOT FOUND THEN status_code = 'FAILED'; END IF;
    RETURN;
END; $$ LANGUAGE plpgsql SECURITY DEFINER;

GRANT EXECUTE ON FUNCTION login(
    in i_username text,
    in i_password text,
    out status_code text
) TO plproxy;

Just for the comfort of those actually trying to follow these steps, here is how the proxy databases
cluster config:

CREATE OR REPLACE FUNCTION plproxy.get_cluster_partitions (cluster_name text)
RETURNS SETOF text AS $$
BEGIN
   IF cluster_name = 'readonly' THEN
        RETURN NEXT 'host=127.0.0.1 dbname=ro1';
        RETURN NEXT 'host=127.0.0.1 dbname=ro2';
        RETURN;
    ELSIF cluster_name = 'write' THEN
        RETURN NEXT 'host=127.0.0.1 dbname=write';
        RETURN;
    END IF;
    RAISE EXCEPTION 'no such cluster%', cluster_name;
END; $$ LANGUAGE plpgsql SECURITY DEFINER;

CREATE OR REPLACE FUNCTION plproxy.get_cluster_config(
    in cluster_name text,
    out key text,
    out val text)
RETURNS SETOF record AS $$
BEGIN
    RETURN;
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION plproxy.get_cluster_version(cluster_name text) RETURNS int AS $$
    SELECT 1;
$$ LANGUAGE SQL;

The last thing left to do is to create the plproxy function definitions that will redirect the login function calls against read-only databases and add_user calls against write database:

CREATE OR REPLACE FUNCTION public.login(
    in i_username text,
    in i_password text,
    out status_code text
) AS $$
CLUSTER 'readonly'; RUN ON ANY;
$$ LANGUAGE plproxy;

CREATE OR REPLACE FUNCTION public.add_user(
    in i_username text,
    in i_password text,
    out status_code text
) AS $$
CLUSTER 'write';
$$ LANGUAGE plproxy;

This is it, the read-only cluster is ready. Note that even though creating such a read-only cluster seems simple and a quick solution for your performance problems it is not a silver bullet solution. Asynchronous replication often creates more problems than it solves so be careful to replicate only non-timecritical data or guarantee a fallback solution when data is not found (eg. proxy function first checks readonly database and if data is not found looks the data up from write db)

相关文章

• No Related Post

Skype has developed many handy tools for creating a database cluster and this series of posts is intended to shed some light on their rather undocumented features. At the base of it stand’s plproxy. The best way to describe it’s features would be “dblink on steroids”. This short tutorial will explain how to install plproxy, do simple remote database calls and setup a simple horizontally partitioned database cluster.

Partitioning for dummys

Partitioning let’s you distribute the database load and data between multiple database servers.
The principle itself is simple. Let’s say you have one table that contains the users login credentials but the problem is that there are millions of users that daily log in to their account. This of cause creates a lot of load not talking about the huge table it needs for storage. First we need a criteria based on which we choose what server contains what data. We could do this by the usernames first character. Users from a-j go to first server and usernames beginning with k-z go to the second server. It does work but probably one of the servers gets more load than the other. The most common option is to choose the partition based on the hash of the primary key value, in our case the username. Using a hashing function will distribute the users between servers very evenly. What you need to know about hashing is that hash function basically calculates a number based on any given input it can handle:

select hashtext('kristokaiv1') = 1116512480
select hashtext('kristokaiv2') = 1440348351
select hashtext('kristokaiv3') = -219299073

How it works internally is beyond the scope of this post.
Now let’s say we have 2 partitions, then we could get the partition number based on the username hash like this

partition nr = hashtext($1) & 1

The & 1 will give us the last bit of the number which can be either 0 or 1 which is the number we will use to choose the partition the user data will be stored in. If it’s 0 the data goes to partition 0 and if it’s one the data goes to partition 1

select hashtext('kristokaiv1') & 1 = 0 -> partition 0
select hashtext('kristokaiv2') & 1 = 1 -> partition 1
select hashtext('kristokaiv3') & 1 = 1 -> partition 1

How plproxy works

The concept itself is rather simple – plproxy is a new language created inside the PostgreSQL database that enables to make remote database calls exactly as you do with dblink. The syntax is really straightforward – the following statement creates a new plproxy function in the database that when run will connect to the database remotedb, execute the function get_user_email(text) and return the results.

localdb=#
CREATE FUNCTION get_user_email(username text) RETURNS text AS $$
    CONNECT 'dbname=remotedb host=123.456.123.21 user=myuser';
$$ LANGUAGE plproxy;

Lets create a dummy function in the remotedb that will respond to the call

remotedb=#
create function get_user_email(text)
returns text as $$
    select 'me@somewhere.com'::text;
$$ language sql;

On execution we will see exactly the same results as we would when executing the query on remotedb

localdb=#
select * from get_user_email('tere');
get_user_email
------------------
me@somewhere.com
(1 row)

Of course this is just a really simple example and i will get back to the more complex syntax later, let’s first take a look on how to install the plproxy language.

Installing plproxy

Plproxy can be downloaded from http://pgfoundry.org/projects/plproxy/ but i strongly suggest you get the newest version from the pgfoundry CVS, instructions how to set it up are here. You have to have the PostgreSQL developement environment installed and the folder where the PostgreSQL configuration info tool (pg_config) is needs to be in included in your $PATH variable. If those prerequisites are met then the installation is simple:

$ make
$ make install
$ make installcheck

If you don’t manage to get it working by yourself there is always the mailing list to help you get started.
The final step is to install the language into the database, this can’t be done as for other languages (createlang utility) instead you have to execute the plproxy.sql file that will create the language call handler. locate plproxy.sql is how i found it but it should be somewhere under contrib.

$ psql -f /usr/local/pgsql/share/contrib/plproxy.sql queries
CREATE FUNCTION
CREATE LANGUAGE

Now everything should be done and you can test the setup with the simple plproxy function in the syntax example.

Setting up our first cluster

Let’s create a simple cluster that consists of 3 databases (in my example they are all running on the same PostgreSQL instance). One proxy database called queries and 2 partitions queries_0000 and queries_0001. Horizontal partitioning is done based on username, It’s the most common way for partitioning as most of the data in the database is usually user related eg. users login, users orders, users payments, users settings…

The database cluster setup is stored inside plpgsql functions that plproxy calls.
There are 3 functions that you _MUST_ create for the cluster configuration to work properly. So let’s create them on the proxy database “queries”.

1) plproxy.get_cluster_version(cluster_name text)
This function called on each request and is used to determine if the configuration for a cluster has been changed, if the version number it returns is higher than the cached version number partitions configuration is reloaded. Let’s start with the first version of our configuration like this:

CREATE OR REPLACE FUNCTION plproxy.get_cluster_version(cluster_name text) RETURNS int AS $$
BEGIN
IF cluster_name = 'queries' THEN
RETURN 1;
END IF;
END;
$$ LANGUAGE plpgsql;

2) plproxy.get_cluster_partitions(cluster_name text)
Function should return the connection strings for all partitions in the correct order.
Because of some unreasonable limitation the total count must be power of 2. This is a unreasonable limitation that can easily be overcome but let’s discuss this in another post.

CREATE OR REPLACE FUNCTION plproxy.get_cluster_partitions(cluster_name text) RETURNS SETOF text AS $$
BEGIN
IF cluster_name = 'queries' THEN
RETURN NEXT 'host=127.0.0.1 dbname=queries_0000';
RETURN NEXT 'host=127.0.0.1 dbname=queries_0001';
RETURN;
END IF;
RAISE EXCEPTION 'no such cluster: %', cluster_name;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

If postgres username is not specified in the connection string the name of CURRENT_USER will be used. As plproxy does not know any passwords, the partition databases should trust connections from the proxy database.

3) plproxy.get_cluster_config(cluster_name text)
This is the equivalent of an init file. It should return the configuration parameters as key – value pairs. All of them are optional but you still need the dummy placeholder function:

CREATE OR REPLACE FUNCTION plproxy.get_cluster_config (cluster_name text, out key text, out val text)
RETURNS SETOF record AS $$
BEGIN
RETURN;
END;
$$ LANGUAGE plpgsql;

The details of configuration parameters and what they do can be found in the plproxy documentation.

Now the setup is complete and we can start playing around with our new cluster.
Let’s create a new table to store usernames on both partitions

#queries_0000=# CREATE TABLE users (username text PRIMARY KEY);
#queries_0001=# CREATE TABLE users (username text PRIMARY KEY);

Also we must create a new function that is used to insert new usernames into the table:

CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS text AS $$
BEGIN
    PERFORM 1 FROM users WHERE username = i_username;
    IF NOT FOUND THEN
        INSERT INTO users (username) VALUES (i_username);
        RETURN 'user created';
    ELSE
        RETURN 'user already exists';
    END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

Now let’s create the proxy function on the proxy database that will call the partitions

queries=#
CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS TEXT AS $$
    CLUSTER 'queries'; RUN ON hashtext(i_username);
$$ LANGUAGE plproxy;

Filling the partitions with random data:
SELECT insert_user('user_number_'||generate_series::text) FROM generate_series(1,10000);
Now if we go to the partition databases we will see that both of them are filled
and the distribution is quite even.

queries_0001 count(*) -> 5071
queries_0000 count(*) -> 4930

相关文章

• 2009年09月4日 -- postgresql 分布式查询方法 (0)