Ⅰ 大数据下的地质资料信息存储架构设计
颉贵琴 胡晓琴
(甘肃省国土资源信息中心)
摘要 为推进我国地质资料信息服务集群化产业化工作，更大更好地发挥地质资料信息的价值，本文针对我国现有的地质资料信息集群化共享服务平台存在的缺陷和问题，基于现有系统的存储架构，设计了一种大数据下的地质资料信息存储架构，以便于我国地质资料信息服务集群化产业化工作能够适应大数据时代的数据存储。
关键词 大数据 地质资料 存储 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]黄
Ⅱ 如何优化操作大数据量数据库
下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。
1．合理使用索引
索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下：
●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。
●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。
●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
●如果待排序的列有多个，可以在这些列上建立复合索引（pound index）。
●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。
2．避免或简化排序
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
●索引中不包括一个或几个待排序的列；
●group by或order by子句中列的次序与索引的次序不一样；
●排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。
3．消除对大型表行数据的顺序存取
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的 *** ，所以应该改为如下语句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
这样就能利用索引路径处理查询。
4．避免相关子查询
一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。
5．避免困难的正规表达式
MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3]>“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。
6．使用临时表加速查询
把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然后以下面的方式在临时表中查询：
SELECT ＊ FROM cust_with_balance
WHERE postcode>“98000”
临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。
注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。
7．用排序来取代非顺序存取
非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。
有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。
实例分析
下面我们举一个制造公司的例子来说明如何进行查询优化。制造公司数据库中包括3个表，模式如下所示：
1．part表
零件号?????零件描述????????其他列
（part_num）?（part_desc）??????（other column）
102，032???Seageat 30G disk?????……
500，049???Novel 10M neork card??……
……
2．vendor表
厂商号??????厂商名??????其他列
（vendor _num）?（vendor_name） （other column）
910，257?????Seageat Corp???……
523，045?????IBM Corp?????……
……
3．parven表
零件号?????厂商号?????零件数量
（part_num）?（vendor_num）?（part_amount）
102，032????910，257????3,450,000
234，423????321，001????4，000，000
……
下面的查询将在这些表上定期运行，并产生关于所有零件数量的报表：
SELECT part_desc，vendor_name，part_amount
FROM part，vendor，parven
WHERE part.part_num=parven.part_num
AND parven.vendor_num = vendor.vendor_num
ORDER BY part.part_num
如果不建立索引，上述查询代码的开销将十分巨大。为此，我们在零件号和厂商号上建立索引。索引的建立避免了在嵌套中反复扫描。关于表与索引的统计信息如下：
表?????行尺寸???行数量?????每页行数量???数据页数量
（table）?(row size)?（Row count）?（Rows/Pages）?（Data Pages）
part????150?????10，000????25???????400
Vendor???150?????1，000???? 25???????40
Parven???13????? 15，000????300?????? 50
索引?????键尺寸???每页键数量???页面数量
（Indexes）?(Key Size)?（Keys/Page)???(Leaf Pages）
part?????4??????500???????20
Vendor????4??????500???????2
Parven????8??????250???????60
看起来是个相对简单的3表连接，但是其查询开销是很大的。通过查看系统表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理顺序存放的。parven表没有特定的存放次序。这些表的大小说明从缓冲页中非顺序存取的成功率很小。此语句的优化查询规划是：首先从part中顺序读取400页，然后再对parven表非顺序存取1万次，每次2页（一个索引页、一个数据页），总计2万个磁盘页，最后对vendor表非顺序存取1.5万次，合3万个磁盘页。可以看出在这个索引好的连接上花费的磁盘存取为5.04万次。
建议你直接用Jdbc好了，用batch，这样是最快的。
打开数据库
con.Open();
读取数据
OdbcDataReader reader = cmd.ExecuteReader();
把数据加载到临时表
dt.Load(reader);
在使用完毕之后，一定要关闭，要不然会出问题
reader.Close();
这个问题是这样的：
首先你要明确你的插入是正常业务需求么？如果是，那么只能接受这样的数据插入量。
其次你说数据库存不下了 那么你可以让你的数据库上限变大 这个你可以在数据库里面设置的 里面有个数据库文件属性 maxsize
最后有个方法可以使用，如果你的历史数据不会对目前业务造成很大影响 可以考虑归档处理 定时将不用的数据移入历史表 或者另外一个数据库。
注意平时对数据库的维护 定期整理索引碎片
时间维度分区表，然后定情按照规则将属于历史的分区数据迁移到，历史库上，写个存储自动维护分区表。
一次性插入大量数据，只能使用循环，
如：游标，while 循环语句
下面介绍While 循环插入数据，
SQL 代码如下：
IF OBJECT_ID('dbo.Nums') IS NOT NULL
DROP TABLE dbo.Nums;
GO
CREATE TABLE dbo.Nums(n INT NOT NULL PRIMARY KEY);
DECLARE @max AS INT, @rc AS INT;
SET @max = 5000000;
SET @rc = 1;
INSERT INTO Nums VALUES(1);
WHILE @rc * 2 <= @max
BEGIN
INSERT INTO dbo.Nums SELECT n + @rc FROM dbo.Nums;
SET @rc = @rc * 2;
END
INSERT INTO dbo.Nums SELECT n + @rc FROM dbo.Nums WHERE n + @rc <= @max;
--以上函数取自Inside SQL Server 2005: T-SQL Query一书。
INSERT dbo.Sample SELECT n, RAND(CAST(NEWID() AS BINARY(16))) FROM Nums
ini_set('max_execution_time',Ɔ');
$pdo = new PDO("mysql:host=localhost;dbname=test","root","123456");
$sql = "insert into test(name,age,state,created_time) values";
for($i=0; $i<100000; $i++){
$sql .="('zhangsan',21,1,-09-17')";
}
$sql = substr($sql,0,strlen($sql)-1);
var_mp($sql);
if($pdo -> exec($sql)){
echo "插入成功！";
echo $pdo -> lastinsertid();
}
试试吧。10万条1分钟多，我觉得还行
就是直接把DataSet 类型作为参数直接传递给服务端
WCF默认支持这么做，直接传Datatable不行。
你看一下 “服务引用设置”中你选的 *** 类型是什么，我选的是System.Array
字典 *** 类型是默认第一项 System.Collections.Generic.Dictionary
又是一个把自己架在火上烤的需求啊，
如果不考虑传输因素，可以调整wcf配置，提升传递的容量，如果是对象传递可能还要调整对象层次的深度
Ⅲ 大数据创业的5大要点,你知道吗
大数据是当今最热门的科技词汇，同时也是最困难的创业项目。CSC对Infochimps的收购表明，那些无法顺利拿到第二轮融资的大数据创业公司 面临着要么关张，要么被人收购的命运
Harris的观点可以归纳为五点，IT经理网摘译整理如下：
1.基础设施非常难
不仅开发基础设施技术产品很难，销售起来也很难，具体到大数据基础设施工具如Hadoop、NoSQL数据库和流处理系统则更是难上加难。客户需要大量培训和教育，付费哟娜谷需要大量支持和及时跟进的产品开发工作。
新兴的大数据创业公司还必须与那些在客户那里已经有一些知名度甚至合作项目的公司竞争，例如Cloudera、Hortonworks、10gen、亚马逊AWS、IBM、Oracle等。
反观大数据应用创业则相对简单的多，无论面向垂直行业应用还是数据可视化这样的通用大数据应用都是如此。因为这些大数据应用的价值对于客户来说更为直观，距离业务也更近，进入企业IT系统的摩擦也更小。
2.云计算是朋友
无论你是销售大数据基础设施还是应用，云计算都是更有效的业务载体。选择云计算不仅仅是在云端托管，更重要的是通过云计算向客户提供服务。你将拥有更多控制权，同时在有限的资源上优化运行也会让你对产品的理解更加透彻。
云计算也降低了潜在用户试用产品的成本和门槛，从NewRelic到亚马逊AWS都从云计算+大数据模式中获益。
3.开发者是朋友
如果你主要从事大数据分析，例如ClearStory、Platfora或者CRM营销应用，数据分析师就是你的朋友。无论那种情况，最好的办法就是围绕以开发者和市场人员为主的目标受众进行开发和营销工作，CIO反而不是很好的目标受众！
专注CIO而非开发者往往会导致你在实际签约时碰到棘手问题。围绕开发者营销的战术被很多云计算创业公司和纯大数据软件公司所采用，例如Splunk和Tableau。
再比如Infochimps和Continuuity的产品类似（两者都被迫按落云头，迫降在用户数据中心），但Continuuity完全面向开发者，这意味着能积累更多技术粉丝。
4.将数据科学家推向前台中央
这既是市场也是销售策略，数据科学家才是能够展示数据和平台威力的人，他们也是会议上最受欢迎的演讲者。
但大数据科学家也需要慎重选择传播内容。如今大家都接受了Hadoop和NoSQL，所以没必要每次开会言必称4V之类的科普。至于如何配置和集成大数据系统也只能吸引小部分听众，除非你的项目规模超大。
Cloudera比竞争对手出名的原因有很多，但其中Jeff hammerbacher绝对是一位举足轻重的人物。不要空谈大数据大数据的价值和架构，站在听众的立场说说具体能做哪些分析，如何做。
5.开源有多重要，取决于你自己
几乎所有的大数据公司都依赖开源软件，有些是“借”来的，如Hadoop、Storm以及各种数据库，有些是自行开发的，有些则是混合模式，例如在HBase上增加的一些功能应用。这些开源项目如此流行是因为社区的力量。
开源绝不是看起来那么轻松，不是说你在Github上放点代码就谈得上回馈社区了。开源的目的是将使用相同代码的人聚拢成社区，并不断改进代码。这 里与第三点中我们提到的吸引开发者有关。只有更多的用户和开发者对你产生兴趣了，在你的产品上花时间和精力了，才有可能最终掏钱。
不计其数的创业公司都将代码开源了，但那些真正能推动项目并建设社区的公司才能脱颖而出。例如Neo Technology的Neo4j、Concurrent的Casading以及10gen的MongoDB。甚至Twitter这样面向大众的公司都开源了Storm和Mesos等项目。