气象数据库分析
存储气象数据，用什么数据库好呢
数据库是存放数据的仓库。简单分为关系型数据库与非关系型数据库。
关系型数据库，存储的格式可以直观地反映实体间的关系。关系型数据库和常见的表格比较相似，关系型数据库中表与表之间是有很多复杂的关联关系的。 常见的关系型数据库有Mysql，SqlServer等。在轻量或者小型的应用中，使用不同的关系型数据库对系统的性能影响不大，但是在构建大型应用时，则需要根据应用的业务需求和性能需求，选择合适的关系型数据库。
非关系型数据库（NoSQL）：指的是分布式的、非关系型的、不保证遵循ACID原则的数据存储系统。大量的NoSql数据库如MongoDB[11] 、Redis、Memcache出于简化数据库结构、避免冗余、影响性能的表连接、摒弃复杂分布式的目的被设计。
键值对数据库是最简单的几种NoSQL数据库之一，由带索引的键 (indexed key) 和其所对应的值 (value) 组成。
当给出一个键时，键值对数据库可以通过哈希机制快速找到与其相关联的值。哈希机制的时间复杂度为常数时间 (constant time)，这意味着即使数据规模很大，键值对数据库依然可以维持高性能。
键值对的键可以是任意类别的对象，但通常是一个字符串 (string)。键值对的值一般来说是模糊的BLOB类型（即：一串数据库不解读的字节）。
键值对数据库包括：Redis, Amazon DynamoDB, Riak以及Oracle NoSQL。一些像是Cassandra一样的表格式的NoSQL数据库也可以满足键值对的需求。
思考：键值对数据库都是一个key对应一或多个value,而全球海洋数据是三个维度，经纬度和时间对应u风或v风数据。故排除这类分布式数据库。
其实Redis应该可以用key-list-list，就是list嵌套list实现多维，但费力。
文档型数据库由基本的键值对存储模式而来，但是存储数据的“文档”则更为复杂一些。
每一个文档都会被分配一个唯一的键 (key)，用来调取文档。这些数据库是为了存储、调取和管理面向文档的信息（通常以JSON的格式存储）而设计的。
因为文档型数据库可以检阅文档内容，它们可以实现一些额外的调取处理。与要求静态模式(schema) 的关系型数据库管理系统 (RDBMSs) 相比，文档型数据库则有着由文档内容定义的、更为灵活的模式。
文档型数据库的例子包括MongoDB和CouchDB。注意：一些关系型数据库管理系统和非纯存储文档的NoSQL数据库也可以存储和查询JSON文档，其中包括了Cassandra。
思考：同样不适合全球海洋数据的处理
表格型数据库用行和列来存储数据，但是与传统的数据库管理系统略有不同。
这种数据库也被称为宽表存储 (wide-column stores) 或是分区行存储 (partitioned row stores)，他们提供把数据库中属于同一个分区的相关行分到同一数据副本的能力，从而达到更快查询的目的。
与关系型数据库管理系统不同的是，表格的格式并不是严格固定的。例如Apache Cassandra™并不要求表格中所有的行的每一列都要有值。
与键值对和文档型数据库一样，表格型数据库也使用哈希函数来调取表格中的记录。
表格型数据库包括：Cassandra、HBase以及Google Bigtable。
思考：应该最后就是从表格型数据库中找一个开源的、合适的来进行数据处理。其中HBase要收费，暂时放弃。
还有图型数据库和混合型数据库，但应该对全球海洋数据处理不太合适，暂且不考虑。
首先要知道我们要处理的这全球海洋数据的特点：
目前简单分析，可以知道最少要满足以下三个要求：
查阅知网相关文献，搜索数据库处理气象数据关键词，知道了GBase数据库、虚谷数据库、TableStore、Hbase等数据库等可以较适合地处理海量气象数据。特别是TableStore数据库，TableStore是一款阿里自研的分布式NoSQL服务，可以提供超大规模的存储容量，支撑超大规模的并发访问和低延迟的性能，可以很好的解决气象数据的规模和查询性能问题，并且该数据库有基于TableStore的海量气象格点数据解决方案实战等文章可以查阅学习，有诸多便利。
但因为这些数据库并非开源，成本较高，且因为非开源故用户少，相关数据库学习方面不如开源数据库便利，故暂且不考虑。
思考：如果考虑收费数据库的话，最好的是TableStore。
开始潜意识认为MySQL这种关系型数据库不适合做为该项目的数据库。阿里巴巴《Java开发手册》提出：单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。但是如果按照时间来进行读取数据，大约一个生成的特定时刻全球海洋数据的txt文件里大约为480*61个数据。一年有722个这样的txt文件，一共有31年，存储肯定是没问题，目前不知道具体实现细节是怎样的，能不能用MySQL的分库分表操作来实现功能，以及最后查询时延会不会过大。
有CSDN相关文档使用python爬取全国天气数据并导入MySQL数据库表提供一点思路，但因数据量不同故或许存在许多问题，具体能否用MySQL进行项目应用有待商榷。
思考：实在没办法的时候，可以考虑，应该是可以做到分库分表始实现所需要求的，但是应该会事倍功半。
Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存收件箱等简单格式数据，集GoogleBigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身Facebook于2008将 Cassandra 开源，此后，由于Cassandra良好的可扩展性，被Digg、Twitter等知名Web 2.0网站所采纳，成为了一种流行的分布式结构化数据存储方案。
Cassandra是一个混合型的非关系的数据库，类似于Google的BigTable。其主要功能比Dynamo （分布式的Key-Value存储系统）更丰富，但支持度却不如文档存储MongoDB（介于关系数据库和非关系数据库之间的开源产品，是非关系数据库当中功能最丰富，最像关系数据库的。支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型）。
主要是属于表格型数据库，且开源。表格型数据库用行和列来存储数据，但是与传统的数据库管理系统略有不同。与键值对和文档型数据库一样，表格型数据库也使用哈希函数来调取表格中的记录。
思考：表格型数据库，且开源，目前是最优选择，如果后续没有更合适的数据库，优先拿此数据库进行尝试。
Bigtable是一个分布式多维映射表，表中的数据通过一个行关键字（Row Key）、一个列关键字（Column Key）以及一个时间戳（Time Stamp）进行索引。Bigtable对存储在其中的数据不做任何解析，一律看做字符串，具体数据结构的实现需要用户自行处理。
思考：也是表格型数据库，开源，全球海洋数据可以用这个数据库，行为经度，列为纬度，时间戳为时间。理论上应该可以实现。还未具体查阅。
进入巨杉数据库的关键技术——分区概念，我们支持两种分区，一种是水平分区，另一种是垂直分区。
水平分区： 这里提到两个概念，一是集合空间（CS），二是集合（CL），我们基本数据存储单元是集合，可以等同于传统关系型数据库里的表，水平分区的概念是在集合里，可以选定一个字段或者多个字段作为水平分区的键（key）。
巨杉数据库会根据你选定的键或者键值，把数据对应到集合对应的所有分区。水平分区最大的好处是可以把多个节点组成复制组，你可以把数据均匀的分布到多个数据节点或者多个复制组，避免单一存储或者单一节点带来的瓶颈，对于分布式数据库来讲是必不可少的特性。
垂直分区： 垂直分区更多的跟业务逻辑相关，常见信息是流水表，如果你想保存银行过去10年甚至20年的交易流水表，这是海量天文数字的数据。因此，我们可以将庞大的数据从逻辑意义上区分开，按时间戳作为分隔的字段。
多维分区：
多维分区机制，把水平分区和垂直分区两种方式结合在一起使用。这跟垂直分区的图类似，在每一个子集合内部可以用水平分区，均匀打散到多个不同的物理存储上。
思考：应该是属于键值型数据库的一种，但是它可以选定一个字段或多个字段作为key，而非固定一个字段作为Key,如果选经纬度、时间作为key，应该就可以满足项目要求。重点是开源，但不为首选，还是表格型数据库最合适。