出家如初，成佛有余» 架构 http://www.yeeach.com 专注电子商务领域，关注无线互联网，关注新媒体；Yeeach.com用于记录我技术生涯的点滴 Sun, 25 Jul 2010 10:30:31 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 distributed key-value store 杂思 http://www.yeeach.com/2009/09/27/distributed-key-value-store-%e6%9d%82%e6%80%9d/ http://www.yeeach.com/2009/09/27/distributed-key-value-store-%e6%9d%82%e6%80%9d/#comments Sat, 26 Sep 2009 17:20:57 +0000 chuanliang http://www.yeeach.com/2009/09/27/distributed-key-value-store-%e6%9d%82%e6%80%9d/     distributed key-value  store是当下比较流行的话题，尤其在构建诸如搜索引擎、IM、P2P、游戏服务器、SNS等大型互联网应用以及提供云计算服务的时候，怎样保证系统在海量数据环境下的高性能、高可靠性、高扩展性、高可用性、低成本成为所有系统架构们挖苦心思考虑的重点，而怎样解决数据库服务器的性能瓶颈是最大的挑战。

    按照分布式领域的CAP理论（Consistency、Availability、Tolerance to network Partitions这三部分在任何系统架构实现时只可能同时满足其中二点，没法三者兼顾）来衡量，传统的关系数据库的ACID只满足了Consistency、Availability，因此在Partition tolerance上就很难做得好。另外传统的关系数据库处理海量数据、分布式架构时候在Performance、Scalability、Availability等方面也存在很大的局限性。

    而key-value store更加注重对海量数据存取的性能、分布式、扩展性支持上，并不需要传统关系数据库的一些特征，例如：Schema、事务、完整SQL查询支持等等，因此在分布式环境下的性能相对于传统的关系数据库有较大的提升。当然不同的key-value store根据应用需求的不同，在设计理念并不完全相同，例如以Google BigTable、Amazon Dynamo为例：

    BigTable is a CA system; it is strongly consistent and highly available, but can be unavailable under network partitions.  BigTable has no replication at the database level, rather replication is handled underneath by GFS.

   Dynamo is an AP system; it is highly available, even under network partitions, but eventually consistent.  Data is replicated within a single cluster, so even under partitions most data is available, however one node’s latest version might not match that of another, so every reader is only guaranteed to see every write eventually.                                                              

          cap理论,cap theorem,base  

    其实使用key-value store的历史已经很久了，以前在做电信计费时候的Radius服务器就采用Berkeley DB这样经典的key-value store作为用户数据库，只不过早期使用这样的key-value store关注的重点主要在性能上，对于分布式、海量数据的处理并非考虑的重点。

1、key-value store与RDBMS的区别

摘自:Is the Relational Database Doomed?

key-value store,rdbms,distributed hash table

key-value store,rdbms,distributed hash table

key-value store,rdbms,distributed hash table

 

2、一些常用的key-value的开源项目

这些项目的设计思路大多是参考Google BigTable、Amazon Dynamo

    Richard Jones _ Anti-RDBMS A list of distributed key-value stores

除了以上罗列的产品外，还有如下一些产品

Tokyo cabinet

Redis

MongoDB

Oracle Berkeley DB

LightCloud

Lux IO

Drizzle

Flare

其中Tokyo cabinet、Redis、MongoDB各有特色，可以作为项目使用key-value store时候的重点评估对象。

 

3、与工作相关的一些可以使用key-value store的应用场合

    Cache：Memcachedb、Tokyo Tyrant

    网络通信：做IM、P2P时候做单点登录服务器、状态服务器；消息队列服务器（Tokyo Tyrant）

    交易系统：计费系统cdr及预处理后的账单数据；交易系统风控系统（内存数据库,redis）

    日志：服务器访问日志，用于web analytics使用；呼叫中心的呼叫数据；

    爬虫及搜索引擎：爬取页面日志；爬取任务；索引库

    SNS社区及CMS站点：可以大规模应用Tokyo Cabinet+Tokyo Tyrant，结合Solr/Lucene或这样的Sphinx搜索引擎搞定查询问题

    云存储：

4、参考资料

    Brewers CAP Theorem

    Towards Robust Distributed Systems

    CAP Theorem

    Key Value Store List

    Anti-RDBMS: A list of distributed key-value stores

    Database Sharding at Netlog, with MySQL and PHP

© chuanliang for 出家如初，成佛有余, 2009. | Permalink | 2 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 技术相关.

]]> http://www.yeeach.com/2009/09/27/distributed-key-value-store-%e6%9d%82%e6%80%9d/feed/ 2 平台各系统统计分析系统设计方案 http://www.yeeach.com/2008/05/07/%e5%b9%b3%e5%8f%b0%e5%90%84%e7%b3%bb%e7%bb%9f%e7%bb%9f%e8%ae%a1%e5%88%86%e6%9e%90%e7%b3%bb%e7%bb%9f%e8%ae%be%e8%ae%a1%e6%96%b9%e6%a1%88/ http://www.yeeach.com/2008/05/07/%e5%b9%b3%e5%8f%b0%e5%90%84%e7%b3%bb%e7%bb%9f%e7%bb%9f%e8%ae%a1%e5%88%86%e6%9e%90%e7%b3%bb%e7%bb%9f%e8%ae%be%e8%ae%a1%e6%96%b9%e6%a1%88/#comments Wed, 07 May 2008 01:48:37 +0000 chuanliang http://www.yeeach.com/2008/05/07/%e5%b9%b3%e5%8f%b0%e5%90%84%e7%b3%bb%e7%bb%9f%e7%bb%9f%e8%ae%a1%e5%88%86%e6%9e%90%e7%b3%bb%e7%bb%9f%e8%ae%be%e8%ae%a1%e6%96%b9%e6%a1%88/  

    随着公司业务的快速开拓，数据库数据量极速增长，一些关键数据表的数据没有备份归档策略，在统计分析策略上也没有进行相应的优化，系统将会很不稳定，最终影响日常交易、运营业务运行，同时也对新业务的开展造成了严重制约（例如商家查询和报表）。特编写手软平台所有系统进行统计分析的基本设计规范，作为各新系统建设的建设。

    基本指导原则：

  • 分离统计库（olap）和交易库（oltp）
  • 建立相对完备的数据归档、预处理机制，定期将统计数据归档到统计分析中间表
  • 统计分析数据从中间表读取，避免从oltp都实时统计查询

1. 目前系统主要的问题及经验教训

    性能问题主要来自于后台统计、结算等操作，这些sql的代价非常庞大，也是系统性能瓶颈所在。

    系统缺少老数据的归档机制，导致一些关键表的数据量一直在增长，导致日常查询操作压力较大，影响所有查询效率。

    系统统计分析和查询操作没有预处理机制，形成中间表或临时表，应用直接查询原始表，导致数据库压力过大。

    存在查询按钮重复点击，导致同一查询同时执行，很容易导致数据库负载达到峰值。

    查询页面需求不明确，存在一些不必要的信息，导致关联查询的复杂性。应用中存在无条件的查询语句。

    业务高负载时，集中在白天。这个时段的并发查询导致整体性能下降。

2. 新系统统计分析设计基本方法

基本方法：

  • 数据归档

    对历史数据定时归档，降低在线表各表的数据量。历史数据不进行删除操作。

    用脚本定时完成统计分析数据或查询数据入临时表或中间表，降低查询的压力。

  • 数据库优化和应用设计优化（数据库扁平化）

    对数据采用分库、分区、分表方式来处理大数据处理。

    对数据库设计优化。

    对应用系统优化。

3. 数据库分离基本方法

3.1. 数据归档原则

1) 目的：

    归档包括对交易数据的归档，也包括对历史数据的归档。

  • 交易数据的归档：

    将业务表与历史数据设计成不同的表来存储数据。业务表中只保留正在处理的业务数据。业务表中保留一段时间后（视数据量和实际需求），系统定时进行归档或人工在界面操作进行归档，将业务数据转移至历史数据表。

  • 历史数据的归档

    按照统计分析或大数据量查询要求，通过定时脚本对历史数据进行归档处理以降低统计查询的数据量。

    典型场景：对历史数据，按照日报表、周报表、月报表、年报表要求进行定时处理，形成中间数据表，前台查询时候直接从中间数据表中查询数据。

2) 原因：

    对于历史交易数据如果仍然存在在交易表中不进行清理操作，随着交易数据量的增长，将影响系统业务处理性能。

3) 备注：

    归档策略依赖于统计分析、定时脚本、查询等需求。

    存放时间：电信系统一般保存6个月数据。

    历史数据归档查询：

3.2. 数据分库原则

1) 目的：

    数据库分库原则分离交易库和分析库。

2) 原因：

    OLTP系统管理当前数据，侧重于事务和查询处理，在设计上遵循E-R模型。

    OLAP系统管理大量历史数据,提供汇总和聚集机制.，用于数据统计分析和挖掘，在设计上采用星型或雪花模型和面向主题的数据库设计。

    目前系统并没有区分这两种系统，导致进行统计分析和大数据量查询时候对数据库资源有较大的占用。

3) OLAP与OLTP同步策略

    采用mysql的Master-Slave模式来实现。交易库为Master，统计库为Slave。除对统计报表相关的表进行操作外，对统计库（Slave库）的交易数据不进行任何insert、update、delete操作，需要更新相关数据，只能操作Master库。

3.3. 数据分区原则

目的：

    为了使用户的大量的数据在读写操作和查询中速度更快，利用数据库系统提供的对表和索引进行分区的技术，以改善大型应用系统的性能。

    使用分区的优点：

  • 增强可用性：如果表的某个分区出现故障，表在其他分区的数据仍然可用；
  • 维护方便：如果表的某个分区出现故障，需要修复数据，只修复该分区即可
  • 均衡I/O：可以把不同的分区映射到磁盘以平衡I/O，改善整个系统性能；
  • 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索速度。

3.4. 数据分表原则

目的：

    把若干个存储相同类型数据的表分成几个表分表存储，在提取数据的时候，不同的用户访问不同的表，互不冲突，减少锁表的几率。

可通过一个原始目标的ID或者名称通过一定的hash算法计算出数据存储表的表名，然后访问相应的表。

3.5. 统计分析处理原则

    写脚本自动生成统计分析结果，存入结果表中，提供查询。

3.6. 数据库操作日志拦截

目的：

    利用hibernate等的interceptor机制，拦截下数据库操作日志，以便于跟踪sql语句及性能调试。

    正常情况下，拦截操作日志为关闭状态。

3.7. 中间表、临时表、视图

目的

    利用中间表和临时表或视图机制，降低统计分析或查询过程中过大sql的操作，造成对数据库排序区过多占用，提高查询速度。

4. eSales系统核心统计策略

    通过Quartz来实现每日凌晨及每月1号凌晨业务量较小时候定时调度统计分析程序，汇总每日的销售明细等统计数据，形成“产品日销售统计”、“产品月销售统计”、“销售员日销售统计”、“销售员月销售统计”几个核心的统计中间表。

eSales系统统计分析

 

© chuanliang for 出家如初，成佛有余, 2008. | Permalink | No comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 技术相关.

]]> http://www.yeeach.com/2008/05/07/%e5%b9%b3%e5%8f%b0%e5%90%84%e7%b3%bb%e7%bb%9f%e7%bb%9f%e8%ae%a1%e5%88%86%e6%9e%90%e7%b3%bb%e7%bb%9f%e8%ae%be%e8%ae%a1%e6%96%b9%e6%a1%88/feed/ 0 电子商务系统之网络管理 http://www.yeeach.com/2007/11/10/%e7%94%b5%e5%ad%90%e5%95%86%e5%8a%a1%e7%b3%bb%e7%bb%9f%e4%b9%8b%e7%bd%91%e7%bb%9c%e7%ae%a1%e7%90%86/ http://www.yeeach.com/2007/11/10/%e7%94%b5%e5%ad%90%e5%95%86%e5%8a%a1%e7%b3%bb%e7%bb%9f%e4%b9%8b%e7%bd%91%e7%bb%9c%e7%ae%a1%e7%90%86/#comments Sat, 10 Nov 2007 03:37:05 +0000 chuan liang http://www.yeeach.com/2007/11/10/%e7%94%b5%e5%ad%90%e5%95%86%e5%8a%a1%e7%b3%bb%e7%bb%9f%e4%b9%8b%e7%bd%91%e7%bb%9c%e7%ae%a1%e7%90%86/   对于以“软件作为服务”的互联网公司而言，系统的可靠性、可用性、性能、安全性是互联网公司的核心竞争力之一，很大程度决定了服务质量、客户满意度。为了提升客户的服务满意度，要建立一种“主动维护”的综合运维机制，对网络及系统进行定期检测和实时监控，在用户还没有感知的情况下，及时发现网络的故障隐患并将其排除，从而保障电子商务系统的长期安全稳定运行，为客户提供满意的SLA服务。可以说有效的网络管理已不仅局限于网络层，它还面对着业务管理的需求，甚至影响着商业运行的方方面面。

  但是随着互联网公司的网络规模不断地扩展、网络类型逐渐增多，网络管理系统的作用越来越重要、也越来越复杂，数据配置、告警、统计和检测手段的不足直接影响了运维效率，排除网络故障、软件系统故障更加困难、维护成本也急剧上升，单靠日常的手工方式进行维护已经不能满足业务发展要求。通过网管系统对系统进行“主动维护”可以保证网管系统能够7×24小时对全网进行监控维护 ，满足系统高可用性、高可靠性、高性能、高安全性、高扩展性要求，同时有效降低运营成本，及时发现并排查故障，有效提升服务质量。

 

1、电子商务系统对网络管理的要求：

第一、管理对象的接入类型及系统的管理功能是水平可扩展的，随着被管理网络类型的多样化，网管系统具备管理各种类型网络的能力，而且功能实现也能够逐渐扩展。

第二、系统在处理能力方面要具有垂直可扩性。随着网络规模的不断扩大，网管系统必须满足能够管理始终处于增长态的网络的要求

第三、系统必须能够通过权限的划分，保证不同层次、不同地域的用户拥有不同层次的功能。

第四、网管系统应当具有较好的软件架构，提供较好的插件式扩展机制，以方便定制开发。对于电子商务系统核心业务功能的监控应该作为核心业务需求进行设计和开发，在规范上应当遵循网管系统的管理接口，以方便系统的集中统一管理。

第五：满足提供标准化的接口，包括JMX、SNMP等。

网管系统的功能分类：

  • 配置管理
  • 性能管理
  • 失效管理
  • 计费管理
  • 安全管理

2、开源网络管理系统解决方案

2.1、开源的网络管理平台：

Hyperic ：http://www.hyperic.com/

Zenoss：http://zenoss.com/

GroundWorks：http://www.groundworkopensource.com/

OpenQRM：http://openqrm.org/

Nagios：http://nagios.org/

OpenNMS：http://www.opennms.org/

Zabbix：  http://www.zabbix.org/

以上几个提供功能相对完整的综合解决方案，也即所谓的“企业级网管软件”，其他的参考10 Great Open Source Network Tools

最佳选择：Hyperic

Hyperic HQ功能

Hyperic HQ 可以监控和管理：

  • 操作系统: AIX, HP/UX, Linux, Solaris, Windows, Mac OSX, FreeBSD
  • Web服务器: Apache, Microsoft IIS, Sun ONE Web Server
  • 应用服务器: BEA WebLogic, IBM WebSphere, JBoss, Apache Geronimo, Macromedia ColdFusion, Macromedia JRun, Microsoft .NET Runtime, Novell Silverstream, Tomcat, Caucho Resin
  • 数据库: IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Sybase Adaptive Server
  • 消息中间件: ActiveMQ，Weblogic MQ
  • 微软的产品: MS Exchange，MS ActiveDirectory，.NET
  • 虚拟产品: VMWare, Citrix Metaframe
  • 应用平台: LAMP, LAM-J, J2EE, MX4J
  • 其他技术网络设备交换机，路由器等。
Hyperic HQ架构　

 

diagram-server-arch-small

diagram-agent-arch-small

2.2、开源备份管理软件

http://www.bacula.org/

http://www.amanda.org/

http://www.cleversafe.org/

最佳选择：bacula

 

3、电子商务系统建设网络管理功能思考

系统的可监控性、可维护性、易部署性是电子商务系统建设必须考虑的核心功能之一，必须提前未雨绸缪，而不是上线之后再补充和完善。

基本原则：必须实现系统的集中统一管理、数据统一备份管理。

基本思路：选定一个相对完整的管理平台，然后在此基础上进行二次开发。在系统需求分析时候就必须把对核心功能的网管监控需求、系统的数据归档及备份需求体现到核心业务需求中去，而不是作为可有可无的功能。在架构设计时候就必须对核心功能设计网管接口、对系统数据的备份归档进行统一设计考虑。这样后期运营维护时候，才能够及时发现系统故障，降低系统的风险点。所有系统的管理监控功能、数据备份应当遵循网管系统、备份系统的接口要求。

使用 vs. 开发：网管系统不应当只是停留在监控数据库、操作系统等使用层面，必须让网管系统帮助把核心业务系统的功能管理起来。核心系统的网管接口由程序员完成，但与网管系统的融合及二次开发可以考虑让系统人员来做，这样可以帮助系统人员提升其职业技能，也可以让程序员集中精力完成业务功能的实现。

怎样利用网管系统来简化软件上线部署统一的分发管理、部署管理？

 

4、参考资料

https://www.theforbingroup.com/files/TFG%20-%20Monitoring%20Whitepaper.pdf

http://www.itmanagement.com/features/10-open-source-network-tools-052407/

http://redmonk.com/cote/2007/01/16/open-platforms-in-systems-management/

http://www.openxtra.co.uk/blog/network-managements-new-wave/

 

Technorati 标签: , , , , ,

© chuan liang for 出家如初，成佛有余, 2007. | Permalink | No comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under 技术相关, 电子商务.

]]> http://www.yeeach.com/2007/11/10/%e7%94%b5%e5%ad%90%e5%95%86%e5%8a%a1%e7%b3%bb%e7%bb%9f%e4%b9%8b%e7%bd%91%e7%bb%9c%e7%ae%a1%e7%90%86/feed/ 0