如何选择数据库 大概服务200人左右

其实你要考虑数据库要怎么用，数据库不可能像EXCEL,WORD等每个人都直接用的。

一版情况下，你们需要买一个软件，例如CRM（客户关系管理系统），大家都用这个系统，数据保存在数据库里面，可以随时通过查询数据。

如果单纯给你各数据库，你不可能直接用的。

具体要用什么数据库，要看你购买的软件支持什么数据库，现在最常用的是ORACLE，SQL server ,DB2，mysql 等等

如何选择数据库

柳树

公众号：柳树的絮叨叨

关注他

30 人赞同了该文章

我们正在做一个电子书小程序。

10 层次模型数据库

用户购买，生成订单，订单详情里有用户购买的电子书：

一层一层铺开，一对多，这是「层次模型数据库」（Hierarchical Database）。

20 网状模型数据库

一笔订单可以购买多本电子书，一本电子书也可以被多笔订单购买：

这就形成了「多对多」的「网状模型数据库」（Network Database）。

上面讲的两种数据库，也许你听都没听过。

我们用的，是「关系模型」，而非上面的「层次模型」或者「网状模型」。

为什么？

你会说，这样不方便遍历所有订单。

并不会，再加一个根节点就好：

你会说，这样查找效率很低。

也不会，因为可以优化下数据结构，比如换成 B+ 树。

为什么我们从一开始就在用「关系模型数据库」？

30 关系模型数据库

无论是层次模型还是网状模型，程序员看到的，都是实实在在的物理存储结构。

查询时，你要照着里面的数据结构，用对应的算法来查；

插入时，你也要照着数据结构，用对应算法来插入，否则你就破坏了数据的组织结构，数据也就坏掉了。

因为我们都没用过前面两种数据库，所以觉得「关系模型数据库」（以下简称 RDB）的一切都理所当然，但其实，它做出了一个革命性的变革：

用逻辑结构（logical representation of data）代替物理结构（physical representation of data）

所谓「逻辑结构」，也就是我们经常看到的「表格」，User 是一张表格，Order 是一张表格，Book 又是一张表格，它们之间的关系，用 id 来关联，这些 id，可能是 number 类型，也可能是 string 类型

但你看到的，不一定就是实际的，你看到的只是让你方便理解的「逻辑结构」，真实数据自然不是这样按表格来存储，表格无异于一个数组，数组查询是很慢的。

真实的「物理结构」，也许还是像「层次模型」和「网状模型」一样，是复杂的数据结构。

但到底是怎样的数据结构，你都无需关心，你只需把它想象成一张「表」去 *** 作，就连可视化工具，都会帮你把数据可视化成表，来方便你理解。

这个观念的提出，来自于 1970 年 Codd 的一篇论文，A Relational Model of Data for Large Shared Data Banks：

Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation) 

Activities of users at terminals and most application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed 

—— Codd

Codd 的这种思想，其实就是经济学里提到的：分工产生效能。

程序员们不需要直接和物理结构打交道，只负责告诉数据库，他想做什么，至于数据是如何存储、如何索引，都交给数据库，最终他们看到的就是一张张特别直观、特别好理解的 excel 表格。

而数据库则把维护物理结构的复杂逻辑，交给了自己， 对程序员屏蔽了复杂的实现细节。

开发时写的代码少了，耦合性降低了，数据也不容易损坏，也就提高了生产效率（productive）。

一切能用同样的耗能，带来更多效能的技术，都会被广泛使用。

NoSQL

那后来为什么又有了 NoSQL 呢？

在 RDB 被发明的时代，软件多用于大型企业，比如银行、金融等等，人们对数据的要求非常纯粹：准确、可靠、安全，让数据按照期望，正确的写入，不要给老子算错钱就好，于是有了具有 ACID 特性的事务：原子性、一致性、隔离性和持久性。

那时候用网络的人很少，通过终端来访问客户端的人，更少，自然的，数据库的数据量和访问量都跟现在没法比，一台机器，足矣，最多再来个一主多从：

后来，你知道的，每个人手里都有个手机，每分每秒，都有成千上万的数据，写入你的数据库、从你的数据库被查出，于是有了「分布式」，有了 BASE 和 CAP。这时候，RDB 就会发现，自己之前的那一套 ACID，竟然有点作茧自缚了：

为了保证事务的隔离性，要进行加锁，在分布式的环境下，就要对多台机器的数据进行加锁；

为了保证事务的原子性，在机器 A 的 *** 作和在机器 B 的 *** 作，要么一起成功，要么一起失败；

…

这些都要去不同节点的机器进行通讯和协调，实现起来非常复杂，而且要付出更多的网络 IO，影响性能。

ACID 在分布式系统上实现起来就会变得难以实现，即使实现了，也要付出很大的性能成本，于是才有了后来的各种「分布式一致性协议」，Paxos、Raft、2PC …… 而 Mysql 也提供了各种方案来实现分布式，当然，这些方案自然是很复杂的，比如 「NDB Cluster」 ：

而 NoSQL 则没有这么多承诺，它的一致性，一般都是最终一致性，当然你可以选择强一致，那自然就要付出点性能作为代价，当然你还可以弱一致，这样会更不安全，但是更快，一切取决于你对数据的要求。

除此之外，RDB 的「数据库范式」（Database Schema），也成了限制扩展性的瓶颈。为了避免数据冗余导致的各种问题（占用空间、删除异常、更新异常等等），我们在设计关系模型时，通常都是按照最小单位来设计的。

什么叫最小单位，比如用户有地址和爱好，那么在正确设计的关系模型（比如 3NF）里，这就是三张表：

如果这三张表被分散在不同的机器，那进行关联查询时，就需要多次跨机器的通讯；

而对于 NoSQL，这三类信息，都可以利用 Json 格式的数据，将它们存放在一起：

完整的存储进去，完整的取出来，不需要额外的 *** 作。

NoSQL 比 RDB 有更强的扩展性，可以充分利用分布式系统来提升读写性能和可靠性。

这不是谁设计好坏的问题，而是跟他们要解决的问题有关：RDB 诞生于互联网萌芽的时代，那时数据的准确、可靠是最重要的，而 NoSQL 诞生于互联网快速发展普及的时代，大数据、分布式、扩展性成了数据库的另一个重要特性。

总结一下：

RDB 首先得是准确、可靠，然后才向更高的「可拓展性」发展；

而 NoSQL 生而分布式，可拓展性强，然后才向更高的「准确性」发展。

NoSQL ，not only SQL，其实就是对那种打破了 RDB 严格事务和关系模型约束的那些数据库的泛指，而随着要解决的问题的不同，又诞生了各种各样的 NoSQL。

首先是「列式数据库」（Column-oriented DBMS），数据量上去了，我们想分析网站用户的年龄分布，简单说，就是你需要对同一个特征进行大数据量的分析统计，于是把原来 RDB 的「按行存储」的范式打破，变成了「按列存储」，比如 HBase；

然后你发现有些数据变动不是很大，但是经常需要被查询， 查询时还要关联很多张表，于是你把这些来自不同表的数据，揉成一个大对象，按 key-value 的格式存起来，比如 Redis；

再后来你需要对博客内容进行相关性搜索，传统 RDB 不支持相关性搜索，最重要的，还是扩展性差，增加机器的带来边际效益有限，于是有了「全文搜索引擎」，比如 Elasticsearch；

除此之外，还有「文档数据库」、「图形数据库」……

没有一种数据库是银d。

总结

这篇文章的题目是「如何选择数据库」，这是困扰很多人的问题，那么多数据库，到底要选什么好？

可是当你问出这样一个问题时，其实你是在问一种「手段」。我现在要做这样一个需求，用什么数据库可以帮我实现它？

但其实你需要的不只是一种「手段」，因为如果对方甩给你一个冷冰冰的名字，Mysql、Elasticsearch、MongoDB，你肯定会问，凭什么？

你需要的，是一种「解决方案」。如果你需要数据十分严格准确，分毫不差，那我会推荐你采用「事务」和「关系模型」来处理数据；如果你需要数据能够被大量读取和写入，那我会推荐你扩展性强的「分布式」；如果你的数据经常是整个读取、整个更新的，那「关系模型」就没有「文档模型」适合你。

「事务」、「关系模型」、「分布式」、「文档模型」等等，这些就是「解决方案」，知道用什么「解决方案」，用哪个数据库，自然水到渠成。

正如一位大牛说的：

设计实践中，要基于需求、业务驱动架构。无论选用 RDB/NoSQL，一定是以需求为导向，最终数据存储方案必然是各种权衡的综合性设计。

用户不会因为你用了 Mysql 或者 MongoDB 而使用你的软件，毕竟绝大多数用户都不知道 Mysql 和 MongoDB 是什么玩意。

安华金和官网上看的一篇文章，希望对你有帮助。随着数据价值的不断提升，从政策到用户对于数据安全重视程度越来越高，数据库审计产品作为一款部署简单，不用对现有IT架构进行任何改变，又能够满足政策合规需求的产品，是很多用户保障数据安全和合规需求的首选产品。那么面对市场上众多的数据库审计产品该怎样选择呢？下面将从数据库审计产品的功能上提出一些参考建议，希望对在数据库审计产品的选型过程中对您有所帮助。

一、数据库审计产品选型的10大基本能力

如果要满足用户使用数据库审计产品的基本需求，必须满足以下条件：

1、审计记录全和准：保证审计的准确性、全面性、无漏审，实现数据库访问流量的全捕获；

2、高效入库：审计结果快速入库，要在高访问量压力下，审计结果入库无延迟、无丢包；

3、准确的关联审计：高并发情况下，能够审计到数据库 *** 作的应用用户；

4、高效分析：要能够对审计记录进行快速分析与检索，至少实现千万乃至亿级数据秒级响应；

5、高易用性：要符合用户的使用习惯，保障产品的易用性；

6、加密协议解析：随着通讯加密的普及，数据库审计产品必须要能够解析加密的数据库访问流量；

7、数据库入侵行为监测：数据价值的提升，造成了数据库攻击行为更加普遍，审计产品应提供针对数据库漏洞攻击的“检测”功能，并对这些漏洞攻击实时监控、有效记录，发现风险后及时告警，且能够有效追溯风险来源；

8、数据库异常行为监测：数据库访问行为异常时，系统可提供实时的告警能力，降低数据泄露的损失；

9、数据库违规行为监测：数据库审计产品还应具备针对数据库的违规访问、登录等行为检测告警的能力；

10、报表展现：数据库审计产品应具备将审计日志进行数据化分析并以个性化报表展示的能力，以便帮助安全管理人员更加便捷、深入的剖析数据库运行风险。例如：综合报表、合规性报表、专项报表、自定义报表等。

二、做标王，数据库审计还需要哪些更过硬实力

在具备了数据库审计产品的基本功能之外，一款好的数据库审计产品还应能够做到以下四点：

1、全面的审计元素：包括，表、函数、包、存储过程、视图、数据库登陆用户、客户端ip、端口、MAC、客户端 *** 作系统、用户名、客户端工具、影响行数、结果集、执行时间、 *** 作类型、长语句、大对象、mysql压缩协议、dblink、imp、exp、prepare参数等，这样才能保证审计结果的全面性；

2、精确SQL语句解析：采用句柄追踪\参数绑定追踪和基于词法和语法的精确SQL解析技术，可以实现在长SQL语句、高并发访问量时不丢包；在多SQL语句情况下，准确记录数据库语句是否执行成功；对于prepare语句，准确将参数值与原始语句和绑定变量关联；对SQL执行结果集进行准确追踪，从而准确记录SQL语句的影响行数，从而保证数据库审计结果的准确性；

3、应用审计视角下的4层应用框架结构：具备4级应用框架结构——应用请求、应用行为、应用模块、应用：

应用请求：访问源对某个指定的URL发起访问请求的流水记录；

应用行为：针对某类相同和相似的应用请求，去除参数化的URL模板（类似于SQL语句模板概念）；

应用模块：多个应用行为的组合，归属于一组功能模块的集合，对应应用服务器的功能菜单；

应用：以应用服务器IP+应用服务器端口+应用工程名定义的一个应用系统。

这种4级应用框架结构，可以有效保证数据库审计产品的应用关联准确性，从而提供完整的基于应用访问视角的综合性统计数据呈现和正向追溯能力，以及多角度的审计结果分析能力。

4、完整的风险匹配规则与多样化的告警方式：基于横向的黑白名单匹配规则以及黑白名单SQL语句，以及纵向的高中低等风险等级设置，实现准确的数据库访问风险行为匹配。snmp、syslog、短信、邮件等多样性的告警方式，保证数据库风险行为的实时告警，从而实现全面风险发现与及时告警。

这是我在安华金和官网上看到的一篇文章，觉得不错，推荐给你，他们家就有数据库审计产品。

数据库类型还是数据类型？

数据库类型直接innodb

数据类型则遵从以下规则：

整数：int

金额：decimal

日期：date

日期时间：datetime

可变长度字符：varchar；即不确定有多长

固定长度字符：char；即知道字符长度，比如md5（）32位

文章详情等：longtext

我觉得首先得根据

业务场景

来决定，无论选择哪种数据库最终都是为了解决实际问题的。其次再考虑

成本

，开发人员对数据库的

熟练度，维护难易程度。

一、业务场景

问题上说的两种数据库区别还是蛮大的，mysql是传统关系型数据库，在处理小型系统和关系型数据时有很多的优点，什么支持多语言，开源，免费等等百度上就有很多。目前很多中小型公司都是用mysql。如果数据量大，对安全性能要求高，还不差钱的公司可以选择另外一种关系型数据库Oracle。monogoDB是非关系型的nosql数据库，属于文档型数据库，存储是以json、String等key-value键值对形式。通常用的较多的nosql数据库是redis。monodb使用的少（个人觉得）。这类非关系型数据库通常用来存储一些不会经常修改的数据，用来做缓存使用。另外还有使用monogodb开发商城的购物车功能。

二、使用成本

mysql、redis、monogodb都是可以免费使用，成本应该只有服务器存储空间成本，而oracle公司使用的话是需要缴费的。

三、工程师成本

这个我觉得还是传统的关系型数据库使用的人多，相应的资料也多。用起来应该能更快上手。应该没有后端工程师不会使用mysql、oracle等关系型数据库的。

四、维护难易程度

对于数据量在百万级以内的话维护成本差不多，如果再大mysql数据库就需要使用分库分表了。后期如果数据大数据处理的话，我认为nosql数据库更有优势。

我们从五个方面入手，帮助您系统的了解数据库服务 器对服务器硬件有哪些要求。

1数据库的高性能原则

保证所选购的服务器，不仅能够满足运营系统的运行和业务处理的需要，而且能够满足一定时期业务量的增 长。一般可以根据经验公式计算出所需的服务器TpmC值(Tpmc是衡量计算机系统的事务处理能力的程序)，然 后比较各服务器厂商和TPC组织公布的TpmC值，选择相应的机型。同时，用服务器的市场价/报价除去计算出 来的TpmC值得出单位TpmC值的价格，进而选择高性能价格比的服务器。

结论：服务器处理器性能很关键，CPU的主频要高，要有较大的缓存

2数据库安全可靠性原则

可靠性原则是所有选择设备和系统中首要考虑的，尤其是在大型的、有大量处理要求的、需要长期运行的系 统上。考虑服务器系统的可靠性，不仅要考虑服务器单个节点的可靠性或稳定性，而且要考虑服务器与相关 辅助系统之间连接的整体可靠性，如：网络系统、安全系统、远程打印系统等。在必要时，还应考虑对关键 服务器采用集群技术，如：双机热备份或集群并行访问技术，甚至采用可能的完全容错机。

结论：服务器要具备冗余技术，同时像硬盘、网卡、内存、电源此类设备要以稳定耐用为主，性能其次。

3数据库的可扩展性原则

保证所选购的服务器具有优秀的可扩展性原则。因为服务器是所有系统处理的核心，要求具有大数据吞吐速 率，包括：I/O速率和网络通讯速率，而且服务器需要能够处理一定时期的业务发展所带来的数据量，需要服 务器能够在相应时间对其自身根据业务发展的需要进行相应的升级，如：CPU型号升级、内存扩大、硬盘扩大 、更换网卡、增加终端数目、挂接磁盘阵列或与其他服务器组成对集中数据的并发访问的集群系统等。这都 需要所选购的服务器在整体上具有一个良好的可扩充余地。一般数据库和计费应用服务器在大型计费系统的 设计中就会采用集群方式来增加可靠性，其中挂接的磁盘存储系统，根据数据量和投资考虑，可以采用DAS、 NAS或SAN等实现技术。

结论：服务器的IO要高，否则在CPU和内存都是高性能的情况下，会出现瓶颈。除此之外，服务器的扩展性要 好，为的是满足企业在日后发展的需要。

4服务器的安全性原则

服务器处理的大都是相关系统的核心数据，其上存放和运行着关键的交易和重要的数据。这些交易和数据对 于拥有者来说是一笔重要的资产，他们的安全性就非常敏感。服务器的安全性与系统的整体安全性密不可分 ，如：网络系统的安全、数据加密、密码体制等。服务器需要在其自身，包括软硬件，都应该从安全的角度 上设计考虑，在借助于外界的安全设施保障下，更要保证本身的高安全性。

结论：首先从服务器的材料上来说要具备高硬度高防护性等条件，其次服务器的冷却系统和对环境的适应能 力要强，这样才能够在硬件上满足服务器安全的要求。

5服务器利于可管理性原则

服务器既是核心又是系统整体中的一个节点部分，就像网络系统需要进行管理维护一样，也需要对服务器进 行有效的管理。这需要服务器的软硬件对标准的管理系统支持，尤其是其上的 *** 作系统，也包括一些重要的 系统部件。

结论：尽量选择支持系统多的服务器，因为服务器兼容的系统越多，你就可以拥有更大选择空间。

最后希望能够给你有所帮助。

以上就是关于如何选择数据库 大概服务200人左右全部的内容，包括:如何选择数据库 大概服务200人左右、如何选择数据库、怎样选择数据库审计系统等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！