好久不看Blog了。
最近都做了什么???啊,搞系统的孩纸,最近在做web page的提取。想想这个风险还是小于支付系统的,哈哈。
大家都知道架构一直是根据需求来的,所以还是那句话,适合的才是最好的。
架构主要还是要考虑是否符合业务需求,架构可扩展性,复杂度。。
最近了解了一下颠覆常规的的数据分片的知识,后来发现已经很普遍了。这种sharding system,这种思想不同于曾经用于的sharding system, 比如Vertical partitioning, Key-Based partitioning,Directory-based partitioning。这种Url-Based sharding system的好处是,即使在架构开始阶段你没有充分的考虑到未来系统的扩展性,在未来做扩展时也不必重新架构,更改分片系统。
提到了4点,系统的架构主要是为4个目标服务的:
当然这里主要考虑分片这。
1. 处理持续增长的数据能力.
2. 成比例的控制软件复杂度的增量。(主要是是否有必要在数据积累到一定程度,对数据分片系统进行重构,最好的想法是,横向就可以解决这个问题,通过添加hardware)。
3. 支持多种数据分片方案。
4. 便于程序员理解
主要思想是这样的:
说在前面,我是小白,针对java(我只了解java和c,c++),在和数据库方面交互,如果没有充分的使用orm,使用硬编码,那系统。。。
1. 进行data和 entity的联系。就是面向对象,建立一个java bean。
2. 例子:
针对customer,建议个entity。某个db负责存储customer的信息,OK。如果你想查看某个customer的信息,那只需将客户信息构建成url形式:
customer://1234
ps:
在底层的数据访问中,以前是这样的:(ps:以后会提到,牛逼的架构会在同一sql和nosql的访问,至少在dal层你是这样感觉的)
$Connection = new_db_connection("host", "port", "dbname");
$statement = $connection->prepare($sql, $params);
$result = $statement->execute();
现在是这样的
$connection = new_db_connection("customer://1234");
$statement = $connection->prepare($sql, $param);
$result = statement->execute();
2. sharding system中要有一个map机制:
customer://1234 -> mysql://hostname:port/dbnam
所以,每个系统只要有一个恰当的映射就可以了。
customer://1234 (id)
forums://master (vertical)
log://January/2014(date)