A. LBS数据库的架构是怎样的
架构的话有很多尝试，传统的Oracle和 Postgre用的比较广泛, 很多架构在此基础上同时应用 NoSQL。因为大多数LBS并不涉及更复杂的空间数据存储，例如多边形或者三维数据，因此，大多数generic的数据库架构都可以应用。但是，从产品核心的设计以及发展来看，如果像FourSquare(4SQ)进行数据挖掘并提供收费的数据分析服务，那么基于空间的利用文件数据结构，以空间POI为基础的NoSQL，是比较好的选择。除了其他人介绍的很多LBS，比如街旁和4SQ，应用的Mongo DB， 还有Couch DB, 根据之前来讲课的澳洲政府的一个大型空间数据库项目(集成了多种现有的空间数据库)的构架师介绍，这个项目应用了Couch DB。虽然理论上Graphic的NoSQL对于存储空间数据也有很大优势，但是毕竟相对不成熟，所以实际应用中的NoSQL还是以doc结构的Mongo和Couch为主。
如何提高命中率关键是对存储的空间数据认识程度和对用户query的类型的统计分析，并在此基础上开发出适合的算法，建立缓存或者对传统的空间索引进行组合，例如应用一些refine-filter策略。空间数据的索引与传统的索引不同，但是又部分基于传统索引的基础之上的。这里只介绍一些简单的空间索引入门算法，最后简单谈一下缓存建立的策略。
B. 大数据量高并发访问数据库结构的设计
大数据量高并发访问数据库结构的设计
如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。所以，在一个系统开始实施之前，完备的数据库模型的设计是必须的。
在一个系统分析、设计阶段，因为数据量较小，负荷较低。我们往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。
所以在考虑整个系统的流程的时候，我们必须要考虑，在高并发大数据量的访问情况下，我们的系统会不会出现极端的情况。（例如：对外统计系统在7月16日出现的数据异常的情况，并发大数据量的的访问造成，数据库的响应时间不能跟上数据刷新的速度造成。具体情况是：在日期临界时（00：00：00），判断数据库中是否有当前日期的记录，没有则插入一条当前日期的记录。在低并发访问的情况下，不会发生问题，但是当日期临界时的访问量相当大的时候，在做这一判断的时候，会出现多次条件成立，则数据库里会被插入多条当前日期的记录，从而造成数据错误。），数据库的模型确定下来之后，我们有必要做一个系统内数据流向图，分析可能出现的瓶颈。
为了保证数据库的一致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余。（例如用户表的地区，我们可以把地区另外存放到一个地区表中）如果数据冗余低，数据的完整性容易得到保证，提高了数据吞吐速度，保证了数据的完整性，清楚地表达数据元素之间的关系。而对于多表之间的关联查询（尤其是大数据表）时，其性能将会降低，同时也提高了客户端程序的编程难度，因此，物理设计需折衷考虑，根据业务规则，确定对关联表的数据量大小、数据项的访问频度，对此类数据表频繁的关联查询应适当提高数据冗余设计但增加了表间连接查询的操作，也使得程序的变得复杂，为了提高系统的响应时间，合理的数据冗余也是必要的。设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。
另外，最好不要用自增属性字段作为主键与子表关联。不便于系统的迁移和数据恢复。对外统计系统映射关系丢失（******************）。
原来的表格必须可以通过由它分离出去的表格重新构建。使用这个规定的好处是，你可以确保不会在分离的表格中引入多余的列，所有你创建的表格结构都与它们的实际需要一样大。应用这条规定是一个好习惯，不过除非你要处理一个非常大型的数据，否则你将不需要用到它。（例如一个通行证系统，我可以将USERID，USERNAME，USERPASSWORD，单独出来作个表，再把USERID作为其他表的外键）
表的设计具体注意的问题：
1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。
2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
3、对于不可变字符类型char和可变字符类型varchar都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。在设计字段的时候可以灵活选择，例如用户名、密码等长度变化不大的字段可以选择CHAR，对于评论等长度变化大的字段可以选择VARCHAR。
4、字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。
5、基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。
6、若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。
7、主键PK的取值方法，PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。
8、主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。
〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。
9、中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。
10、防止数据库设计打补丁的方法是“三少原则”
(1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；
(2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；
(3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。
数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性)的E--R图，要好得多。
提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数就会越少。
提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。
“三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。
11、在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：
(1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方式用编程语言计算处理完成之后，最后才入库追加到表中去。
(3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
(4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
(5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。
总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。
主键设计：
1、不建议用多个字段做主键，单个表还可以，但是关联关系就会有问题，主键自增是高性能的。
2、一般情况下，如果有两个外键，不建议采用两个外键作为联合住建，另建一个字段作为主键。除非这条记录没有逻辑删除标志，且该表永远只有一条此联合主键的记录。
3、一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。
主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与、外键的配对，表示实体之间的连接。
C. gp数据库全称是什么
gp数据库全称是Creenplum。
GP数据库是业界最快最高性价比的关系型分布式数据库，它在开源的PostgreSQL的基础上采用MPP架构（Massive Parallel Processing，海量并行处理），具有强大的大规模数据分析任务处理能力，其主要关注在数据仓库和商业智能方面。
分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。
GP数据库特点：
1.greenplum是一个关系型数据库集群，是由数个独立的数据库服务组合成的逻辑数据库。
2.greenplum采用Shared-Nothing架构，整个集群由很多个数据节点（Segment Sever）和控制节点（master server）组成，其中每个数据节点上可以运行多个数据库。
简单来说，Shared-Nothing是一个分布式的架构，每个节点相对独立。在典型的Shared-Nothing中，每一个节点上所有的资源（CPU，内存，磁盘）都是独立的，每个节点都只有全部数据的一部分，也只能使用本节点的资源。
D. 数据库软件架构设计的要点
数据库软件架构设计，要关注哪些要点？
方法/步骤
在IT系统架构设计中，数据库的设计，占据着很重要的地位。那么主要面临哪些问题，需要考虑哪些因素呢？
面对数据量过大的问题，通常需要通过分片技术来解决，目前应用较多的是哈希分片。
因为通过范围简单分片，可能造成各库的压力不均；而统一路由，会增加访问前查询的压力。
通过主从复制的分组，既可以解决可用性的问题，还可以实现一定的性能提升。
数据库的软件架构设计，要关注可用性、性能、一致性和扩展性四个方面。
解决可用性的主要思路就是冗余——站点冗余、服务冗余、数据冗余……
冗余带来的可用性问题，就是数据一致性的问题，要保证数据一致性，可以考虑双写同步。
扩展性能一般有三种方式——增加索引、增加从库和增加缓存，要结合实际情况分析应用。
架构的设计是一个动态优化的过程，要综合考虑几个方面的因素，寻找合适的平衡点。
E. 目前大型数据库应用系统采用什么体系结构
从数据库最终用户角度看，数据库系统的结构分为单用户结构、主从式结构、分布式结构、客户/服务器、浏览器/应用服务器/数据库服务器多层结构。这是数据库外部体系结构。
物理存储结构、逻辑存储结构、内存结构和实例进程结构。这是内部体系结构
F. 什么叫做数据库的“三层架构”
三层架构可以说是一种设置模式，他的作用只是让我们更加有效的利用资源，有利于以后的修改和查看，依次分为视图层，逻辑层，数据层；
试图层顾名思义就是我们所看到的，他的原代码并没有关于处理和连库等代码，只是简单的跳转页面，我们没有办法看到真正的代码；
逻辑层就是我们从页面层发回的问题等请求，从字面意思来看，你可以将他视为一个过渡层，只是连接是图层和数据层；进行一些连库，删除数据等操作了；从试图层跳转过来的问题在这里进行处理，并提交给数据层，再返回页面层共读者查看；
数据层就不用说了吧！这里存放着所有的数据也就是一个工程的大本营一样；
三层架构已经不仅仅属于.net了，他是一种设计形式，从某种意义上来说，所有的开发设计几乎都已经以三层架构为基础，三层架构及有效的处理问题，将数据和试图也有效的分开，这样防止耦合度过高，有利于处理和修改，（你不会是想将代码全部写在视图页面上，这样有一个小小的变动，我们就要翻看几十万句代码，从中找出，那我要替你的眼睛抱不平了）当你将程序做好后，从这台机子移动到另一台机子时，大大减少了出错的问题；
通俗一点就是，这样看上去很有层次感，我们查看时，可以减少时间的浪费，也不用在代码堆里翻来覆去找不到北
G. 数据库的问题
数据库，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、截取、更新、删除等操作。
所谓“数据库”系以一定方式储存在一起、能予多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。[1]
数据库管理系统
主条目：数据库管理系统
数据库管理系统（英语：Database Management System，简称DBMS）是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类，例如关系式、XML；或依据所支持的计算机类型来作分类，例如服务器群集、移动电话；或依据所用查询语言来作分类，例如SQL、XQuery；或依据性能冲量重点来作分类，例如最大规模、最高运行速度；亦或其他的分类方式。不论使用哪种分类方式，一些DBMS能够跨类别，例如，同时支持多种查询语言。[1]
类型
关系数据库
MySQL
MariaDB（MySQL的代替品，英文维基网络从MySQL转向MariaDB）
Percona Server（MySQL的代替品·）
PostgreSQL
Microsoft Access
Microsoft SQL Server
Google Fusion Tables
FileMaker
Oracle数据库
Sybase
dBASE
Clipper
FoxPro
foshub
几乎所有的数据库管理系统都配备了一个开放式数据库连接（ODBC）驱动程序，令各个数据库之间得以互相集成。
非关系型数据库（NoSQL）
主条目：NoSQL
BigTable（Google）
Cassandra
MongoDB
CouchDB
键值（key-value）数据库
Apache Cassandra（为Facebook所使用）：高度可扩展
Dynamo
LevelDB（Google）[1]
数据库模型
对象模型
层次模型（轻量级数据访问协议）
网状模型（大型数据储存）
关系模型
面向对象模型
半结构化模型
平面模型（表格模型，一般在形式上是一个二维数组。如表格模型数据Excel)
架构
数据库的架构可以大致区分为三个概括层次：内层、概念层和外层。
内层：最接近实际存储体，亦即有关数据的实际存储方式。
外层：最接近用户，即有关个别用户观看数据的方式。
概念层：介于两者之间的间接层。
数据库索引
主条目：数据库索引
数据索引的观念由来已久，像是一本书前面几页都有目录，目录也算是索引的一种，只是它的分类较广，例如车牌、身份证字号、条码等，都是一个索引的号码，当我们看到号码时，可以从号码中看出其中的端倪，若是要找的人、车或物品，也只要提供相关的号码，即可迅速查到正确的人事物。
另外，索引跟字段有着相应的关系，索引即是由字段而来，其中字段有所谓的关键字段（Key Field），该字段具有唯一性，即其值不可重复，且不可为"空值（null）"。例如：在合并数据时，索引便是扮演欲附加字段数据之指向性用途的角色。故此索引为不可重复性且不可为空。
数据库操作:事务
主条目：数据库事务
事务（transaction）是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。 事务的ACID特性：
基元性（atomicity）
一致性（consistency）
隔离性（isolation）
持续性（rability）
事务的并发性是指多个事务的并行操作轮流交叉运行，事务的并发可能会访问和存储不正确的数据，破坏交易的隔离性和数据库的一致性。
网状数据模型的数据结构 网状模型 满足下面两个条件的基本层次联系的集合为网状模型。 1. 允许一个以上的结点无双亲； 2. 一个结点可以有多于一个的双亲。[2]
参见
数据库理论
信息技术审核
LDAP（轻量级数据访问协议）
SQL（结构化查询语言）
H. 数据库 数据
简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。
数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。
单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。
“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。
“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。
“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。
数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。
补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。
1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。
2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。
3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。
是否可以解决您的问题？
I. 大数据正在如何改变数据库格局
大数据正在如何改变数据库格局
提及“数据库”，大多数人会想到拥有30多年风光历史的RDBMS。然而，这可能很快就会发生改变。
一大批新的竞争者都在争夺这一块重要市场，他们的方法是多种多样的，却都有一个共同点：极其专注于大数据。推动新的数据迭代衍生品大部分都是基于底层大数据的3V特征：数量，速度和种类。本质上来讲，今天的数据比以往任何时候都要传输更快，体积更大， 同时更加多样化。这是一个新的数据世界，换言之，传统的关系数据库管理系统并没有真正为此而设计。“基本上，他们不能扩展到大量，或快速，或不同种类的数据。”一位数据分析、数据科学咨询机构的总裁格雷戈里认为。这就是哈特汉克斯最近发现。截至到2013年左右，营销服务机构使用不同的数据库，包括Microsoft SQL Server和Oracle真正应用集群（RAC）的组合。“我们注意到，数据随着时间的增长，我们的系统不能足够快速的处理信息”一位科技发展公司的负责人肖恩说到。“如果你不断地购买服务器，你只能继续走到这幺远，我们希望确保自己有向外扩展的平台。”最小化中断是一个重要的目标，Iannuzzi说到，因此“我们不能只是切换到Hadoop。”相反，却选择了拼接机器，基本上把完整的SQL数据库放到目前流行的Hadoop大数据平台之上，并允许现有的应用程序能够与它连接，他认为。哈特汉克斯现在是在执行的初期阶段，但它已经看到了好处，Iannuzzi说，包括提高容错性，高可用性，冗余性，稳定性和“性能全面提升”。一种完美风暴推动了新的数据库技术的出现，IDC公司研究副总裁Carl Olofson说到。首先，“我们正在使用的设备与过去对比，处理大数据集更加快速，灵活性更强”Olofson说。在过去，这样的集合“几乎必须放在旋转磁盘上”，而且数据必须以特定的方式来结构化，他解释说。现在有64位寻址，使得能够设置更大的存储空间以及更快的网络，并能够串联多台计算器充当单个大型数据库。“这些东西在不可用之前开辟了可能性”Olofson说。与此同时，工作负载也发生了变化。10年前的网站主要是静态的，例如，今天我们享受到的网络服务环境和互动式购物体验。反过来，需要新的可扩展性，他说。公司正在利用新的方式来使用数据。虽然传统上我们大部分的精力都放在了对事务处理 – 销售总额的记录，比如，数据存储在可以用来分析的地方 – 现在我们做的更多。应用状态管理就是一个例子假设你正在玩一个网络游戏。该技术会记录你与系统的每个会话并连接在一起，以呈现出连续的体验，即使你切换设备或各种移动，不同的服务器都会进行处理，Olofson解释说。数据必须保持连续性，这样企业才可以分析问题，例如“为什么从来没有人穿过水晶厅”。在网络购物方面，为什么对方点击选择颜色后大多数人不会购买某个特殊品牌的鞋子。“以前，我们并没试图解决这些问题，或者我们试图扔进盒子也不太合适”Olofson说。Hadoop是当今新的竞争者中一个重量级的产品。虽然他本身不是一个数据库，它的成长为企业解决大数据扮演关键角色。从本质上讲，Hadoop是一个运行高度并行应用程序的数据中心平台，它有很强的可扩展性。通过允许企业扩展“走出去”的分布方式，而不是通过额外昂贵的服务器“向上”扩展，“它使得我们可以低成本地把一个大的数据集汇总，然后进行分析研究成果”Olofson说。其他新的RDBMS的替代品如NoSQL家族产品，其中包括MongoDB -目前第四大流行数据库管理系统，比照DB引擎和MarkLogic非结构化数据存储服务。“关系型数据库一直是一项伟大的技术持续了30年，但它是建立在不同的时代有不同的技术限制和不同的市场需求，”MarkLogic的执行副总裁乔·产品帕卡说。大数据是不均匀的，他说。许多传统的技术，这仍然是一个基本要求。“想象一下，你的笔记本电脑上唯一的程序是Excel”帕卡说。“设想一下，你要和你的朋友利用网络保持联系 – 或者你正在写一个合约却不适合放进行和列中。”拼接数据集是特别棘手的“关系型，你把所有这些数据集中在一起前，必须先决定如何去组织所有的列，”他补充说。“我们可以采取任何形式或结构，并立即开始使用它。”NoSQL数据库没有使用关系数据模型，并且它们通常不具有SQL接口。尽管许多的NoSQL存储折中支持速度等其他因素，MarkLogic为企业定身量做，提供更为周全的选择。NoSQL储存市场有相当大的增长，据市场研究媒体，不是每个人都认为这是正确的做法-至少，不是在所有情况下。NoSQL系统“解决了许多问题，他们横向扩展架构，但他们却抛出了SQL，”一位CEO-Monte Zweben说。这反过来，又为现有的代码构成问题。Splice Machine是一家基于Hadoop的实时大数据技术公司，支持SQL事务处理，并针对OLAP 和OLAP应用进行实时优化处理。它被称为替代NewSQL的一个例子，另一类预期会在未来几年强劲增长。“我们的理念是保持SQL，但横向扩展架构”Zweben说。“这是新事物，但我们正在努力试图使它让人们不必重写自己的东西。”深度信息科学选择并坚持使用SQL，但需要另一种方法。公司的DeepSQL数据库使用相同的应用程序编程接口（API）和关系模型如MySQL，意味着没有应用变化的需求而使用它。但它以不同的方式处理数据，使用机器学习。DeepSQL可以自动适应使用任何工作负载组合的物理，虚拟或云主机，该公司表示，从而省去了手动优化数据库的需要。该公司的首席战略官Chad Jones表示，在业绩大幅增加的同时，也有能力将“规模化”为上千亿的行。一种来自Algebraix数据完全不同的方式，表示已经开发了数据的第一个真正的数学化基础。而计算器硬件需在数学建模前建成，这不是在软件的情况下，Algebraix首席执行官查尔斯银说。“软件，尤其是数据，从未建立在数学的基础上”他说，“软件在很大程度上是语言学的问题。”经过五年的研发，Algebraix创造了所谓的“数据的代数”集合论，“数据的通用语言”Silver说。“大数据肮脏的小秘密是数据仍然放在不与其他数据小仓融合的地方”Silver解释说。“我们已经证明，它都可以用数学方法来表示所有的集成。”配备一个基础的平台，Algebraix现在为企业提供业务分析作为一种服务。改进的性能，容量和速度都符合预期的承诺。时间会告诉我们哪些新的竞争者取得成功，哪些没有，但在此期间，长期的领导者如Oracle不会完全停滞不前。“软件是一个非常时尚行业”安德鲁·门德尔松，甲骨文执行副总裁数据库服务器技术说。“事情经常去从流行到不受欢迎，回再次到流行。”今天的许多创业公司“带回炒冷饭少许抛光或旋转就可以了”他说。“这是一个新一代孩子走出学校和重塑的东西。”SQL是“唯一的语言，可以让业务分析师提出问题并得到答案，他们没有程序员，”门德尔松说。“大市场将始终是关系型。”至于新的数据类型，关系型数据库产品早在上世纪90年代发展为支持非结构化数据，他说。在2013年，甲骨文的同名数据库版本12C增加了支持JSON（JavaScript对象符号）。与其说需要一个不同类型的数据库，它更是一种商业模式的转变，门德尔松说。“云，若是每个人都去，这将破坏这些小家伙”他说。“大家都在云上了，所以在这里有没有地方来放这些小家伙？“他们会去亚马逊的云与亚马逊竞争？” 他补充说。“这将是困难的。”甲骨文有“最广泛的云服务”门德尔松说。“在现在的位置，我们感觉良好。”Gartner公司的研究主任里克·格林沃尔德，倾向于采取了类似的观点。“对比传统强大的RDBMS，新的替代品并非功能齐全”格林沃尔德说。“一些使用案例可以与新的竞争者来解决，但不是全部，并非一种技术”。展望未来，格林沃尔德预计，传统的RDBMS供货商感到价格压力越来越大，并为他们的产品增加新的功能。“有些人会自由地带来新的竞争者进入管理自己的整个数据生态系统”他说。至于新的产品，有几个会生存下来，他预测“许多人将被收购或资金耗尽”。今天的新技术并不代表传统的RDBMS的结束，“正在迅速发展自己”IDC的Olofson。赞成这种说法，“RDBMS是需要明确定义的数据 – 总是会有这样一个角色。”但也会有一些新的竞争者的角色，他说，特别是物联网技术和新兴技术如非易失性内存芯片模块（NVDIMM）占据上风。以上是小编为大家分享的关于大数据正在如何改变数据库格局的相关内容，更多信息可以关注环球青藤分享更多干货