数据存储设计方案
㈠ 数据仓库与ODS的区别，数据仓库和ODS并存方案
一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。先大概列一下互联网行业数据仓库、数据平台的用途：
整合公司所有业务数据，建立统一的数据中心；
提供各种报表，有给高层的，有给各个业务的；
为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；
为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；
分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；
开发数据产品，直接或间接为公司盈利；
建设开放数据平台，开放公司数据；
。。。。。。
上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；
其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；
建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。
整体架构下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：
逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看：
数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多：
网站日志：
作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，
一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；
业务数据库：
业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapRece来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。
当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。
来自于Ftp/Http的数据源：
有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；
其他数据源：
比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；
数据存储与分析毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapRece要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；
当然，使用Hadoop框架自然而然也提供了MapRece接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapRece来做分析与计算；Spark是这两年非常火的，经过实践，它的性能的确比MapRece要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》
实时计算部分，后面单独说。
数据共享这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；
前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据；和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。
另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。
数据应用
业务产品
业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；
报表
同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；
即席查询
即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；
这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。
即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。
当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。
OLAP
目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；
这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；
比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。
其它数据接口
这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。
实时计算现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。
我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。
做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。
任务调度与监控在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；
这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。
前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。
总结在我看来架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。
㈡ 谁知道数据库优化设计方案有哪些
本文首先讨论了基于第三范式的数据库表的基本设计，着重论述了建立主键和索引的策略和方案，然后从数据库表的扩展设计和库表对象的放置等角度概述了数据库管理系统的优化方案。
关键词： 优化（Optimizing） 第三范式（3NF） 冗余数据（Rendant Data） 索引（Index） 数据分割（Data Partitioning） 对象放置（Object Placement）
1 引言
数据库优化的目标无非是避免磁盘I/O瓶颈、减少CPU利用率和减少资源竞争。为了便于读者阅读和理解，笔者参阅了Sybase、Informix和Oracle等大型数据库系统参考资料，基于多年的工程实践经验，从基本表设计、扩展设计和数据库表对象放置等角度进行讨论，着重讨论了如何避免磁盘I/O瓶颈和减少资源竞争，相信读者会一目了然。
2 基于第三范式的基本表设计
在基于表驱动的信息管理系统（MIS）中，基本表的设计规范是第三范式（3NF）。第三范式的基本特征是非主键属性只依赖于主键属性。基于第三范式的数据库表设计具有很多优点：一是消除了冗余数据，节省了磁盘存储空间；二是有良好的数据完整性限制，即基于主外键的参照完整限制和基于主键的实体完整性限制，这使得数据容易维护，也容易移植和更新；三是数据的可逆性好，在做连接（Join）查询或者合并表时不遗漏、也不重复；四是因消除了冗余数据（冗余列），在查询（Select）时每个数据页存的数据行就多，这样就有效地减少了逻辑I/O，每个Cash存的页面就多，也减少物理I/O；五是对大多数事务(Transaction)而言，运行性能好；六是物理设计(Physical Design)的机动性较大，能满足日益增长的用户需求。
在基本表设计中，表的主键、外键、索引设计占有非常重要的地位，但系统设计人员往往只注重于满足用户要求，而没有从系统优化的高度来认识和重视它们。实际上，它们与系统的运行性能密切相关。现在从系统数据库优化角度讨论这些基本概念及其重要意义：
（1）主键(Primary Key)：主键被用于复杂的SQL语句时，频繁地在数据访问中被用到。一个表只有一个主键。主键应该有固定值（不能为Null或缺省值，要有相对稳定性），不含代码信息，易访问。把常用（众所周知）的列作为主键才有意义。短主键最佳（小于25bytes），主键的长短影响索引的大小，索引的大小影响索引页的大小，从而影响磁盘I/O。主键分为自然主键和人为主键。自然主键由实体的属性构成，自然主键可以是复合性的，在形成复合主键时，主键列不能太多，复合主键使得Join*作复杂化、也增加了外键表的大小。人为主键是，在没有合适的自然属性键、或自然属性复杂或灵敏度高时，人为形成的。人为主键一般是整型值（满足最小化要求），没有实际意义，也略微增加了表的大小；但减少了把它作为外键的表的大小。
（2）外键（Foreign Key）：外键的作用是建立关系型数据库中表之间的关系（参照完整性），主键只能从独立的实体迁移到非独立的实体，成为后者的一个属性，被称为外键。
（3）索引(Index)：利用索引优化系统性能是显而易见的，对所有常用于查询中的Where子句的列和所有用于排序的列创建索引，可以避免整表扫描或访问，在不改变表的物理结构的情况下，直接访问特定的数据列，这样减少数据存取时间；利用索引可以优化或排除耗时的分类*作；把数据分散到不同的页面上，就分散了插入的数据；主键自动建立了唯一索引，因此唯一索引也能确保数据的唯一性（即实体完整性）；索引码越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代价：有空间开销，建立它也要花费时间，在进行Insert、Delete和Update*作时，也有维护代价。索引有两种：聚族索引和非聚族索引。一个表只能有一个聚族索引，可有多个非聚族索引。使用聚族索引查询数据要比使用非聚族索引快。在建索引前，应利用数据库系统函数估算索引的大小。
① 聚族索引（Clustered Index）：聚族索引的数据页按物理有序储存，占用空间小。选择策略是，被用于Where子句的列：包括范围查询、模糊查询或高度重复的列（连续磁盘扫描）；被用于连接Join*作的列；被用于Order by和Group by子句的列。聚族索引不利于插入*作，另外没有必要用主键建聚族索引。
② 非聚族索引（Nonclustered Index）：与聚族索引相比，占用空间大，而且效率低。选择策略是，被用于Where子句的列：包括范围查询、模糊查询（在没有聚族索引时）、主键或外键列、点（指针类）或小范围（返回的结果域小于整表数据的20%）查询；被用于连接Join*作的列、主键列（范围查询）；被用于Order by和Group by子句的列；需要被覆盖的列。对只读表建多个非聚族索引有利。索引也有其弊端，一是创建索引要耗费时间，二是索引要占有大量磁盘空间，三是增加了维护代价（在修改带索引的数据列时索引会减缓修改速度）。那么，在哪种情况下不建索引呢？对于小表（数据小于5页）、小到中表（不直接访问单行数据或结果集不用排序）、单值域（返回值密集）、索引列值太长（大于20bitys）、容易变化的列、高度重复的列、Null值列，对没有被用于Where子语句和Join查询的列都不能建索引。另外，对主要用于数据录入的，尽可能少建索引。当然，也要防止建立无效索引，当Where语句中多于5个条件时，维护索引的开销大于索引的效益，这时，建立临时表存储有关数据更有效。
批量导入数据时的注意事项：在实际应用中，大批量的计算（如电信话单计费）用C语言程序做，这种基于主外键关系数据计算而得的批量数据（文本文件），可利用系统的自身功能函数（如Sybase的BCP命令）快速批量导入，在导入数据库表时，可先删除相应库表的索引，这有利于加快导入速度，减少导入时间。在导入后再重建索引以便优化查询。
（4）锁：锁是并行处理的重要机制，能保持数据并发的一致性，即按事务进行处理；系统利用锁，保证数据完整性。因此，我们避免不了死锁，但在设计时可以充分考虑如何避免长事务，减少排它锁时间，减少在事务中与用户的交互，杜绝让用户控制事务的长短；要避免批量数据同时执行，尤其是耗时并用到相同的数据表。锁的征用：一个表同时只能有一个排它锁，一个用户用时，其它用户在等待。若用户数增加，则Server的性能下降，出现“假死”现象。如何避免死锁呢？从页级锁到行级锁，减少了锁征用；给小表增加无效记录，从页级锁到行级锁没有影响，若在同一页内竞争有影响，可选择合适的聚族索引把数据分配到不同的页面；创建冗余表；保持事务简短；同一批处理应该没有网络交互。
（5）查询优化规则：在访问数据库表的数据(Access Data)时，要尽可能避免排序（Sort）、连接(Join)和相关子查询*作。经验告诉我们，在优化查询时，必须做到：
① 尽可能少的行；
② 避免排序或为尽可能少的行排序，若要做大量数据排序，最好将相关数据放在临时表中*作；用简单的键（列）排序，如整型或短字符串排序；
③ 避免表内的相关子查询；
④ 避免在Where子句中使用复杂的表达式或非起始的子字符串、用长字符串连接；
⑤ 在Where子句中多使用“与”（And）连接，少使用“或”(Or)连接；
⑥ 利用临时数据库。在查询多表、有多个连接、查询复杂、数据要过滤时，可以建临时表（索引）以减少I/O。但缺点是增加了空间开销。
除非每个列都有索引支持，否则在有连接的查询时分别找出两个动态索引，放在工作表中重新排序。
3 基本表扩展设计
基于第三范式设计的库表虽然有其优越性（见本文第一部分），然而在实际应用中有时不利于系统运行性能的优化：如需要部分数据时而要扫描整表，许多过程同时竞争同一数据，反复用相同行计算相同的结果，过程从多表获取数据时引发大量的连接*作，当数据来源于多表时的连接*作；这都消耗了磁盘I/O和CPU时间。
尤其在遇到下列情形时，我们要对基本表进行扩展设计：许多过程要频繁访问一个表、子集数据访问、重复计算和冗余数据，有时用户要求一些过程优先或低的响应时间。
如何避免这些不利因素呢？根据访问的频繁程度对相关表进行分割处理、存储冗余数据、存储衍生列、合并相关表处理，这些都是克服这些不利因素和优化系统运行的有效途径。
3.1 分割表或储存冗余数据
分割表分为水平分割表和垂直分割表两种。分割表增加了维护数据完整性的代价。
水平分割表：一种是当多个过程频繁访问数据表的不同行时，水平分割表，并消除新表中的冗余数据列；若个别过程要访问整个数据，则要用连接*作，这也无妨分割表；典型案例是电信话单按月分割存放。另一种是当主要过程要重复访问部分行时，最好将被重复访问的这些行单独形成子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但在分割表以后，增加了维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。
垂直分割表（不破坏第三范式），一种是当多个过程频繁访问表的不同列时，可将表垂直分成几个表，减少磁盘I/O（每行的数据列少，每页存的数据行就多，相应占用的页就少），更新时不必考虑锁，没有冗余数据。缺点是要在插入或删除数据时要考虑数据的完整性，用存储过程维护。另一种是当主要过程反复访问部分列时，最好将这部分被频繁访问的列数据单独存为一个子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但这增加了重叠列的维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。垂直分割表可以达到最大化利用Cache的目的。
总之，为主要过程分割表的方法适用于：各个过程需要表的不联结的子集，各个过程需要表的子集，访问频率高的主要过程不需要整表。在主要的、频繁访问的主表需要表的子集而其它主要频繁访问的过程需要整表时则产生冗余子集表。
注意，在分割表以后，要考虑重新建立索引。
3.2 存储衍生数据
对一些要做大量重复性计算的过程而言，若重复计算过程得到的结果相同（源列数据稳定，因此计算结果也不变），或计算牵扯多行数据需额外的磁盘I/O开销，或计算复杂需要大量的CPU时间，就考虑存储计算结果（冗余储存）。现予以分类说明：
若在一行内重复计算，就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器更新这个新列。
若对表按类进行重复计算，就增加新表（一般而言，存放类和结果两列就可以了）存储相关结果。但若参与计算的列被更新时，就必须要用触发器立即更新、或存储过程或应用代码批量更新这个新表。
若对多行进行重复性计算（如排名次），就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器或存储过程更新这个新列。
总之，存储冗余数据有利于加快访问速度；但违反了第三范式，这会增加维护数据完整性的代价，必须用触发器立即更新、或存储过程或应用代码批量更新，以维护数据的完整性。
3.3 消除昂贵结合
对于频繁同时访问多表的一些主要过程，考虑在主表内存储冗余数据，即存储冗余列或衍生列（它不依赖于主键），但破坏了第三范式，也增加了维护难度。在源表的相关列发生变化时，必须要用触发器或存储过程更新这个冗余列。当主要过程总同时访问两个表时可以合并表，这样可以减少磁盘I/O*作，但破坏了第三范式，也增加了维护难度。对父子表和1：1关系表合并方法不同：合并父子表后，产生冗余表；合并1：1关系表后，在表内产生冗余数据。
4 数据库对象的放置策略
数据库对象的放置策略是均匀地把数据分布在系统的磁盘中，平衡I/O访问，避免I/O瓶颈。
⑴ 访问分散到不同的磁盘，即使用户数据尽可能跨越多个设备，多个I/O运转，避免I/O竞争，克服访问瓶颈；分别放置随机访问和连续访问数据。
⑵ 分离系统数据库I/O和应用数据库I/O。把系统审计表和临时库表放在不忙的磁盘上。
⑶ 把事务日志放在单独的磁盘上，减少磁盘I/O开销，这还有利于在障碍后恢复，提高了系统的安全性。
⑷ 把频繁访问的“活性”表放在不同的磁盘上；把频繁用的表、频繁做Join*作的表分别放在单独的磁盘上，甚至把把频繁访问的表的字段放在不同的磁盘上，把访问分散到不同的磁盘上，避免I/O争夺；
⑸ 利用段分离频繁访问的表及其索引（非聚族的）、分离文本和图像数据。段的目的是平衡I/O，避免瓶颈，增加吞吐量，实现并行扫描，提高并发度，最大化磁盘的吞吐量。利用逻辑段功能，分别放置“活性”表及其非聚族索引以平衡I/O。当然最好利用系统的默认段。另外，利用段可以使备份和恢复数据更加灵活，使系统授权更加灵活。
㈢ 在数据库存储结构设计时要考虑哪些因素
第一：各个参数是否对应的一个对象（面向对象编程思想）；
第二：各个参数可能类型和出现的最大长度，之后合理的设计各个字段的最大长度和相应类型；
第三：各个参数中哪些字段具有唯一性，考虑作为主键或者是外键来进行表关联；
第四：根据数据量的大小来考虑是否需要进行分区处理；
第五：哪些字段是不经常便跟字段，可以考虑进行多张表的存储来节省存储空间（可能影响查询修改效率）
㈣ 急求一份管理信息系统课程设计
1成绩管理系统------分析报告(不知如何贴数据流程图之类的到这里，所以把相关图片贴到空间里啦)（另：数据字典是表格形式啦，贴来这里就变了。）
一 . 引言
1.系统名称：学生成绩管理信息系统
2.开发目标：开发出一个操作简便，界面友好，灵活实用，安全可靠的学生成绩管理信息系统。
该系统的开发以教务管理人员和任课教师服务为对象，能够提高学校对学生成绩的统计分析效率，减轻教务管理人员对学生成绩管理和统计的负担，提高学校对学生成绩的规范化管理。
该成绩管理系统能够及时对学生成绩进行收集整理，使学校相关部门及时获取可靠的学生成绩信息，便于管理。
3.主要功能：
本系统的使用者根据其使用者------教务处管理人员和任课教师-----可分为以下几方面：
（1）教务处管理人员登陆后，进入教务人员管理模块，可以进行个人信息查询，教师住处职称工资情况的查询，学生信息查询，成绩查询以及退出系统等操作。
（2）教师登陆教师管理子系统，要能够对学生成绩进行权限范围内的录入、添加、修改、删除、查询；查询教师信息、更改个人登陆密码、修改个人信息等；
（3）学生单科成绩、全科成绩的总分、平均分，最高分、最低分，排序等计算和统计实现自动化；可以按班级、按个人进行信息查询；信息可以发布到网络，以实现数据共享；
（4）能够自动进行录入错误检查
4.开发背景
每个学校都需要在学期末进行期末考试成绩的统计分析工作，而这些工作都必须在考试结束后近一个星期的时间内完成。大量的成绩数据的统计分析工作如果只靠人工来完成，费时费力，还容易出错。随着计算机技术的飞速发展，计算机在日常管理应用中迅速普及，利用计算机进行学生成绩管理势在必行。因此需开发出一个能满足学校进行成绩的录入，统计，查询，报表和打印等需求的、功能完善、安全可靠、迅速简便的成绩管理信息系统。
二. 系统目标和开发的可行性
1.系统目标：
(1)为教务处管理人员提供各学期、各年级、各班级学生的基本成绩信息，以作为其进行成绩汇总，分析和考绩和总结评比的依据。
(2)方便各任课教师记录，统计所带班学生成绩，提高工作效率，减轻负担；总结经验，提高教学质量。
(3)实现快速方便地处理大量成绩数据信息，完成成绩的录入、添加、修改、删除、统计、查询、排序等处理要求。
(4)输出和打印成绩单和各种成绩报表。
2.开发的可行性
(1)系统的名称、功能、目标等已如前所述，此地不再重复。
(2)系统环境以及工具：
A. 软件环境：
用户端：Windows2000，Windows2003，Windows XP
服务器端：WindowsNT/Windows2000及以上操作系统
编程语言：SOL
数据库：Access2003
B 硬件环境：
有高性能的电子计算机、大容量的存贮装置，个人电脑（终端）以及联结起来的网线等，组成信息资源共享的计算机网络，有共享的打印机，扫描仪等等
（3）系统设计原则：
1) 系统运行安全可靠，稳定性好；
2) 系统的可管理性和可维护性好；
3) 系统输入界面友好，操作简便易行，尽量减少用户的输入工作量；
4）允许多种数据输入方式，能实现多种查询，允许进行模糊查询；
5）数据具有规范性，整体性，方便数据之间的比较分析。
（4）系统可行性分析：
A． 技术可行性：系统要求在windows2000以上环境运行，后台数据库采用access2003，使用SOL编程，采用ADO方式连接数据库，这些在目前都是容易实现的。程序将部分需要经常调用的数据存入内存，可提高程序运行速度．
B．经济可行性：在经济上，用此系统加强了成绩信息管理效率，为教务人员提供了较高的效率，可节省人力资源的开支。
C．管理的可行性：在工作上，教务人员管理学生信息量非常大，开发了此系统，可极大提高教务人员的工作的效率。方便成绩的储存和修改，及以后随时查询成绩信息，是一个比较人性化的管理系统。
（5）．系统分析结论：
由以上分析得出，本系统可进行开发。
三. 现行系统概况
1.现行系统现状调查
现有的学生成绩管理系统主要是以成绩数据信息的存储和统计为目标，而且系统的设计繁琐，管理不够专人化，需要的人员过多，因此系统的安全性保密性不好；查询功能简单，数据共享性不高。
2.系统需求说明
（1）系统需要在实现数据录入，存储，统计自动化的基础上增强查询功能；
（2）要能够充分利用网络扩大信息共享程度；
（3）设专人管理员，明确划分管理权限，规范管理，以提高系统的安全性保密性。
四. 新系统的逻辑方案
1.业务流程图
2．数据流程图
（1）顶层图：
（2）第一层：
（3）第二层：
A:身份验证图：
B:成绩变动处理科：
C:教务人员身份验证：
3.数据字典
A:数据存储条目：
编号 名称 组成
D1.1
教师信息表 教师编号,教师姓名,教师职称,所教班级,所在学院
D1.2
学生成绩记录单 学生学号，姓名，课程名称，课程编号，课程成绩，教师编号
D1.3
教务人员信息表 教务人员姓名，编号，职称
D1.4
反馈信息表 教务处人员信息后对教师的评价，学生成绩的分析
B:数据加工条目：
编号 名称 输入 处理逻辑 输出
P1.1 身份验证处理 教师登陆信息 检验教师教工号与密码是否一致 ———
P1.2 成绩变动处理 学生学科成绩 录入、修改、删除成绩并检验是否输入错误 学生成绩记录单
P1.3 成绩查询处理 学生班别、学号、姓名 查询学生成绩，排序等 学生成绩记录单
P1.4
身份验证处理 教务人员登陆信息量 检验教务人员编号与密码 ———
P1.5 成绩查询处理 学院编号、年级、学号 查询班级成绩、排序及学期平均分等 学生成绩记录单及对教师的反馈信息
C:数据元素项目：
编号 名称 数据类型 长度 小数位 取值范围 说明
01 教师编号 N 8 0
02 教师名字 C 8
03 教师职称 C 6
04 所教班级 N 8 0
05 学生学号 N 8 0
06 学生姓名 C 8
07 课程名称 C 16
08 课程编号 N 10
09 成绩 N 3 1 0~~100
10 教务人员编号 N 8 0
11 教务人员姓名 C 8
12 教务人员职称 C 6
五．系统实施计划：
1．工作任务分工：
系统初步规划：
实验报告填写及图表绘制：
系统编程：，
后期系统检测完善：
2．进度安排：
系统分析阶段：2006.6.11—2..6.6.13
系统设计阶段：20066.20—2006.6.24
系统实施阶段：2006.25—2006.6.29
__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
2系统设计报告：
系统设计报告
一、概述
以需求分析说明书为依据，针对教务管理人员及教师对学生成绩的管理需求，参照现有的开发环境，利用可用资源和使用环境，设计出能满足相应功能的特点,构造并确定出类和类成员函数。
二、环境说明
1．硬件环境：CPU型号为Pentium Ⅲ以上，内存128M以上。
系统环境：Windows98 及WindowsXP等系统均可。
2．开发环境：Access软件下开发，此软件是面向对象的开发工具，易于上手，而且界面比较友好
三、模块图
四、功能模块
本系统大致分为如下四大功能模块。
1．用户登陆模块
用户登陆模块：（教务处管理人员---叶飞—密码：950281）
（教师---刘力—密码：980102）
A:教务处管理人员登陆后，进入教务人员管理模块，可以进行个人信息查询，教师住处查询，学生信息查询，成绩查询以及退出系统等操作。
B:教师登陆后，进入教员管理模块，可以进行个人资料修改，学生信息查询，本班成绩查询，其它班成绩查询，退出登陆等操作。
2．查询及修改模块
包括以下四个模块：
A:学生个人信息查询模块：此模块又分为学生个体模块和班级模块。学生个体模块包含了学生的基本信息以及成绩，可进行如学生所在班组，学院，专业，英语成绩等相关查询操作；
在班级模块则可按班级查询学生的信息。
B:教师信息查询及修改模块：此模块主要服务于教务管理人员，可以通过打开“教师表”或“单个教师信息”进行总体或指定个体查询，如对教师工龄、工资额的设定，对各个工龄段及相应的工龄工资额进行修改、添加、删除等操作。
C:成绩查询及修改模块：该模块又分为三部分：按指定学号进行学生个体成绩查询及修改； 按指定教工号进行教师所教班级成绩查询； 按指定班级号或专业号进行综合成绩查询其中还包括教师对其它班成绩的查询（但不无修改权）。
成绩查询具体内容包括指定科目成绩查询，成绩排序，排名，平均分和不及格科目查询等
D:用户信息修改模块：此模块用于教务管理人员及教师修改密码或用户名，教师教课班级及工资职称等信息的修改。
3．退出模块
查询修改完毕，通过退出模块退出成绩管理系统，以确保系统及个人信息的安全。
五、代码设计：
1 用户登陆模块代码：
A：教务处管理人员登陆
◆Private Sub 教务处人员登录_Click()
On Error GoTo Err_教务处人员登录_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(21153) & ChrW(22788) & ChrW(20154) & ChrW(21592) & ChrW(30331) & ChrW(24405)
DoCmd.RunMacro stDocName
Exit_教务处人员登录_Click:
Exit Sub
Err_教务处人员登录_Click:
MsgBox Err.Description
Resume Exit_教务处人员登录_Click
End Sub
B: 教师登陆
◆Private Sub 教师登录_Click()
On Error GoTo Err_教师登录_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(24072) & ChrW(30331) & ChrW(24405)
DoCmd.RunMacro stDocName
Exit_教师登录_Click:
Exit Sub
Err_教师登录_Click:
MsgBox Err.Description
Resume Exit_教师登录_Click
End Sub
◆Private Sub ok_Click()
If Len(Nz(Me!UserName)) = 0 And Len(Nz(Me!UserPassword)) = 0 Then
MsgBox "用户名、密码为空！请输入", vbCritical, "error"
Me!UserName.SetFocus
ElseIf Len(Nz(Me!UserName)) = 0 Then
MsgBox "用户名为空！请输入", vbCritical, "error"
Me!UserName.SetFocus
ElseIf Len(Nz(Me!UserPassword)) = 0 Then
MsgBox "密码为空！请输入", vbCritical, "error"
Me!UserName.SetFocus
Else
If Me!UserName = "刘力" Then
If UCase(Me!UserPassword) = "980102" Then
MsgBox "欢迎使用！", vbInformation, "成功"
DoCmd.OpenForm "教师-综合信息查询"
Else
MsgBox "密码有误，非正常退出。", vbCritical, "error"
DoCmd.Close
End If
Else
MsgBox "用户名有误，非正常退出。", vbCritical, "error"
DoCmd.Close
End If
End If
End Sub
2 学生个人信息查询模块代码
A:指定学生信息查询：
◆ Private Sub Command1_Click()
On Error GoTo Err_Command1_Click
Dim stDocName As String
stDocName = ChrW(23398) & ChrW(29983) & ChrW(20010) & ChrW(20154) & ChrW(20449) & ChrW(24687) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command1_Click:
Exit Sub
Err_Command1_Click:
MsgBox Err.Description
Resume Exit_Command1_Click
End Sub
B:班级所有学生信息查询：
◆Private Sub Command20_Click()
On Error GoTo Err_Command20_Click
Dim stDocName As String
stDocName = ChrW(29677) & ChrW(32423) & ChrW(23398) & ChrW(29983) & ChrW(20449) & ChrW(24687) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command20_Click:
Exit Sub
Err_Command20_Click:
MsgBox Err.Description
Resume Exit_Command20_Click
End Sub
3 教师信息查询及修改模块代码
A:指定教师信息查询
◆Private Sub Command13_Click()
On Error GoTo Err_Command13_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(24072) & ChrW(20449) & ChrW(24687) & ChrW(21333) & ChrW(20010) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command13_Click:
Exit Sub
Err_Command13_Click:
MsgBox Err.Description
Resume Exit_Command13_Click
End Sub
B:全体教师信息查询：
◆Private Sub Command14_Click()
On Error GoTo Err_Command14_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(24072) & ChrW(20449) & ChrW(24687) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command14_Click:
Exit Sub
Err_Command14_Click:
MsgBox Err.Description
Resume Exit_Command14_Click
End Sub
4 成绩查询及修改模块代码
A:指定学生个体成绩查询：
◆Private Sub Command23_Click()
On Error GoTo Err_Command23_Click
Dim stDocName As String
stDocName = ChrW(23398) & ChrW(29983) & ChrW(20010) & ChrW(20154) & ChrW(25104) & ChrW(32489) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command23_Click:
Exit Sub
Err_Command23_Click:
MsgBox Err.Description
Resume Exit_Command23_Click
End Sub
B: 指定班级综合成绩查询
◆Private Sub Command24_Click()
On Error GoTo Err_Command24_Click
Dim stDocName As String
stDocName = ChrW(25353) & ChrW(29677) & ChrW(32423) & ChrW(26597) & ChrW(-29726) & ChrW(23398) & ChrW(29983) & ChrW(25104) & ChrW(32489)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command24_Click:
Exit Sub
Err_Command24_Click:
MsgBox Err.Description
Resume Exit_Command24_Click
End Sub
5 用户信息修改模块代码
◆Private Sub Command28_Click()
On Error GoTo Err_Command28_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(21153) & ChrW(22788) & ChrW(20154) & ChrW(21592) & ChrW(20449) & ChrW(24687) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command28_Click:
Exit Sub
Err_Command28_Click:
MsgBox Err.Description
Resume Exit_Command28_Click
End Sub
6 退出模块代码
◆Private Sub Command31_Click()
On Error GoTo Err_Command31_Click
DoCmd.Quit
Exit_Command31_Click:
Exit Sub
Err_Command31_Click:
MsgBox Err.Description
Resume Exit_Command31_Click
End Sub
__________________________________________________________________________________________________________
3系统实施报告
㈤ 大数据时代，数据应该如何存储
PB或多PB级基础设施与传统大规模数据集之间的差别简直就像白天和黑夜的差别，就像在笔记本电脑上处理数据和在RAID阵列上处理数据之间的差别。"
当Day在2009年加入Shutterfly时，存储已经成为该公司最大的开支，并且以飞快的速度增长。
"每N个PB的额外存储意味着我们需要另一个存储管理员来支持物理和逻辑基础设施，"Day表示，"面对大规模数据存储，系统会更频繁地出问题，任何管理超大存储的人经常都要处理硬件故障。大家都在试图解决的根本问题是：当你知道存储的一部分将在一段时间内出现问题，你应该如何确保数据可用性，同时确保不会降低性能？"RAID问题解决故障的标准答案是复制，通常以RAID阵列的形式。但Day表示，面对庞大规模的数据时，RAID解决问题的同时可能会制造更多问题。在传统RAID数据存储方案中，每个数据的副本都被镜像和存储在阵列的不同磁盘中，以确保完整性和可用性。但这意味着每个被镜像和存储的数据将需要其本身五倍以上的存储空间。随着RAID阵列中使用的磁盘越来越大（从密度和功耗的角度来看，3TB磁盘非常具有吸引力），更换故障驱动器的时间也将变得越来越长。
"实际上，我们使用RAID并不存在任何操作问题，"Day表示，"我们看到的是，随着磁盘变得越来越大，当任何组件发生故障时，我们回到一个完全冗余的系统的时间增加。生成校验是与数据集的大小成正比的。当我们开始使用1TB和2TB的磁盘时，回到完全冗余系统的时间变得很长。可以说，这种趋势并没有朝着正确的方向发展。"
对于Shutterfly而言，可靠性和可用性是非常关键的因素，这也是企业级存储的要求。Day表示，其快速膨胀的存储成本使商品系统变得更具吸引力。当Day及其团队在研究潜在技术解决方案以帮助控制存储成本时，他们对于一项叫做纠删码（erasure code）的技术非常感兴趣。
采用擦除代码技术的下一代存储
里德-所罗门纠删码最初作为前向纠错码（Forward Error Correction, FEC）用于不可靠通道的数据传输，例如外层空间探测的数据传输。这项技术还被用于CD和DVD来处理光盘上的故障，例如灰尘和划痕。一些存储供应商已经开始将纠删码纳入他们的解决方案中。使用纠删码，数据可以被分解成几块，单块分解数据是无用的，然后它们被分散到不同磁盘驱动器或者服务器。在任何使用，这些数据都可以完全重组，即使有些数据块因为磁盘故障已经丢失。换句话说，你不需要创建多个数据副本，单个数据就可以确保数据的完整性和可用性。
基于纠删码的解决方案的早期供应商之一是Cleversafe公司，他们添加了位置信息来创建其所谓的分散编码，让用户可以在不同位置（例如多个数据中心）存储数据块或者说数据片。
每个数据块就其自身而言是无用的，这样能够确保隐私性和安全性。因为信息分散技术使用单一数据来确保数据完整性和可用性，而不是像RAID一样使用多个副本，公司可以节省多达90%的存储成本。
"当你将试图重组数据时，你并不一定需要提供所有数据块，"Cleversafe公司产品策略、市场营销和客户解决方案副总裁Russ Kennedy表示，"你生成的数据块的数量，我们称之为宽度，我们将重组数据需要的最低数量称之为门槛。你生成的数据块的数量和重组需要的数量之间的差异决定了其可靠性。同时，即使你丢失节点和驱动器，你仍然能够得到原来形式的数据。"
㈥ 数据存储解决方案可以实现什么作用
数据存储解决方案可以实现的作用有以下8点：
1 信息资产的统一管控
企业运行过程中，可能产生一些违规数据，可将违规数据定位，并且统一删除，对所有用户的查询和使用集中控制。
2 分公司管理员角色设置
云企网盘可针对大中型企业，灵活的配置用户权限，可设置多级的管理员权限。
3 标准API接口，系统间无缝对接
云企网盘系统提供了全套的API接口，可完成所有功能的数据对接，其他系统调用即可将数据传输至云企网盘集中管理，安全存储。
云企网盘系统从底层上就设计为可对接的数据管理系统，各终端都通过API对系统进行访问。
4 按钮级权限设置
考虑到企业的数据管控，文件系统的防扩散。云企网盘的授权体系可细分到按钮，可以控制每个用户，能否操作每一个具体的功能。
5 集团级组织架构设置
云企网盘是针对企业管理设计的系统，可针对复杂的企业组织架构进行设置，可适用与集团级的大型企业。可对组织的级别、性质、顺序进行定义，可以添加、删除、移动组织单元。
6 信息资产的查询
云企网盘可根据数据的授权，统一对数据进行查询，可根据条件进行高级检索。
7 文档版本管理
文件上传更新以后，所有历史版本都会继续保存，这样即使工作中发生了失误，也可以通过网盘补救。 查看原始文档 找回丢失文件 修复崩溃文档
找回错误覆盖的文件
8 信息资产的迁移
企业员工根据工作内容的变化，可能发生工作的交接情况，云企网盘可将员工的文件管理权限进行一键交接。快速的工作交接同时，也避免数据丢失，避免企业资产受损。
㈦ ScaleIO、VSAN、MFS、Ceph这几种存储方案的区别是什么
ScaleIO:使用弹性聚合软件产品来革新数据存储，该软件产品利用本地磁盘来创建服务器存储区域网络 (SAN)。纯软件方式的基于服务器的存储区域网络 (SAN)，将存储和计算资源聚合到一起，形成单层的企业级存储产品。 ScaleIO 存储弹性灵活，可以提供可线性扩展的性能。 其横向扩展服务器 SAN 体系结构可以从几个服务器扩展至数千服务器。
基本适用于全平台。https://community.emc.com/thread/198500
VSAN：VMware Virtual SAN™ 是面向虚拟环境中超聚合的软件定义存储.Virtual SAN 是第一款专为 vSphere 环境设计的策略驱动型存储产品，可帮助用户实现存储调配和管理的简化和优化。 通过使用虚拟机级存储策略，Virtual SAN 可自动将需求与底层存储资源进行动态匹配。借助 Virtual SAN，许多手动存储任务都可以实现自动化，从而提供更加高效和经济实惠的运维模式。对比 ScaleIO，它是仅限于VMware虚拟化平台的。
参考链接：Virtual SAN：软件定义的共享存储 | VMware 中国
MFS 是分布式文件系统，可参考：分布式存储系统MFS -
Ceph是一个 Linux PB 级分布式文件系统。
㈧ 大数据下的地质资料信息存储架构设计
颉贵琴 胡晓琴
(甘肃省国土资源信息中心)
摘要 为推进我国地质资料信息服务集群化产业化工作，更大更好地发挥地质资料信息的价值，本文针对我国现有的地质资料信息集群化共享服务平台存在的缺陷和问题，基于现有系统的存储架构，设计了一种大数据下的地质资料信息存储架构，以便于我国地质资料信息服务集群化产业化工作能够适应大数据时代的数据存储。
关键词 大数据 地质资料 存储 NoSQL 双数据库
0 引言
新中国成立60多年来，我国形成了海量的地质资料信息，为国民经济和社会发展提供了重要支撑。但在地质资料管理方面长期存在资料信息分散、综合研究不够、数字化信息化程度不高、服务渠道不畅、服务能力不强等问题，使地质资料信息的巨大潜在价值未能得到充分发挥。为进一步提高地质工作服务国民经济和社会发展的能力，充分发挥地质资料信息的服务功能，扩大服务领域，国土资源部根据国内外地质工作的先进经验，做出了全面推进地质资料信息服务集群化产业化工作的部署。
目前，全国各省地质资料馆都在有条不紊地对本省成果、原始和实物地质资料进行清理，并对其中重要地质资料进行数字化和存储工作。然而，由于我国地质资源丰富，经过几十年的积累，已经形成了海量的地质资料，数据量早已经超过了几百太字节(TB)。在进行地质资料信息服务集群化工作中，随着共享数据量的不断增大，传统的数据存储方式和管理系统必然会展现出存储和检索方面的不足以及系统管理方面的缺陷。为了解决该问题，需要设计更加先进的数据存储架构来实现海量地质资料的存储。
而大数据(Big Data)作为近年来在云计算领域中出现的一种新型数据，科技工作者在不断的研究中，设计了适合大数据存储管理的非关系型数据库NoSQL进行大数据的存储和管理。本文将针对我国现有的地质资料信息集群化共享服务平台存在的缺陷和问题，利用大数据存储管理模式的思想，提出一种海量地质资料存储架构，改进现有系统存储架构，以便于我国全面推进地质资料信息服务集群化产业化工作。
1 工作现状
1.1 国内外地质资料信息的存储现状
在美国，主要有两大地质资料公共服务平台，分别是地球科学信息中心(ESIC)、地球资源观测和科学中心(EROS)，其目的是通过为社会和政府提供更加便利、快速的地质信息服务。20世纪90年代初，澳大利亚出台了国家地球科学填图协议，采用先进的科学方法和技术进行数据存储，从而形成了第二代澳大利亚陆地地质图。
目前，我国地质资料信息服务集群化产业化工作刚刚起步，虽然国土资源部信息中心已经开发了地质资料信息集群化共享服务平台，并倡导各地方用户使用该系统。但由于各个地方早期的工作背景不一致，因此各地方所使用的存储系统也不尽相同，主要有Access、SQL Server、Oracle、MySQL等系统。本文以国土资源部信息中心开发的地质资料信息集群化共享服务平台的存储系统MySQL为例说明。该系统是基于关系数据库管理系统MySQL的一套分布式存储检索系统。该系统的部署使得我国地质资料信息服务集群化产业化工作取得了重大进展，同时也为我国建立标准统一的地质资料信息共享服务平台和互联互通的网络服务体系奠定了坚实的基础。然而，该系统的研发并没有考虑到地质资料信息进一步集群化以及在未来地质资料信息进入大数据时代的信息共享和存储管理问题，也没有给出明确的解决方案。
1.2 大数据的存储架构介绍
大数据是近年在云计算领域中出现的一种新型数据，具有数据量大、数据结构不固定、类型多样、查询分析复杂等特点。传统关系型数据库管理系统在数据存储规模、检索效率等方面已不再适合大数据存储。NoSQL(Not Only SQL)是与关系数据库相对的一类数据库的总称。这些数据库放弃了对关系数据库的支持，转而采用灵活的、分布式的数据存储方式管理数据，从而可以满足大数据存储和处理的需求。NoSQL基于非关系型数据存储的设计理念，以键值对进行存储，采用的数据字的结构不固定，每一个元组可以有不一样的字段，且每个元组可以根据自己的需要增加一些自己的键值对，可以减少一些检索时间和存储空间。目前，应用广泛的 NoSQL 数据库有 Google BigTable、HBase、MongoDB、Neo4 j、Infinite Graph等。
2 大数据下的地质资料信息存储架构设计
根据国土资源部做出的全面推进地质资料信息服务集群化产业化工作的部署，国土资源部倡导全国地质资料馆使用国土资源部信息中心开发的地质资料信息集群化共享服务平台，实现地质资料信息的存储和共享。该系统采用了数据库管理系统MySQL作为数据存储系统。
为了与现有系统和现有的工作进行对接，并为将来地质资料进入大数据时代后的存储工作做准备，本文设计了一种能用于海量地质资料信息存储并且兼容MySQL的分布式的数据存储架构(图1)。
整个系统可以根据不同的用户等级分为不同的用户管理层，由于图幅限制，在图1 中仅仅展示了3级：国家级管理层(即共享服务平台用户层)、省级管理层以及市级管理层(可根据实际需要延伸至县级)。
每级管理层的每个用户可以单独管理一个服务器。如国土资源部信息中心可以单独管理一个服务器；甘肃省国土资源信息中心可以单独管理一个服务器，陕西省国土资源信息中心可以单独管理一个服务器；甘肃的若干个市级国土资源局可以根据需要分别管理各自的服务器。
在服务器上分别安装两套数据库管理系统，一套是原有的MySQL数据库管理系统，另一套是为大数据存储而配备的NoSQL型数据库管理系统。在服务器上还专门开发一个数据库管理器中间件，用于进行用户层和数据库的通信以及两套数据库之间的通信。
由于各个管理层都各自维护自己的数据库和数据。当用户需要进行数据存储时，他所影响的数据库仅仅是本地数据库，存储效率较高；当用户需要从多个数据库读取数据时，顶层的共享服务平台会根据用户需求进行任务分解，将任务分发给下层的管理层进行数据库读取，由于各个数据库并行读取，从而提高了数据库读取效率。
图1 大数据下的地质资料信息存储架构框图
2.1 用户管理层
用户管理层根据权限范围，分为多层(本文以3层为例)。
位于顶层的国家级管理层(共享服务平台用户层)负责用户访问权限的分配、与其直接关联的数据库的访问、下级管理层任务的分配等工作。
用户访问权限的分配是指为访问本共享服务平台的个人用户和单位用户分配数据的使用权限、安全性的设计等。
与其直接关联的数据库访问是指直接存储在其本地数据库上的数据的访问。在该数据库中不仅要存储所需要的地质资料，还要存储注册用户信息等数据。
下级管理层任务分配是指如果用户需要访问多个下层数据库，用户只需要输入查询这几个下层数据库的命令，而如何查找下层数据库则由该功能来完成。例如某用户要查找甘肃、陕西、上海、北京的铁矿分布图，则用户只需要输入这几个地方及铁矿等查询条件，系统将自动把各个省的数据库查询任务分派到下级管理层。
同理，位于下层的省级管理层和市级管理层除了没有用户访问权限功能外，其余功能与国家级管理层是相同的。各层之间的数据库通过互联网相互连接成分布式的数据库系统。
2.2 MySQL和NoSQL的融合
MySQL是关系型数据库，它支持SQL查询语言，而NoSQL是非关系型数据库，它不支持SQL查询语言。用户要想透明地访问这两套数据库，必须要设计数据库管理器中间件，作为用户访问数据库的统一入口和两套数据库管理系统的通信平台。本文所设计的数据库管理器简单模型如图2所示。
图2 数据库管理器模型
服务器管理器通过用户程序接口与应用程序进行通讯，通过MySQL数据库接口与MySQL服务器通讯，通过NoSQL数据库接口与NoSQL数据库接口通讯。当应用程序接口接收到一条数据库访问命令之后，交由数据库访问命令解析器进行命令解析，从而形成MySQL访问命令或者NoSQL访问命令，通过相应的数据库接口访问数据库；数据库返回访问结果后经过汇总，由应用程序接口返回给应用程序。
两套数据库可以通过双数据库通信协议进行相互的通信和互访。此通信协议的建立便于地质工作人员将已经存入MySQL数据库的不适合结构化存储的数据转存到NoSQL数据库中，从而便于系统的升级和优化。
2.3 系统的存储和检索模式
在本存储框架设计中，系统采用分布式网络存储模式，即采用可扩展的存储结构，利用分散在全国各地的多台独立的服务器进行数据存储。这种方式不仅分担了服务器的存储压力，提高了系统的可靠性和可用性，还易于进行系统扩展。另外，由于地质资料信息存储的特殊性，各地方用户的数据存储工作基本都是在本地服务器进行，很少通过网络进行远程存储，所以数据存储效率较高。
在一台数据库服务器上安装有MySQL和NoSQL型两套数据库管理系统，分别用于存储地质资料信息中的结构化数据和非结构化数据。其中，NoSQL型数据库作为主数据库，用于存储一部分结构化数据和全部的非结构化数据；而MySQL数据库作为辅助数据库，用于存储一部分结构化的数据，以及旧系统中已经存储的数据。使用两套数据库不仅可以存储结构化数据而且还可以适用于大数据时代地质资料信息的存储，因此系统具有很好的适应性和灵活性。
2.4 安全性设计
地质资料信息是国家的机密，地质工作人员必须要保证它的安全。地质资料信息进入数字化时代之后，地质资料常常在计算机以及网络上进行传输，地质资料信息的安全传输和保存更是地质工作人员必须关注和解决的问题。在本存储架构的设计中设计的安全问题主要有数据库存储安全、数据传输安全、数据访问安全等问题。
数据库设计时采用多边安全模型和多级安全模型阻止数据库中信息和数据的泄露来提高数据库的安全性能，以保障地质信息在数据库中的存储安全；当用户登录系统访问数据库时，必须进行用户甄别和实名认证，这主要是对用户的身份进行有效的识别，防止非法用户访问数据库；在对地质资料进行网络传输时，应该首先将数据进行加密，然后再进行网络传输，以防止地质信息在传输过程中被窃取。
3 结语
提高地质资料数字化信息化水平，是国外地质工作强国的普遍做法。为推进我国地质资料信息服务集群化产业化工作，本文针对我国现有的地质资料信息集群化共享服务平台存在的缺陷和问题，利用大数据存储管理模式的思想，基于现有系统的存储架构，设计了一种大数据下的地质资料信息存储架构，以便于我国地质资料信息服务集群化产业化工作能够适应大数据时代的数据存储。该存储架构的设计只涉及了简单模型的构建，具体详细复杂的功能设计和软件实现还需要在进一步的研究工作中完成。
参考文献
[1]吴金朋.一种大数据存储模型的研究与应用[D].北京：北京邮电大学计算机学院，2012.
[2]吴广君，王树鹏，陈明，等.海量结构化数据存储检索系统[J].计算机研究与发展，2012，49(Suppl)：1～5.
[3]黄
㈨ Redis百亿级Key存储设计方案
该应用场景为DMP缓存存储需求，DMP需要管理非常多的第三方id数据，其中包括各媒体cookie与自身cookie（以下统称supperid）的mapping关系，还包括了supperid的人口标签、移动端id（主要是idfa和imei）的人口标签，以及一些黑名单id、ip等数据。
在hdfs的帮助下离线存储千亿记录并不困难，然而DMP还需要提供毫秒级的实时查询。由于cookie这种id本身具有不稳定性，所以很多的真实用户的浏览行为会导致大量的新cookie生成，只有及时同步mapping的数据才能命中DMP的人口标签，无法通过预热来获取较高的命中，这就跟缓存存储带来了极大的挑战。
经过实际测试，对于上述数据，常规存储超过五十亿的kv记录就需要1T多的内存，如果需要做高可用多副本那带来的消耗是巨大的，另外kv的长短不齐也会带来很多内存碎片，这就需要超大规模的存储方案来解决上述问题。
人⼝标签主要是cookie、imei、idfa以及其对应的gender（性别）、age（年龄段）、geo（地域）等；mapping关系主要是媒体cookie对supperid的映射。以下是数据存储⽰示例：
媒体编号-媒体cookie=>supperid
supperid => { age=>年龄段编码，gender=>性别编码，geo=>地理位置编码 }
imei or idfa => { age=>年龄段编码，gender=>性别编码，geo=>地理位置编码 }
显然PC数据需要存储两种key=>value还有key=>hashmap，⽽而Device数据需要存储⼀一种
key=>hashmap即可。
存储吃紧的一个重要原因在于每天会有很多新数据入库，所以及时清理数据尤为重要。主要方法就是发现和保留热数据淘汰冷数据。
网民的量级远远达不到几十亿的规模，id有一定的生命周期，会不断的变化。所以很大程度上我们存储的id实际上是无效的。而查询其实前端的逻辑就是广告曝光，跟人的行为有关，所以一个id在某个时间窗口的（可能是一个campaign，半个月、几个月）访问行为上会有一定的重复性。
数据初始化之前，我们先利用hbase将日志的id聚合去重，划定TTL的范围，一般是35天，这样可以砍掉近35天未出现的id。另外在Redis中设置过期时间是35天，当有访问并命中时，对key进行续命，延长过期时间，未在35天出现的自然淘汰。这样可以针对稳定cookie或id有效，实际证明，续命的方法对idfa和imei比较实用，长期积累可达到非常理想的命中。
Hash表空间大小和Key的个数决定了冲突率（或者用负载因子衡量），再合理的范围内，key越多自然hash表空间越大，消耗的内存自然也会很大。再加上大量指针本身是长整型，所以内存存储的膨胀十分可观。先来谈谈如何把key的个数减少。
大家先来了解一种存储结构。我们期望将key1=>value1存储在redis中，那么可以按照如下过程去存储。先用固定长度的随机散列md5(key)值作为redis的key，我们称之为BucketId，而将key1=>value1存储在hashmap结构中，这样在查询的时候就可以让client按照上面的过程计算出散列，从而查询到value1。
过程变化简单描述为：get(key1) -> hget(md5(key1), key1) 从而得到value1。
如果我们通过预先计算，让很多key可以在BucketId空间里碰撞，那么可以认为一个BucketId下面挂了多个key。比如平均每个BucketId下面挂10个key，那么理论上我们将会减少超过90%的redis key的个数。
具体实现起来有一些麻烦，而且用这个方法之前你要想好容量规模。我们通常使用的md5是32位的hexString（16进制字符），它的空间是128bit，这个量级太大了，我们需要存储的是百亿级，大约是33bit，所以我们需要有一种机制计算出合适位数的散列，而且为了节约内存，我们需要利用全部字符类型（ASCII码在0~127之间）来填充，而不用HexString，这样Key的长度可以缩短到一半。
下面是具体的实现方式
参数bit决定了最终BucketId空间的大小，空间大小集合是2的整数幂次的离散值。这里解释一下为何一个字节中只有7位可用，是因为redis存储key时需要是ASCII（0~127），而不是byte array。如果规划百亿级存储，计划每个桶分担10个kv，那么我们只需2^30=1073741824的桶个数即可，也就是最终key的个数。
碎片主要原因在于内存无法对齐、过期删除后，内存无法重新分配。通过上文描述的方式，我们可以将人口标签和mapping数据按照上面的方式去存储，这样的好处就是redis key是等长的。另外对于hashmap中的key我们也做了相关优化，截取cookie或者deviceid的后六位作为key，这样也可以保证内存对齐，理论上会有冲突的可能性，但在同一个桶内后缀相同的概率极低(试想id几乎是随机的字符串，随意10个由较长字符组成的id后缀相同的概率*桶样本数=发生冲突的期望值<<0.05,也就是说出现一个冲突样本则是极小概率事件，而且这个概率可以通过调整后缀保留长度控制期望值)。而value只存储age、gender、geo的编码，用三个字节去存储。
另外提一下，减少碎片还有个很low但是有效的方法，将slave重启，然后强制的failover切换主从，这样相当于给master整理的内存的碎片。
推荐Google-tcmalloc， facebook-jemalloc内存分配，可以在value不大时减少内存碎片和内存消耗。有人测过大value情况下反而libc更节约。
1）kv存储的量级必须事先规划好，浮动的范围大概在桶个数的十到十五倍，比如我就想存储百亿左右的kv，那么最好选择30bit 31bit作为桶的个数。也就是说业务增长在一个合理的范围（10 15倍的增长）是没问题的，如果业务太多倍数的增长，会导致hashset增长过快导致查询时间增加，甚至触发zip-list阈值，导致内存急剧上升。
2）适合短小value，如果value太大或字段太多并不适合，因为这种方式必须要求把value一次性取出，比如人口标签是非常小的编码，甚至只需要3、4个bit（位）就能装下。
3）典型的时间换空间的做法，由于我们的业务场景并不是要求在极高的qps之下，一般每天亿到十亿级别的量，所以合理利用CPU租值，也是十分经济的。
4）由于使用了信息摘要降低了key的大小以及约定长度，所以无法从redis里面random出key。如果需要导出，必须在冷数据中导出。
5）expire需要自己实现，目前的算法很简单，由于只有在写操作时才会增加消耗，所以在写操作时按照一定的比例抽样，用HLEN命中判断是否超过15个entry，超过才将过期的key删除，TTL的时间戳存储在value的前32bit中。
6）桶的消耗统计是需要做的。需要定期清理过期的key，保证redis的查询不会变慢。
人口标签和mapping的数据100亿条记录。
优化前用2.3T，碎片率在2左右；优化后500g，而单个桶的平均消耗在4左右。碎片率在1.02左右。查询时这对于cpu的耗损微乎其微。
另外需要提一下的是，每个桶的消耗实际上并不是均匀的，而是符合多项式分布的。
上面的公式可以计算桶消耗的概率分布。公式是唬人用的，只是为了提醒大家不要想当然的认为桶消耗是完全均匀的，有可能有的桶会有上百个key。但事实并不没有那么夸张。试想一下投硬币，结果只有两种正反面。相当于只有两个桶，如果你投上无限多次，每一次相当于一次伯努利实验，那么两个桶必然会十分的均匀。概率分布就像上帝施的魔咒一样，当你面对大量的桶进行很多的广义的伯努利实验。桶的消耗分布就会趋于一种稳定的值。接下来我们就了解一下桶消耗分布具体什么情况：
通过采样统计
31bit（20多亿）的桶，平均4.18消耗
100亿节约了1.8T内存。相当于节约了原先的78%内存，而且桶消耗指标远没有达到预计的底线值15。
对于未出现的桶也是存在一定量的，如果过多会导致规划不准确，其实数量是符合二项分布的，对于2 30桶存储2 32kv，不存在的桶大概有（百万级别，影响不大）：
Math.pow((1 - 1.0 / Math.pow(2, 30)), Math.pow(2, 32)) * Math.pow(2, 30);
对于桶消耗不均衡的问题不必太担心，随着时间的推移，写入时会对HLEN超过15的桶进行削减，根据多项式分布的原理，当实验次数多到一定程度时，桶的分布就会趋于均匀（硬币投掷无数次，那么正反面出现次数应该是一致的），只不过我们通过expire策略削减了桶消耗，实际上对于每个桶已经经历了很多的实验发生。
总结：信息摘要在这种场景下不仅能节约key存储，对齐了内存，还能让Key按照多项式分布均匀的散列在更少量的key下面从而减少膨胀，另外无需在给key设置expire，也很大程度上节约了空间。
这也印证了时间换空间的基本理论，合理利用CPU租值也是需要考虑的。
关注分布式存储技术以及分布式计算方法