数据库选型的五大要素
数据库设计的关键要素
数据库设计的关键要素数据库设计是指根据特定的需求和目标，规划和设计数据库模式的过程。
一个优秀的数据库设计能够实现高效的数据存储和管理，同时满足对数据的准确性、一致性和安全性的要求。
在进行数据库设计时，有几个关键要素需要考虑。
一、需求分析在进行数据库设计之前，首先需要进行需求分析，明确系统的功能和业务需求。
通过与用户的沟通和了解，收集并理解用户的需求，从而确定数据库设计的目标和约束条件。
需求分析阶段的准确性和完整性直接影响数据库设计的质量。
二、数据模型选择数据模型是数据库设计的基础，不同的数据模型适用于不同的应用场景。
常见的数据模型有层次模型、网状模型和关系模型等。
在选择数据模型时，需要考虑数据库的结构特点、查询需求和操作复杂度等因素。
目前，关系模型是最常用的数据模型，基于关系模型的数据库设计具有可扩展性和灵活性。
三、实体关系建模在数据库设计中，实体关系建模是一项重要的任务。
通过对实体和实体之间的关系进行建模，可以将现实世界中的概念转化为数据库模型中的表和关系。
在实体关系建模中，需要确定实体的属性和关系的类型，为数据库设计提供清晰的结构。
四、范式设计范式设计是数据库设计的一个重要环节。
通过将数据组织到确定的范式中，可以确保数据库中的数据存储合理、有序且无冗余。
常见的范式有第一范式、第二范式和第三范式等。
范式设计需要细致地分解数据，并消除冗余的部分，以提高数据库的性能和可靠性。
五、索引设计索引在数据库设计中起着重要的作用，可以提高数据检索的效率。
合理的索引设计能够加快查询速度，但过多或不合理的索引设计反而会导致性能下降。
索引设计需要根据查询需求和数据量大小来考虑，选择合适的字段作为索引，以提高数据库的查询效率。
六、安全性设计数据库中存储着重要的数据，因此安全性设计是数据库设计中的重要一环。
安全性设计包括对数据的访问权限控制、用户身份验证和数据加密等方面。
合理的安全性设计可以保护数据库免受非法访问、数据泄露或损坏的影响。
数据库服务器对硬件配置的五个要求
数据库服务器对硬件配置的五个要求LELE was finally revised on the morning of December 16, 2020数据库服务器对硬件配置的五个要求【来源：小鸟云计算】小鸟云 - 企业级云服务器、虚拟主机、服务器租用托管服务提供商说了这么多数据库的重要性，那么如何挑选一款可靠的，稳定的数据库服务器呢？我们从五个方面入手，帮助您系统的了解数据库服务器对服务器硬件有哪些要求。
选择数据库服务器的五个原则：1)高性能原则保证所选购的服务器，不仅能够满足运营系统的运行和业务处理的需要，而且能够满足一定时期业务量的增长。
一般可以根据经验公式计算出所需的服务器TpmC值(Tpmc是衡量计算机系统的事务处理能力的程序)，然后比较各服务器厂商和TPC组织公布的TpmC值，选择相应的机型。
同时，用服务器的市场价/报价除去计算出来的TpmC值得出单位TpmC值的价格，进而选择高性能价格比的服务器。
结论：服务器处理器性能很关键，CPU的主频要高，要有较大的缓存2)可靠性原则可靠性原则是所有选择设备和系统中首要考虑的，尤其是在大型的、有大量处理要求的、需要长期运行的系统上。
考虑服务器系统的可靠性，不仅要考虑服务器单个节点的可靠性或稳定性，而且要考虑服务器与相关辅助系统之间连接的整体可靠性，如：网络系统、安全系统、远程打印系统等。
在必要时，还应考虑对关键服务器采用集群技术，如：双机热备份或集群并行访问技术，甚至采用可能的完全容错机。
结论：服务器要具备冗余技术，同时像硬盘、网卡、内存、电源此类设备要以稳定耐用为主，性能其次。
3)可扩展性原则保证所选购的服务器具有优秀的可扩展性原则。
因为服务器是所有系统处理的核心，要求具有大数据吞吐速率，包括：I/O速率和网络通讯速率，而且服务器需要能够处理一定时期的业务发展所带来的数据量，需要服务器能够在相应时间对其自身根据业务发展的需要进行相应的升级，如：CPU型号升级、内存扩大、硬盘扩大、更换网卡、增加终端数目、挂接磁盘阵列或与其他服务器组成对集中数据的并发访问的集群系统等。
数据库选型的五大要素
数据库选型的五大要素在进行数据库选型时，有五个重要要素需要考虑。
这些要素包括：数据类型、访问模式、规模和性能需求、安全性和可靠性以及成本效益。
在选择合适的数据库时，这些要素是至关重要的，可以帮助组织更好地满足业务需求和目标。
首先，数据类型是选择数据库的重要考量因素之一、不同类型的数据库适用于不同的数据类型。
例如，关系型数据库适用于结构化数据，而文档型数据库适用于半结构化和非结构化数据。
因此，在选择数据库时，需要仔细考虑组织所需处理和存储的数据类型。
其次，访问模式是选择数据库的另一个关键因素。
访问模式涉及到数据的读取、写入、更新和删除方式。
不同的应用程序可能具有不同的访问模式需求。
例如，一些应用程序需要大量的读取操作，而另一些应用程序可能需要频繁的写入和更新操作。
因此，在选择数据库时，需要根据应用程序的访问模式需求来评估不同数据库的性能和效率。
第三个要素是数据库规模和性能需求。
数据库的规模涉及到数据量的大小，而性能需求涉及到对数据的处理和响应时间的要求。
数据库规模和性能需求对于数据库的选择非常重要。
在选择数据库时，需要考虑数据库的扩展性、吞吐量和响应时间等因素，以满足组织的数据处理需求。
安全性和可靠性是数据库选型的另一个关键要素。
数据库需要保护组织的敏感数据，并提供对数据的权限管理和身份验证。
此外，数据库还需要能够处理故障和数据丢失的情况，并提供数据备份和恢复的能力。
因此，在选择数据库时，需要考虑数据库的安全性和可靠性功能。
最后，成本效益是数据库选型的重要考量因素之一、不同类型的数据库具有不同的成本结构和授权模式。
一些数据库是开源的，可以免费使用，而另一些数据库则需要支付许可费用。
此外，数据库还涉及到硬件和维护成本。
因此，在选择数据库时，需要考虑数据库的总体成本效益，并权衡成本和性能之间的关系。
综上所述，数据库选型的五大要素包括数据类型、访问模式、规模和性能需求、安全性和可靠性以及成本效益。
使用这些要素作为决策依据，可以帮助组织选择最适合其需求的数据库，并满足业务目标。
数据库选型依据
数据库选型依据在选择数据库时，有许多因素需要考虑，包括但不限于以下几个方面。
1. 数据类型和量：不同的数据库适用于不同类型和量的数据。
例如，关系型数据库适用于结构化数据，而NoSQL数据库则适用于非结构化数据。
因此，在选择数据库时，首先需要考虑数据的类型和量。
2. 数据处理需求：不同的应用对数据的处理需求也不同。
一些应用需要快速的读取和写入，一些需要高并发处理，还有一些需要支持大规模的数据分析。
因此，在选择数据库时，需要考虑应用的数据处理需求。
3. 可扩展性与可靠性：应用可能需要支持不断增长的用户和数据量，因此，数据库的可扩展性和可靠性也是考虑的重要因素。
一些数据库具有水平扩展能力，可以通过添加更多的节点来增加容量和性能，而一些则具有高可靠性和故障转移能力，可以确保数据的安全性和可用性。
4. 性能和成本：性能和成本往往是相互矛盾的。
一些高性能的数据库可能需要高昂的许可费用和硬件成本，而一些低成本的数据库可能性能较低。
因此，在选择数据库时，需要平衡性能和成本，找到最佳的平衡点。
5. 社区支持和生态系统：数据库的社区支持和生态系统也是重要的考虑因素。
一些数据库拥有庞大的开发者社区和丰富的生态系统，可以提供丰富的工具和插件，促进开发和部署。
这些数据库也更容易得到帮助和支持，遇到问题可以快速解决。
因此，在选择数据库时，需要考虑其社区支持和生态系统。
综上所述，选择数据库需要考虑许多因素，包括数据类型和量、数据处理需求、可扩展性与可靠性、性能和成本、社区支持和生态系统等。
在选择时，需要平衡这些因素，找到最适合应用的数据库。
数据库技术中的数据字段类型选择(六)
数据库技术中的数据字段类型选择在数据库设计和开发中，选择正确的数据字段类型是至关重要的。
数据字段类型不仅直接影响数据的存储方式和效率，还关系到数据的准确性和一致性。
在本文中，我们将探讨数据库技术中的数据字段类型选择，并给出一些建议。
一、字符型字段类型选择字符型字段类型是数据库中最常见的字段类型之一。
在选择字符型字段类型时，需要考虑存储的最大长度和字符集。
一般常见的字符型字段类型有CHAR、VARCHAR和TEXT等。
1. CHAR类型：CHAR类型是一种固定长度的字符类型，长度上限一般为255个字符。
由于其固定长度的特性，使用CHAR类型可以提高查询效率。
但是，在存储数据时，如果字符长度小于字段定义的长度，系统会自动填充空格，因此这会带来一些空间浪费。
2. VARCHAR类型：VARCHAR类型是一种可变长度的字符类型，长度上限一般为65535个字符。
与CHAR类型相比，VARCHAR类型可以更节省空间，因为它只存储实际需要的字符。
但是，VARCHAR类型在查询时会降低一些效率。
3. TEXT类型：TEXT类型是一种可变长度的大文本类型，它的长度上限一般为65535个字符。
与VARCHAR类型相比，TEXT类型可以存储更大的文本数据。
然而，由于其大文本的特点，查询效率相对较低。
在选择字符型字段类型时，需要根据具体应用场景来选择。
如果字段的长度是固定的，建议使用CHAR类型；如果字段的长度不确定，但是数据量不大，建议使用VARCHAR类型；如果字段的长度不确定，并且数据量较大，建议使用TEXT类型。
二、数值型字段类型选择数值型字段类型用于存储各种数值类型的数据，如整数、小数等。
在选择数值型字段类型时，需要考虑数据的精度和范围。
常见的数值型字段类型有INT、FLOAT和DECIMAL等。
1. INT类型：INT类型是一种整数类型，它可以存储不超过的整数。
在存储整数时，INT类型占用的存储空间较小，查询效率较高。
数据库产品的选型
数据库产品的选型根据系统对数据库信息系统功能和性能方面的要求，我们可以从Sybase、Oracle、MSSQL、DB2等数据库管理平台中选择一款构建校园应用。
这些数据库厂商都是世界知名品牌，他们的产品已经无可质疑。
下面就数据库必须满足的功能与系统的具体应用需求加以说明：数据库产品的基本功能1、支持多种硬件和操作系统平台，如Windows NT、SUN、DIGITAL、HP、SGI、SCO、DG、DYNIX等。
2、支持TCP/IP、SPX/IPX、X。
25网络通讯协议，支持ANSI SQL92、XA、SNMP等标准，支持中文等多字节编码，支持UNICODE编码格式。
3、透明分布式数据库系统，支持透明二阶段提交机制；数据库核心内置了高级复制功能，可实现对称复制和存储转发等数据库复制技术。
4、支持NT和UNIX上并行服务器的高可用性系统，支持多种STANGBY服务器备份模式。
5、支持CLIENT/SERVER和BROWSER/SERVER多层计算结构，可以提供完整的WEB APPLICATION SERVER和开发工具产品，可提供基于BROWSER的开发工具。
使用可视化开发工具开发的应用，可以直接发布到WEB APPLICATION SERVER上，通过标准的BROWSER调用。
6、支持多进程、多线索的机制和对象关系型数据库。
7、支持超过12种以上的数据库触发器，可以设置触发器使之启用或失效，支持DDL操作（建表、删除表）触发器，支持系统事件触发器，可以在视图和嵌套表上建立触发器。
8、支持多语种、集成的全文检索功能，可对英文实现语法分析和语义归纳功能，对中文可按字按词检索，检索范围可以是数据库字段、HTML页面或WORD文件等，检索的语法为标准SQL语句的扩展。
9、支持表空间概念，可以设置表空间为只读或可读写，表空间可以实时地被在线和离线，提供临时表空间类型，可在表空间上对用户设定空间使用限额，表空间容量可以随着数据的增长而自动扩展。
数据库字段类型选择原则与技巧
数据库字段类型选择原则与技巧在设计和创建数据库时，选择适当的字段类型是至关重要的。
字段类型会直接影响数据库的性能、存储和可扩展性。
本文将介绍一些常见的数据库字段类型，并提供选择原则和技巧，以帮助开发人员在设计数据库时做出明智的决策。
1. 字符串类型在数据库中存储文本数据通常需要选择适当的字符串类型。
最常见的字符串类型是CHAR、VARCHAR和TEXT。
- CHAR：固定长度的字符串类型。
当存储的数据的长度是固定的或者非常接近固定的时候，CHAR是一个不错的选择。
例如，存储国家或地区的代码时，通常是两个字符的固定长度。
- VARCHAR：可变长度的字符串类型。
VARCHAR通常用于存储长度不固定的文本数据。
它可以根据存储的数据自动调整长度。
对于存储用户输入的数据，如用户名、电子邮件地址等，使用VARCHAR更为合适。
- TEXT：用于存储大段文本数据的字符串类型。
当需要存储较大的文本数据时，TEXT是一个不错的选择。
然而，需要注意的是，TEXT类型会占用更多的存储空间和处理时间。
2. 数字类型在数据库中存储数值类型的数据时，需要根据数值的范围和精度选择适当的数据类型。
常见的数字类型有INT、BIGINT、FLOAT和DECIMAL。
- INT：用于存储整数类型的数据。
INT适用于存储整数数据，其范围通常从-2147483648到2147483647。
- BIGINT：用于存储较大整数类型的数据。
如果需要存储超过INT范围的整数数据，BIGINT则是一个较好的选择。
- FLOAT：用于存储浮点数类型的数据。
FLOAT适合存储具有小数部分的数值。
然而，需要注意的是，FLOAT类型在精度上有一定的限制。
- DECIMAL：用于存储高精度数值类型的数据。
DECIMAL可以存储更加精确的数值，具有更高的精度。
在需要计算金额和货币值等情况下，DECIMAL通常是更好的选择。
3. 日期和时间类型在数据库中存储日期和时间相关的数据时，需要选择合适的日期和时间类型。
数据库类型和选择理由
1.1.1.数据库类型和选择理由1.1.1.1.数据库类型数据库是存储、管理、检索数据的关键组件。
根据数据的结构化程度和查询的复杂性，有多种数据库类型可供选择。
以下是几种常见的数据库类型：关系型数据库（Relational Databases）：关系型数据库使用表格形式存储数据，每个表格由行和列组成，每一列都有一个特定的数据类型。
这种数据库类型使用结构化查询语言（SQL）进行数据操作。
常见的开源和商业关系型数据库包括MySQL、PostgreSQL、Oracle、Microsoft SQL Server等。
非关系型数据库（NoSQL Databases）：非关系型数据库不遵循固定的数据结构，因此更为灵活。
这类数据库主要用于大规模数据的快速读取和高并发操作。
常见的NoSQL数据库包括MongoDB、Cassandra、Redis、Elasticsearch等。
列存储数据库（Columnar Storage Databases）：列存储数据库将数据按列存储，而不是按行。
这种存储方式使得某些查询能够更快地读取数据，因为只需要读取所需的列，而不是整行。
Apache Parquet和ORC是常见的列存储格式。
图形数据库（Graph Databases）：图形数据库使用图形结构（节点和边）来表示和存储数据，特别适合表示和查询具有复杂关系的数据。
Neo4j是图形数据库的知名例子。
时序数据库（Temporal Databases）：时序数据库用于存储和管理时间序列数据，例如日志和传感器数据。
这种类型的数据库特别适合时间序列分析和实时数据处理。
InfluxDB是时序数据库的知名例子。
1.1.1.2.选择理由在选择合适的数据库类型时，需要考虑以下因素：数据规模：如果应用程序需要处理大量的数据，那么非关系型数据库或列存储数据库可能更合适，因为它们通常更适合大规模数据的处理和高并发操作。
查询复杂性：如果应用程序需要执行复杂的联接、聚合或子查询操作，关系型数据库可能更适合。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库选型的五大要素
面对品种繁多的数据库产品，如何才能独具慧眼，选中适合自己的数据库产品呢？众所周知，正确的评估、选型与数据库技术本身同样重要。
而通常，数据库厂商都会在性能清单和技术基准表中尽量展现产品最佳的一面，对产品弱点却避免提及或进行遮掩，关于这一点，业界已经是人尽皆知了。
其实在挑选和评估过程中，首要目标是选择一款能够满足甚至超过预定要求的技术或解决方案。
选型的正确方法将使用户在面对众多产品时，提高其做出最佳选择的能力。
数据库选型时，必须考虑以下五大因素：
1. 开发要求
2. 性能/成本
3. 数据库运行和管理
4. 可升级性
5. 总体拥有成本
开发要求
首先，需要清楚自己究竟想使用什么开发技术。
例如，你是要以访问传统的关系型数据库？还是要以纯面向对象技术构建J2EE应用平台？又或是需要建设XML Web Services？如果你要实现的是纯关系型的开发典范，那么实际要使用的受支持的标准（和非标准）SQL功能有多少？
如果你要规划的是面向对象开发策略，那么在原计划里的数据库支持真正的面向对象吗？它是如何支持的？若有需要,它能同时提供SQL的功能吗？数据库支持这个功能吗？虽然,有些关系型数据库声称支持对象开发，但实际上并不是直接支持的。
这种非直接的体系结构将导致更多的事务处理故障，以及潜在的可升级性和性能问题。
另外，你还需要确定自己的前端技术如何与后端进行“对话”。
你的业务逻辑是放在客户机一端呢？还是放在服务器一端？你要使用哪些脚本语言？它们与后端服务器的兼容性如何？它们是快速应用开发（RAD）环境吗？
目前，实现基于关系型数据库的应用可以选择传统的主流品牌，这些数据库产品有着很成熟的关系技术以及广泛的应用资源。
但是,如果实现的是基于面向对象技术的应用、又或是数据结构更为复杂时，不妨考虑目前一些公司推出的所谓后关系数据库。
它所代表的正好是关系数据库和面向对象技术的融合，以多维数据引擎作为核心，从根本上支持复杂的对象存储及主流的二维表，同时也已经配备了功能强大的应用服务引擎，可作对象逻辑操作的平台。
它的出现已经为传统数据库领域带来了冲击，而在面向对象数据库方面更是广受欢迎。
性能/成本
测量数据库性能最常见的方法是TPC基准。
TPC明确地定义了数据库方案、数据量以及SQL查询。
测量的结果是，在特定的操作系统上，配置了特定的数据库版本，以及在惊人的硬件条件下，每项事务的成本是多少——其中的事务可以是TPC测试中定义的任何数据库操作。
从理论上来讲，这类基准旨在提供不同产品间客观的比较值。
但在现实中，这些方案又有多少能准确反映并回答你在挑选技术时所存在的疑惑？其次，所有技术厂商发布的TPC基准都会超过以前发布的结果。
这样，TPC基准在更大程度上反映的是为解决问题而投入的内存和CPU量，而不是数据库性能的任何真实表现。
以笔者多年所见，只有在真实的环境中进行实际的比较测试才可以推断出数据库的预期性能及评估所需成本。
常用的方法包括平衡移植，把原来的数据转移到类似硬件上的另一套数据库，然后以真实的客户端连接这套测试对象。
又或是以数据产生器针对真实的数据模型，建立出庞大的数据量，再以客户端连接作测试。
这种做法跟实验室中的做法的不同之处有以下几点：第一，试验中的硬件构架跟你预期的方案不会有太大的差别；第二，所测试的事务在宽度和深度方面跟未来计划的也差不太远；第三，如果是硬件条件一样，我们可以直接看出测试对象跟原来方案有着多少差异。
掌握了以上结论之后，我们应该可以更精明地为所需的性能投入相应的成本。
换句话说，我们将能够更准确地预测各种数据库的性能与相应的成本。
数据库运行和管理
所有数据库都需要进行管理。
数据库管理涉及以下问题：
·操作任务：备份、故障切换、灾难恢复，等等；
·整理系统：分段、存档；
·访问控制：定义、监控；
·性能：保持系统在线和优化运行；
·数据库方案变更：更改数据库结构、更新索引、数据库同步。
有些数据库需要比其他数据库投入更多管理资源，业界通常以一家公司必须雇用的数据库管理员（DBA）人数的多少来做比较，这是因为只有雇用足够数量的管理员才能在确保系统运行平稳的同时，又能维持数据库的完整性。
因此，在数据库选型时应考虑以下问题：
·产品需要多少数据库管理员？
·他们负责什么？
·什么任务需要停机？
·停机时间会有多长？
·这些任务的困难/复杂程度有多大？
·执行这些任务需要什么技术？
·这些任务如何管理（现场还是远程）？
·现在有哪些工具可以帮助完成这些任务？
·所有优化措施都可行/容易执行吗？
过去选择数据库时，因为别无他选，大部分项目经理、信息主任在考虑问题时已经不再看重以上因素，理由是不管选哪一品牌的产品，他们还是要长时间地付出同样昂贵的维护及管理费用。
而目前市面上出现的一些新的数据库为行业带来了一定的冲击，除速度和处理能力之外，更重要的是，为信息主任们分担了大部分繁杂的工序，过去一些必然的管理和优化操作，现在全自动完成，已招聘的人力资源可改而投入单位里其他岗位，创造更大的价值。
可升级性
随着对数据库应用软件使用的不断增加，很可能某一时刻当前的硬件配置就不够用了，这时你就需要对硬件进行检查。
升级可以朝两个方向发展：垂直升级（使用更大/更多的处理器）和水平升级（使用与当前平台同一规格的更多的计算机/处理器）。
在考虑可升级性时，用户应首先回答以下问题：
·业务逻辑能和数据分离吗？
·业务逻辑能拆分吗？
·数据库能分段吗？
·这些任务执行起来容易吗？
·执行上述任一操作后对性能有什么提升？
·如果当前的配置成倍增长，那么性能也会成倍增长吗？
·升级到所需的数量/容量时有哪些体系结构可以选择？
·我需要对用户接口前端做哪些更改才能接纳这些不同的选择？这些更改有多复杂，需要什么技术？更改的成本是多少？
·最后一点，同时也是最重要的一点，这类要求在开发和部署方面有哪些需要注意的事项？
虽然所有供应商都声称自己提供的是“具有巨大升级空间”的技术，但最重要的还是你要调查高容量升级所引发的直接、间接及隐藏成本。
对“服务器群（Server Farms）”一词相关的技术切勿掉以轻心。
那些好的数据库所带来的机遇应该基于它所支持的各种主流的操作系统平台，以及研发多年成熟和稳定的网络分布式数据缓冲技术，确保在垂直升级时不用对应用程序做任何修订，更可在不影响日常业务运作的情况下，实时调整服务器群的规模。
总体拥有成本
总体拥有成本(Total Cost of Ownership)是你做决策时必须首先面对的问题。
作为一个专业的决策人员，不能只因为单项优势(如软件价格）就加以采纳，所部署的解决方案创建出来的价值理应超过它的成本。
目前的困难在于许多成本和优势都是无形的，因此难以量化并且难以测量。
不过，在对评估的各个产品进行TCO审查时，一定要将数量和客观的估计值包括在内。
否则不仅对产品的情况掌握得不够完整，还有可能导致结论不够全面，从而产生负面结果。
需要考虑的一些成本和优势如表1所示。
表1 数据库选型中的成本和优势
下面我们来举例说明，如果我们需要在数据库A和B之间进行选择。
在考虑TCO的前提下，我们应该做如表2所示的计算。
表2 数据库A和B的TCO计算
从表面上看来，数据库A价格便宜、实施的成本也相对地低一些。
但要达到预期的服务水平，硬件和维护的成本却要高很多。
相反，数据库B售价高昂、实施时的风险高一点所以成本也高很多，但因为它的技术水平比较高，相对的硬件和维护成本就要低很多。
结果是，数据库B的方案，长远来讲反而更有利。
通过以上的假设，说明如果通过TCO审查，我们能更全面地看到事实的真相。
为什么要用关系型数据库而不用非关系型数据库。
1、对于增删改查操作，关系型数据库和非关系型数据库的性能开销基本一致，因为所有表的数据量都非常小，小于百万级，因为在千万级数据量以下，关系型数据库只要设置了索引，都是非常快的。
2、在性能方面一致的情况下，非关系数据库的缺点在于无法支持动态连接查询应用，即sql中的join操作，或者说是join效率不如关系型数据库高，另外也不支持分组(group)和统计操作(count/sum/avg等)，在业务系统中存在大量的join操作，比如，报表打印、银行缴费对账、员工、机构、角色、交易、科目、字典等复杂应用都涉及到大量关联，所以非关系型数据库在这些处理方面不如关系型数据库灵活和性能高，编写的代码可读性和健壮性也较低。
3、关系型数据库的管理工具，比非关系型数据库的管理工具更丰富，也更完善。
对于数据库的DBA维护而言，关系型数据库的批量更新、导入、导出、备份、优化等方式和资料都丰富，对于开发人员的入门门槛，关系型数据库也比较低。
4、关系型数据库的发展历史和稳定性要超过非关系型数据库。
5、既然在性能一致的情况下为什么不用关系型数据库呢。
6、统计和数据分析相关的数据库就必须是用关系型数据库了，因为大量的统计应用都是基于sql中的统计函数的，比如查询交易业务性别比例、学历分布等，都涉及到sql操作，比如，join,group by xxx,sum(),count(),avg()等，这些都是非关系型数据库不支持的。