国内做分布式数据库开发的现状如何(分布式数据库适用于大数据分析吗)

基础软件创业其实我觉得是个好生意，尤其是数据库，但是前提是确实在技术上有所创新，这么一来技术壁垒就巨高，这就是护城河。如果只是去模仿Oracle，是没有太大前途的（当然靠关系那种就另说了，反正我本人不认为这样是正确的价值观），想想人家O记在这个领域做了30年，你走人家的老路凭什么干得动人家？目前来说我觉得之所以国内还没有太大成功的公司涌现说到底还是因为技术不行或者路子不对或者客户的历史包袱太重，拿个Hadoop改改就是大数据了吗？真正的OLTP业务敢碰吗？所以就造成了做项目挣快钱攒方案搞数据分析的公司扎堆，真正在OLTP端的创新没人敢碰。另外一个重要的问题就是，国内几乎没人懂开源。最近几年重要的基础软件创新都在开源社区，比如Docker/Kubenetes(Mesos)/Spark凭一个公司的力量是很难跟上社区的发展速度的。国内的大多数开源项目不管是代码质量，用心程度，设计的视野上都太弱了，连最基本的英文交流都很少有开源项目注意，更不用说生态了。不过，还是有希望的，至少学术界最近几年的进展，让我们看到了在分布式OLTP系统(NewSQL)上的一些希望，而且这块在全球范围内都是一个蓝海。基于这个背景，我们创立了PingCAP，从零开始抛开一切历史包袱去实现一个全新的数据库TiDB，TiDB的目标就是瞄准世界顶级的通用分布式数据库开源项目和未来的行业标准去的。虽然这个东西确实很难,但我也不觉得我们会比硅谷的顶级基础软件公司差:)，不客气的讲，我们在这个领域也远远走到了各个友商的前面，另外一方面如果不难也没有做它的价值，如果未来的数据库还是需要像现在分库分表中间件Oracle，我觉得就太无趣了。就说一个Cloud-Native，目前来说基本没有OLTP的数据库能搞定。

本质区别。

项目是数据、文档、类库、和代码等vfp对象的一种集合。数据库是一种文件，可以包含表、本地视图、远程视图、到远程数据源的链接和存储过程等vfp对象。

内容拓展:数据库设计器的使用:1打开与关闭数据库2表的添加3新建表4打开多个表5移除表6编辑表7整理数据库设计器窗口。

进入信息化市场，数据库的重要性日益凸显，目前数据库主要分为数据库产品、数据库服务和数据库支撑体系。我国数据库产品以关系型为主，非关系型数据库以键值型数据库为主。

金融、电信、政务、制造和互联网为我国数据库应用最为广泛的领域，但是它们的应用特点各不相同。未来，在企业崛起、国家利好政策和资本关注等因素推动下，我国数据库行业市场规模有望接近7百亿元。

本文核心数据：数据库产品分布、数据库市场规模

数据库主要分为三大类

在信息化时代，数据库已经逐渐应用于各行各业。数据库主要分为三大类：数据库产品、数据库服务和数据库支撑体系。

数据库产品主要由关系型数据库、非关系型数据库、混合型数据库及数据库周边工具构成。

数据库服务是指围绕数据库的咨询规划、实施部署和运维运营等环节，为数据库系统的正常、高效、持续、安全使用提供信息技术服务工作。

数据库支撑体系由从事数据库学术研究、人才培养、开源社区、评测认证等工作的相关主体共同构成。

数据库产品以关系型为主，非关系型数据库以键值型数据库为主

目前，我国数据库产品主要以关系型为主，非关系型及混合型数据库较少。截止2021年6月，我国关系型数据库共有81个，非关系型数据库共有54个。在非关系型数据库中，键值型数据库占比最高，占非关系型数据库的926%。

五大行业应用较广，应用特点各不相同

在我国，金融、电信、政务、制造和互联网为我国数据库应用最为广泛的领域，但是它们的应用特点各不相同，金融、电信的IT监管环境较为严格、数据业务较为复杂、核心数据业务呈现“强事务”的特点，而对成本敏感度较低。与之相反的是，互联网领域对IT监管环境较弱，但是对成本敏感度较高。

市场规模有望接近7百亿元

虽然目前我国数据库较欧美国家发展规模较小，2020年我国数据库市场规模约占全球数据库市场规模的52%，约为2409亿元。

但是，随着我国浙江智臾、涛思数据等为代表的时序数据库企业不断涌现，同时得到政策政策以及资本关注，我国数据库行业有望迎来新一轮的增长，2025年我国数据库市场规模有望接近7百亿元。

业务和系统开发领域绝对不能容许设计上的重大失误。可是，很多开发人员却因为不了解设计步骤而恰恰轻视乃至完全忽略了整个设计过程。而实际上，我们中的大多数人也确实缺乏必要的有关技能和知识，结果令我们往往“旁路”了项目开发中最重要的阶段。说真的，有本事敢直接绕过设计阶段的人还没诞生呢。如果我们不花点时间创建一个逻辑模型，那么要实现一套高效和优秀的设计是完全不可能的。略过设计步骤会产生大量的错误，而这些错误又会令我们耗费大量的时间在发现它们的时候反复调试和纠正。下面我就大致讨论下设计的逻辑和物理模型，然后引领读者经过逻辑模型的创建全过程。本文是有关主题系列的开篇，在后续的第2部分里，我会根据已经发现的缺陷修改我们的原始设计。数据库的设计方法在对数据库项目的需求着手评估和分析周，接下来的一步就是设计出一套方案帮助你达到项目的要求和目标。在开发领域这一步骤被称做数据库设计方法。它是一种结构化的措施，支持设计流程同时还包括了诸如公司业务流程、规定和文档等一系列工具。步步进阶的整套流程帮助开发人员计划、管理和控制设计及其实现从而高效地完成任务。这意味着，你拥有一整套方法，也就是按照特定顺序安排的项目列表，这些方法指引你经过数据模型创建的全过程。请不要错误地把这个过程理解为平常的过程，实际上它是完全必要的阶段。你应该从完全理解数据和用户需求这一目的出发研究该过程。每一个项目无论其规模大小都能从以下三种模型中获益：概念：明确和说明创建数据全局视图的主要对象，同时辅以一定的轻微细节。许多企业都局限于特定的数据库管理系统（DBMS），所以这一步可以忽略或者放到逻辑模型一组。逻辑：构造采用特定数据的模型，但还不用考虑最终保存数据以及运营应用程序的具体数据库系统。由于SQL Server是一种关系型数据库管理系统（RDBMS），所以我们要依赖于实体关系模型（ER：Entity-Relationship）。在这一阶段你必须明确实体、关系、属性并对你的数据实行规格化。逻辑模型建立在数据集合的基础之上。为了更深入地了解ER模型，不不妨访问下ITS数据库服务网站或者参考Mapping an ER Model to the Relational Model Web site（是一个PDF文件）。物理：根据所采用的具体RDBMS设计实现逻辑模型的具体模型。在这一阶段，你需要说明数据表、索引等数据库对象，而物理模型就是根据数据表建立的。建立逻辑模型的真实用意无非是为了确认应用程序能满足最终的需求（包括输入和输出两方面）。换句话说，逻辑模型必须能产生所有已知的报告、查询等结果。此外，用户还应该能够以合理的方式输入和 *** 作数据。一旦逻辑模型到位，你就应开始把你所了解的情况应用到项目的物理需求方面——比如说——物理模型。图A就描述了逻辑和物理模型在这一阶段的差别。图A　逻辑和物理数据模型逻辑模型的实现目前阶段的所谓“实现”其实就是完成逻辑模型的组件。在明确了实体、关系和属性的情况下，你应该揭示出那些在工作环境下可能会产生问题的缺陷：缺少的实体表示同一概念实体的多个实体需要额外实体来解决问题的多对多关系Aggregator：一家俱乐部，其成员可以享受打折服务。Corporate：代表其职员下定单的公司。它们不能享受的打折优不过需要获得旅行社的全方位服务支持。比如说，旅行社必须帮助它们解决一些诸如取消计划、飞机票订位过多等方面的问题。企业客户总是一样的而旅行者只能是其职员。Retail：不能享受任何折扣优惠的单独客户。这时，你应该准备定义应用程序的主要对象或者实体。为了针对客户类型应用以上的业务规则，你可能会把每一种客户类型当作单独的实体，如表A所示。数据类型和其他信息都是针对SQL Server考虑的。表A　定义应用实体看图B，你可以简化当前的模型：客户订单。某种特定类型的客户。图B不同实体之间的关系正如我们在上面所提到的那样，业务规则要求我们对客户实现区别对待。结果，客户不能总是具有同样的属性。我们的第1个解决方案是创建一个数据表，其中包含了各类客户的特定属性。这一原始设计带来了下列问题：所有的客户数据表都采用系统生成的主键，大致以种子值1开始递增。那就是说，你完全会遭遇重复的ClientID值。结果我们就无法恰当地把每一定单关联到特定的客户，因为每一客户表都包含了重复的值。因为每一客户表重复公共字段（如ClientID、ClientName、Address和Telephone）而产生了一些冗余的属性。客户会有更多的地址吗？也许他们会具有一个当地地址和一个付费的单位地址。客户只有一个电话号码？也许你应该列出多个电话号码乃至传真号码。有必要根据客户的类型来标识定单吗？显然你不能。找出和解决设计问题你首先采取的行动可能和我们用的不同，但那还不是关键的问题。最重要的是你可能没有认识的到设计中隐藏的问题。在后续的文章里我会采用已知的、业已得到证明的方法来寻找和解决设计问题，免得它们在今后的工作中引出不少漏子。

数据库镜像是将数据库事务处理从一个数据库移动到不同环境中的另一个数据库中 镜像的拷贝是一个备用的拷贝 不能直接访问 它只用在错误恢复的情况下 Oracle数据库与MSSQL数据 *** 作上有很大的不同 但是 在镜像 *** 作方面有类比的地方 这篇文章关于MSSQL数据库镜像在Oracle数据库中是如何实现的 它们之间存在哪些差异呢 首先 微软SQL数据库中的镜像数据库类似于Oracle数据库中的备用数据库 我说的只是类似 确切的说 我们需要考虑不同数据库在自己体系中的差异 MSSQL作为一个实例来 *** 作 一个实例包含几个数据库 你首先要登录一个实例 然后选择哪个数据库作用于该实例 而在Oracle数据库中 简单模式(忽略RAC)就只有一个数据库与一个实例相联系 因此 可以这么说 在Oracle数据库中 备份数据库(standby database)就完全是主数据库的快照 而在MSSQL中 镜像数据库仅仅是选择的那个数据库的备份 但没有包括代理 登录 任务(这些或者更多的数据库项目需要单独在数据库镜像上创建或者复制)这些外部数据项 在服务器数量上 Oracle的主数据库和备用数据库配置最小需要 台 在MSSQL中 最小数据是 个或 个 根据你所选择的高可用性 高安全性 高性能方式所决定 高可用性方式 这个 *** 作模式选项允许你在两台服务器上同步事务写入 并支持自动错误恢复 要使用这个选项 你必须还要使用一个证人服务器 高保护方式 这个选项可以让你在两台服务器上同步事物写入 但是错误恢复是手工的 因为自动的错误恢复不是这个选项的一部分 所以也不会用到证人服务器 高性能方式 这个选项不关心两台服务器上的写入是否是同步的 因此在性能上有所提高 当使用这个选项的时候 你只能假设镜像服务器上的所有事情都是成功完成 这个选项只允许手工的错误恢复 因此不会用到证人服务器 为了保证故障自动恢复 就需要有第三台服务器 可以称之为目击者(另外两个就是主数据库和镜像数据库) 你可以将这个目击者当作群集中的一个成员 它实现了 比 投票的能力 当我的一个组件不可达 并因此需要进行错误恢复的时候 证人服务器只有在你想实现自动错误恢复的时候才需要用到 在Oracle数据的一个事务中 日志缓冲器在废数据写入数据文件(忽略write ahead情况)前被刷新或者写入到redo日志中 这种刷新或者写入到redo日志的行为是有必要的 如像实例失败(使用前滚和回滚恢复过程)这样的事件发生时 MSSQL也承认将日志缓冲器写入到磁盘的重要性 不过这里称之为硬化(hardening) 首先将事务日志缓冲器的信息写入到磁盘或者硬化 接着将日志记录块发送到镜像数据库中 镜像数据库接收到该日志记录块后 将之存入到某个缓冲器中 随后依次硬化该日志记录块 当数据发生变化时 MSSQL数据库如何保持主数据库和镜像数据库的一致性呢Oracle用户非常熟悉SCN 而MSSQL用户通过使用mirroring_failover_lsn机制(粗略来讲就是一个日志序列号) MSSQL与Oracle不同 MSSQL将事务分离(两个事务在两个机器上) 而不是一个分布式事务(在自身提交前需要远程等待提交) 另外一个相似点 但稍微有些畸变的反射就是redo日志和事务日志 在Oracle中 完成的redo日志将被发送到远程的服务器中 将完成的 redo日志应用到备份数据中去 在MSSQL中 事务日志没有被传输 但是就像我以上提到的 日志缓冲器数据发送到网络上 这就导致另外一个镜像反射 备份和恢复模式 在Oracle中 当你处于归档模式或者非归档模式的时候 这些 *** 作是内定的 如果归档redo日志被传输或者提交到一个远程的服务器 那么主数据库明显就是在归档模式下 那些文件就是这么产生的 运行在这种模式下 允许有少量的数据丢失 因为在发生故障(无论什么样的故障)前 恢复能够在任意一个点上执行 在MSSQL中是类似的 但是有三种状态需要选择 《SQL Server联机丛书》 像许多其它的在线资源一样 讲述了在使用MSSQL时 种恢复模式的不同点 快速的比较有 MSSQL完整模式对应于 Oracle中的归档模式;简单模式对应于非归档模式;bulk模式与使用直接路径插入 添加提示 或者与nologging模式 *** 作类似 根据以上三种模式(这三种模式很容易转换 不需要关机或者重启)的描述以及日志缓冲器和归档redo日志的讨论中 很容易断定在MSSQL中进行数据库的镜像需要将数据的回复模式设置成完全模式(full model) 简单模式(Simple model)或许也能行 但是这种模式下维持事务日志中的小部分数据 在备份中 如果在日志被删节了 整个镜像过程也就破环了 因为当你在将事务发送到镜像数据库中的时候 如果日志被删节了 这个过程就不能完成 说到数据库被破坏该怎么办呢这正是镜像(或者说备份)的主要目的 当主数据库断开或者说遇到故障时候我们希望系统能回到镜像前或者备份前的状况去 这如何才能实现呢我们能自动实现或者手动实现 想实现这些 需要一些已经完成的设置 在MSSQL中 自动故障恢复 回到原来状态需要在HA模式 事务安全是full 数据传输是同步 有目击服务器的情况下 这种模式下运行还需要使用企业版的数据库系统 高安全性和高性能在标准版的情况下也能实现 MSSQL还有其它版本的选择 但是这些并不如Oracle的反射 干净 这些版本包括 Developer Workgroup 和 SQL Express 举个例子 目击服务器能够是任何的版本 但是如果你想给镜像服务器做一个快照 那么你就需要企业或者开发版的了 ( lian )在设置伙伴(partner 通常有主数据库和镜像数据库组成)过程中 他们的恢复状态开始起作用 通过使用相同的名字 镜像在远程/镜像服务器上建立(使用配置数据库镜像安全向导是最简单的方法)起来 并且镜像数据库被设置成NORECOVERY 通常它是恢复(recovering)状态的 在 MSSQL中 恢复数据库是没有的 因此没有进行上述的设置 是不能被其他用户当作只读数据库来使用的 为了避免这个中缺陷 你可以给镜像做一个快照 使得该 影像 对用户可见 正如我上述所提到的那样 这需要你的数据库版本是企业(或者开发)版 这就意味着用户需要有快照数据库的知识 知道如何进入存储它 如何告诉应用程序使用哪个数据库 惯例上来说 配置文件使用的 NET环境 你能建立一个主数据库和一个故障回滚的辅数据库 如果在Oracle中配置过备份数据库 你就会觉得这很类似 lishixinzhi/Article/program/SQLServer/201311/22292

以上就是关于国内做分布式数据库开发的现状如何(分布式数据库适用于大数据分析吗)全部的内容，包括:国内做分布式数据库开发的现状如何(分布式数据库适用于大数据分析吗)、在达芬奇中,数据库与项目工程的区别、数据库的发展前景怎么样等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！