腾讯云数据安全审计（CloudAudit，CA）能够对腾讯云数据库实例以及用户自建数据库进行审计，不仅支持腾讯云的数据库服务，也能通过一定的配置和管理，对其他云服务提供商的数据库或本地IDC的数据库进行审计。 以下是相关管理和操作方式： ### 管理方式 1. **配置审计代理**： - 对于非腾讯云环境（如其他云或本地IDC），需要在被审计的数据库服务器上部署审计代理。 - 审计代理负责采集数据库的审计日志，并将其安全地传输到腾讯云CA服务端。 2. **日志传输与存储**： - 使用专线或VPN等方式确保数据传输的安全性和稳定性。 - 在CA控制台配置日志接收和存储策略。 3. **策略制定与执行**： - 根据业务需求制定详细的审计策略，包括需要监控的操作类型、时间范围等。 - 将这些策略应用到相应的数据库实例上。 4. **实时监控与告警**： - 实时查看和分析审计日志，及时发现异常行为。 - 设置告警规则，在检测到潜在风险时自动触发通知。 ### 举例 假设一家企业同时在腾讯云和阿里云上部署了数据库，并且还有部分数据库位于自建的IDC机房内。为了实现全面的审计覆盖： - 在阿里云的数据库服务器和IDC的物理机上安装腾讯云提供的审计代理软件。 - 配置代理以定期将数据库活动日志发送至腾讯云CA平台。 - 在CA平台上统一管理和分析所有来源的日志数据，设置跨云的一致性审计策略。 - 当检测到任何不符合预定安全标准的操作时，系统会通过短信和邮件发送告警给管理员。 ### 推荐产品 - **腾讯云数据安全审计（CloudAudit）**：提供全面的数据库审计功能，支持多种数据库类型和环境。 - **腾讯云VPN/专线接入**：保障非腾讯云环境与腾讯云CA之间的安全稳定连接。 通过这种方式，企业能够构建起一个跨云及本地的统一数据安全审计体系，有效提升整体安全性管理水平。... 展开详请

腾讯云数据安全审计通过提供全面的审计日志和监控功能，帮助用户满足数据库等保合规要求。具体来说，腾讯云数据安全审计可以： 1. **记录所有访问和操作**：对数据库的所有访问和操作进行详细的审计记录，包括登录、查询、修改、删除等操作，确保所有行为都可追溯。 2. **实时监控和告警**：提供实时的监控和告警功能，及时发现异常行为或潜在的安全威胁，并通过邮件、短信等方式通知管理员。 3. **数据脱敏和加密**：对敏感数据进行脱敏处理，确保在审计日志中不会泄露敏感信息。同时，支持数据加密存储，保护数据在传输和存储过程中的安全。 4. **合规性报告**：生成详细的合规性报告，帮助用户证明其数据库操作符合相关法律法规和行业标准，如《网络安全法》、GDPR等。 5. **多维度审计**：支持多维度的审计，包括用户、时间、IP地址、操作类型等，提供全面的审计视角。 **举例**： 假设某企业在腾讯云上部署了一个MySQL数据库，通过腾讯云数据安全审计服务，该企业可以： - 记录所有管理员和用户的数据库操作日志。 - 实时监控数据库的访问情况，发现并阻止异常访问。 - 对存储在数据库中的客户信息进行脱敏处理，防止敏感数据泄露。 - 生成合规性报告，证明其数据库操作符合《网络安全法》的要求。 **推荐产品**： 腾讯云的**云数据库审计（CloudDBA）**服务，专为云数据库提供全面的审计和安全监控功能，帮助企业满足等保合规要求，提升数据库的安全性和可管理性。... 展开详请

主机安全防止数据库默认密码泄露可以通过以下措施： 1. **修改默认密码**：在安装数据库后，立即更改默认的管理员密码。默认密码通常较为简单，容易被猜测或通过已知的漏洞获取。 2. **使用强密码策略**：确保新设置的密码复杂度高，包含大小写字母、数字和特殊字符，并且长度足够。 3. **定期更换密码**：定期更换数据库密码可以减少密码被破解的风险。 4. **限制访问权限**：只允许必要的IP地址或网络访问数据库，避免开放给公网。 5. **启用双因素认证**：在可能的情况下，为数据库访问启用双因素认证，增加额外的安全层。 6. **使用配置管理工具**：利用配置管理工具来自动化密码管理和更新过程，确保所有系统都遵循一致的安全策略。 7. **监控和日志审计**：实施监控和日志审计，及时发现异常访问尝试和潜在的安全威胁。 例如，使用腾讯云的云数据库产品时，可以通过腾讯云控制台或API接口来设置和管理数据库密码，同时利用腾讯云的安全组功能限制访问来源，增强数据库的安全性。此外，腾讯云还提供了云安全中心，提供全方位的安全防护，包括入侵检测、漏洞管理等，进一步保护数据库不受未授权访问的威胁。... 展开详请

云防火墙防御数据库入侵主要通过以下方式： **一、访问控制策略** 1. **原理** - 云防火墙可以根据源IP地址、目的IP地址（数据库服务器的IP）、端口号（数据库默认端口如MySQL的3306端口等）以及协议类型（如TCP）来制定严格的访问规则。只允许合法的IP地址或IP段访问数据库服务器，阻止来自未知或恶意源的连接尝试。 2. **举例** - 假设某公司内部的数据库服务器只应该被公司内部特定部门的IP地址段访问。云防火墙就可以设置规则，只允许这些部门办公网络的IP范围（如192.168.1.0/24）通过TCP协议访问数据库服务器的3306端口，其他外部IP的访问请求将被拒绝。 **二、入侵检测与防范功能** 1. **原理** - 云防火墙能够识别一些常见的数据库入侵行为模式。例如，检测到针对数据库的SQL注入攻击特征，像包含恶意的SQL语句片段（如' or '1'='1等典型的SQL注入尝试）的请求时，会阻止该请求到达数据库服务器。 2. **举例** - 如果攻击者试图通过在输入框（可能是登录界面或者数据查询界面）输入恶意的SQL语句来绕过身份验证登录数据库系统，云防火墙能够分析这个请求中的SQL语句特征，判定为SQL注入攻击尝试，从而阻断这个连接请求。 **三、流量监控与异常检测** 1. **原理** - 持续监控进出数据库服务器的流量情况。如果发现流量异常，如短时间内有大量来自同一个IP地址的连接请求超出了正常业务范围，或者数据传输量突然异常增大（可能是数据被窃取时的批量传输），云防火墙可以采取行动。 2. **举例** - 正常情况下，某数据库服务器每小时接收来自外部合作方IP地址的100次查询请求。突然在某个时间段内，从这个IP地址来的查询请求每分钟就达到100次，云防火墙检测到这种流量异常后，可以暂时限制该IP地址的访问权限，同时发出警报以便进一步调查。 腾讯云的云防火墙产品就具备强大的访问控制、入侵检测和流量监控等功能。它可以有效地防御数据库面临的多种入侵威胁，为数据库系统提供可靠的安全防护屏障。... 展开详请

先对现有服务器的 Redis 合理设置过期时间、开启集群做读写分离、压缩数据；MySQL 优化索引与查询、定期清理无用数据；Java 程序用本地缓存。用另一台服务器定时备份 MySQL 数据库保障数据安全。添加一台服务器做负载均衡减轻压力，采用蓝绿部署更新程序，即新服务器部署新版本，切换流量测试无问题后再全量切换。更新前充分测试，准备回滚方案应对可能错误。日常做好服务器监控与维护，防止误删除。... 展开详请

MySQL从单机到集群设计的架构演进过程中，系统性聊一聊，如何折衷高可用与一致性的问题，希望对你有帮助。 高可用的核心方法论是：冗余（replication） + 故障自动转移（fail-over）。 最容易想到的，是数据库主从集群，每份数据都进行复制，每个实例都独享 DISK/MEM/CPU 资源，避免实例之间的资源竞争。 如上图所示： （1）把整体数据存储分复制了N份，每份之间数据都一样； （2）每份数据的 DISK/MEM/CPU 都在一个DBMS进程内，部署在一台服务器上； （3）每份数据的资源之间的没有竞争； 理想很丰满，现实很骨感，思路没问题，但实际执行“复制”的过程中，会碰到一些问题。 以MySQL为例，有3种常见的复制方式： （1）异步复制； （2）半同步复制； （3）组复制； 第一种，异步复制（Asynchronous Replication） 又叫主从复制（Primary-Secondary Replication），是互联网公司用的最多的数据复制与数据库集群化方法，它的思路是，从库执行串行化后的主库事务。 其核心原理如上图所示： （1）第一条时间线：主库时间线；  - 主库执行事务  - 主库事务串行化binlog  - binlog同步给从库  - 主库事务提交完成 （2）第二条/第三条时间线：从库时间线；  - 收到relay log  - 执行和主库一样的事务  - 生成自己的binlog（还可以继续二级从库）  - 从库事务提交完成 从这个时间线可以看到： （1）主库事务提交； （2）从库事务执行； 是并行执行的，主库并不能保证从库的事务一定执行成功，甚至不能保证从库一定收到相关的请求，这也是其称作“异步复制”的原因。 第二种，半同步复制（Semi-synchronous Replication） 为了解决异步复制中“不能保证从库一定收到请求”等问题，对异步复制做了升级。 其核心原理如上图所示： （1）第一条时间线：主库时间线；  - 主库执行事务  - 主库事务串行化binlog  - binlog同步给从库  - 等从库确认收到请求，主库事务才提交完成 （2）第二条/第三条时间线：从库时间线；  - 收到relay log  - 执行和主库一样的事务，并给主库一个确认  - 生成自己的binlog（还可以继续二级从库）  - 从库事务提交完成 从这个时间线可以看到： （1）主库收到从库的ACK，才会提交； （2）从库收到请求后，事务提交前，会给主库一个ACK； 半同步复制存在什么问题呢？ （1）主库的性能，会受到较大的影响，事务提交之前，中间至少要等待2个主从之间的网络TTL； （2）从库仍然有延时，主从之间数据仍然不一致； （3）主从角色有差异，主节点仍然是单点； 大数据量，高并发量的互联网业务，一般不使用“半同步复制”，更多的公司仍然使用“异步复制”的模式。 最后是MySQL5.7里，新提出的MySQL组复制。 第三种，组复制（MySQL Group Replication，MGR） MGR有一些帅气的能力： （1）解决了单点写入的问题，一个分组内的所有节点都能够写入； （2）最终一致性，缓解了一致性问题，可以认为大部分实例的数据都是最新的； （3）高可用，系统故障时（即使是脑裂），系统依然可用； 如上图所示： （1）首先，分组内的MySQL实例不再是“主从”关系，而是对等的“成员”关系，故每个节点都可以写入； （2）其次，增加了一个协商共识的认证（certify）环节，多数节点达成一致的事务才能提交； 画外音：Garela也是此类机制。 结尾稍作总结，为了折衷数据库高可用，一致性，性能等架构设计要素，一般有三类常见复制方式： （1）异步复制，传统主从，互联网公司最常用； （2）半同步复制，从库确认，主库才提交； （3）组复制，MySQL 5.7的新功能，核心在于分布式共识算法； 知其然，知其所以然。 思路比结论更重要。... 展开详请

第一次有人问我这个问题的时候，我心想：互联网大厂，哪有使用PostgreSQL的？因为个人的偏见，自己内心透露着对PostgreSQL的鄙夷。 抱着开放的心态，去墙外调查了一下。我去，PostgreSQL已然超越MySQL成为了世界上最流行的数据库！ 调研方：StackOverflow 调研人群：StackOverflow职业开发者用户（不含学生） 参与人数：60369人 调研时间：2023年底 调研口径：所在企业使用的数据库（多选） 调研结果TOP10如下： PostgreSQL：49.09% MySQL：40.59% SQLite：30.17% SQL-Server：27.34% MongoDB：25.66% Redis：23.25% MariaDB：17.69% ES：15.33% Dynamodb：10.31% Oracle：10.06% 按照stackoverflow的这个统计数据，PostgreSQL超越MySQL，成为世界上最流行的数据库！ 数据是数据，数据背后中外状况的差异，更值得我们思考。 其一，国内外，开源与闭源的比例的差异。 从全球统计数据来看，闭源商业数据库使用比例并不低： SQL-Server：27.34% Oracle：10.06% 但是在国内，闭源商业数据库的使用，却没有这么高的比例，原因是什么呢？ - 企业没有养成付费的习惯？ - 成本费用是我们实施数据库选型的首要因素？ - 合规性与监管要求？ - 厂商在国内的支持不到位？ … 开源免费和闭源收费，本应该相辅相成，如果几乎不付费，真的健康吗？为什么有些企业宁愿自己招人造轮子，也不会考虑外采商业产品呢？ 其二，国内外，开源趋势的差异。 从全球统计数据来看，国外的数据库历史包袱是更重的： Access：3.51% DB2：1.89% Firebird：1.53% Sybase Informix … 中国互联网发展较晚，技术上直接从MySQL起步，几乎没有历史包袱。但近年来兴起的PostgreSQL, MongoDB, MariaDB, Dynamodb… 等后起之秀，在中国几乎没有掀起什么风浪，国内仍是MySQL的天下，原因又是什么呢？ - 国内外市场需求与技术文化的差异？ - 生态系统，社区资源的支持不够？ - 固化的思维？保守的心态？新事物的排斥？ - 语言的问题，导致新技术流入存在时间差？ … 如果PostgreSQL真的是趋势，我们何时能赶上趋势？或者说，是不是够用就行，不用去追赶先进的技术？ 其三，对开源贡献的差异。 这一点，是我看了榜单后最为感触的，咱们的产品，排名最高的是： TiDB：0.19%，排名32位 国内声音很大的OceanBase，PolarDB等产品都没见影子。 我们拥有全球最多的开发者、工程师、架构师、科学家、研究员... 然而，我们的科技创新竞争力却… 为什么会有这样的差距？ - 基础研究与资金投入不够？ - 人员能力不行，沉不下心态度不够？ - 开放文化与创新氛围不够？ - 市场成熟度，产业链与生态完善度不够？ … 结尾 选型，要考虑的点很多。 上面的数据，同步给你。 上面的问题，供你思考，希望对你有帮助。... 展开详请

当数据库的数据量非常大时，水平切分和垂直拆分都降低数据量大小，提升数据库性能。 水平切分是指，以某个字段为依据（例如uid），按照一定规则（例如取模），将一个库（表）上的数据拆分到多个库（表）上，以降低单库（表）大小，达到提升性能的目的的数据库架构设计方法。 水平切分后，各个库（表）的特点是： 1. 每个库（表）的结构都一样； 2. 每个库（表）的数据都不一样，没有交集； 3. 所有库（表）的并集是全量数据； 垂直拆分是指，将一个属性较多，一行数据较大的表，将不同的属性拆分到不同的表中，以降低单库（表）大小，达到提升性能的数据库架构设计方法。 垂直切分后，各个库（表）的特点是： 1. 每个库（表）的结构都不一样； 2. 一般来说，每个库（表）的属性至少有一列交集，一般是主键； 3. 所有库（表）的并集是全量数据； 举个例子，用户表： user(     uid bigint, name varchar(16), pass varchar(16), age int, sex tinyint, flag tinyint, sign varchar(64), intro varchar(256) …); 垂直拆分之后，可能变成两个这样的表： user_base( uid bigint, name varchar(16), pass varchar(16), age int, sex tinyint, flag tinyint, …); user_ext( uid bigint, sign varchar(64), intro varchar(256) …); 垂直切分的依据是什么？ 当一个表属性很多时，垂直拆分依据主要有几点： 1. 将长度较短，访问频率较高的属性尽量放在一个表里，这个表暂且称为主表； 2. 将字段较长，访问频率较低的属性尽量放在一个表里，这个表暂且称为扩展表； 3. 经常一起访问的属性，也可以放在一个表里； 为什么要这么这么拆分？ 1. 数据库有自己的缓冲池buffer_pool，会将磁盘上的数据load到缓冲池里； 2. 缓冲池物理上以页page为单位，逻辑上以行row为单位，缓存数据； 3. 在内存有限，缓冲池大小固定的情况下，长度较短的row，能缓存更多数据； 4. 缓存高频的列column，能提升缓冲池命中率，减少磁盘IO； 举个例子： 1. 假设数据库内存buffer为1G，未拆分的user表1行数据大小为1k，那么只能缓存100w行数据； 2. 如果垂直拆分成user_base和user_ext，其中user_base访问频率高，1行大小为0.1k，就能缓存1000w行数据； 此时，访问磁盘的概率会大大降低，数据库访问的时延会大大降低，吞吐量会大大增加。 简单总结： 1. 海量数据高并发的数据库场景，水平切分，垂直拆分能提升数据库性能； 2. 垂直拆分核心依据是：将长度较短，访问频率较高的属性尽量放在主表里。 补充阅读材料： 《数据库水平切分+垂直拆分简介》 https://www.baeldung.com/cs/databases-horizontal-vertical-partitioning 希望对你有帮助。... 展开详请

数据库的选型，是根据业务需求来决定的。业务需求不同，数据库的选择也是不同的。任何脱离业务的需求选型都是耍流氓。 选型的过程中，你可能要考虑这些因素。 其一，功能特性 ​数据模型支持 ​关系型与非关系型：如果应用主要基于传统的关系型数据模型，如金融交易系统中的账务数据管理，需要数据库支持标准的SQL查询语言、事务处理（ACID特性）等关系型功能。对于一些新兴的大数据分析场景，如物联网设备数据存储和分析，可能更倾向于支持非关系型数据模型（如文档型、键值对型、图型等）的数据库，以更好地适应数据的多样性和灵活性。 ​多模态数据支持：考虑数据库是否能够统一管理和查询多种类型的数据，例如同时处理结构化、半结构化和非结构化数据。这在一些综合性业务场景中非常有用，如电商平台需要处理商品信息（结构化）、用户评价（半结构化）和商品图片（非结构化）等多种数据类型。 ​分布式架构能力 ​数据分片策略：了解数据库支持的分片方式，如哈希分片、范围分片等。不同的分片策略适用于不同的业务场景。例如，对于按照用户ID进行数据隔离和查询优化的场景，哈希分片可能更合适；而对于按照时间范围查询数据的场景，如日志分析系统，范围分片可能更具优势。 ​分布式事务处理：在分布式环境下，确保数据一致性的分布式事务处理机制至关重要。考察数据库是否支持强一致性事务，以及在高并发场景下如何保证事务的性能和隔离性。例如，在跨多个数据中心的金融交易系统中，需要数据库能够在分布式节点之间准确无误地处理事务，防止数据不一致的情况发生。 ​弹性扩展能力：评估数据库是否能够方便地进行水平扩展（增加节点）和垂直扩展（升级节点硬件资源），以应对业务增长带来的数据量和负载压力。例如，随着电商促销活动期间订单量的急剧增加，数据库应能够快速扩展资源来保证系统的稳定性和响应速度。 其二，性能指标 ​读写性能 ​吞吐量：衡量数据库在单位时间内能够处理的读写操作数量。对于高并发的互联网应用，如在线游戏或大型电商平台，需要数据库具有较高的吞吐量来保证大量用户的同时访问。 ​响应时间：关注数据库对单个读写操作的响应速度。在对实时性要求较高的场景下，如金融高频交易系统，低延迟的响应时间能够确保交易的及时性和准确性。 ​可扩展性性能 ​线性扩展能力：测试在增加节点数量时，数据库性能是否能够按照预期的比例提升。这对于构建大规模分布式数据存储和处理系统非常关键，确保随着业务的增长，系统可以通过简单地添加节点来满足性能需求。 其三，数据可靠性与安全性 ​数据可靠性保障 ​数据备份与恢复机制：考察数据库提供的备份策略（全量备份、增量备份等）和恢复方式（如从备份文件恢复、基于日志的恢复等）。对于企业级应用，尤其是涉及重要业务数据的场景，可靠的数据备份和快速恢复能力是必不可少的。 ​数据冗余与容错设计：了解数据库如何在分布式节点之间实现数据冗余存储，以提高数据的可用性和容错能力。例如，采用多副本技术，当某个节点出现故障时，其他副本能够继续提供服务，确保系统的不间断运行。 ​安全特性 ​身份认证与授权管理：评估数据库提供的用户身份验证方式（如用户名/密码、数字证书等）和细粒度的授权机制，确保只有合法的用户能够访问和操作相应的数据资源。 ​数据加密：考察数据库是否支持对数据在传输过程（如SSL/TLS加密）和存储过程（如磁盘加密、字段级加密）进行加密，以保护敏感信息的安全性。 其四，兼容性与集成性 ​与现有系统的兼容性 ​操作系统与硬件平台：确保所选的分布式数据库能够在企业现有的操作系统（如Linux的不同发行版、Windows Server等）和硬件架构（如x86、ARM等）上稳定运行，避免因兼容性问题导致的系统部署和维护困难。 ​应用程序接口（API）兼容性：如果企业已经有大量的现有应用程序与数据库交互，需要考察新的分布式数据库是否支持这些应用程序所使用的API（如JDBC、ODBC等），或者是否提供方便的迁移工具和适配层，以降低应用改造的成本和风险。 ​与其他组件的集成能力 ​大数据生态系统集成：对于涉及大数据分析的场景，数据库应能够与企业常用的大数据处理框架（如Hadoop、Spark等）和数据仓库（如Hive、Snowflake等）进行良好的集成，方便数据的流转和处理。 ​云平台集成：如果企业采用云服务，考察数据库是否能够与选定的云平台（如阿里云、腾讯云等）无缝集成，利用云平台提供的各种资源和服务（如存储、计算、网络等），简化数据库的部署和管理。 其五，易用性与运维管理 ​安装与部署便捷性 ​安装过程复杂度：选择安装过程简单、自动化程度高的数据库产品，能够减少部署时间和人力成本。例如，一些分布式数据库提供了图形化的安装向导或一键式部署脚本，使得在多节点环境下的安装变得更加容易。 ​配置管理灵活性：考察数据库是否支持灵活的配置参数调整，以适应不同的业务场景和硬件环境。同时，配置管理工具应该易于使用，方便管理员进行日常的配置维护和优化。 ​监控与管理工具 ​内置监控指标丰富度：数据库应提供全面的监控指标，如性能指标（CPU使用率、内存占用、磁盘I/O等）、资源利用率、事务状态等，以便管理员及时了解数据库的运行状况。 ​自动化运维能力：具备自动化运维功能的数据库能够减轻管理员的工作负担，如自动故障检测与修复、自动负载均衡、自动数据归档等功能。 其六，成本因素 ​软件授权成本 ​许可证模式：了解数据库的软件授权方式，是基于节点数、用户数还是数据量等进行收费。不同的授权模式对于不同规模和业务需求的企业来说成本差异较大，需要根据实际情况进行评估。 ​开源与商业版本选择：考虑是否有合适的开源版本可以满足业务需求，开源版本通常可以降低软件采购成本，但可能需要企业自己投入更多的技术力量进行维护和支持；商业版本则提供更专业的技术支持和增值服务，但成本相对较高。 ​硬件与运维成本 ​硬件资源需求：评估数据库在不同负载下的硬件资源消耗情况，包括CPU、内存、存储等，以确保企业在采购硬件时能够合理规划资源，避免过度投资。 ​运维人力成本：考虑数据库的运维难度和对运维人员技术水平的要求。易于运维管理的数据库可以减少企业在运维方面的人力投入，降低运维成本 。 可以根据自己的业务需求进行选型。 希望能够帮到你。... 展开详请

系统性了解数据库架构演进与发展的历程，能够更好的帮你了解“计算和存储分离”。 最早的数据库都是单机的，其最大的痛点是啥？ 无法线性扩展。 磁盘能力无法线性扩展，内存能力无法线性扩展，计算能力无法线性扩展。 架构师们称之为“Shared Everything”架构。 如上图所示，DISK/MEM/CPU 都耦合在一个DBMS进程内，必须部署在一台服务器上，完全处于竞争态，无法线性扩展，并行处理较差。 数据库单机部署，就是典型的“Shared Everything”架构。 如何来提升系统的并行能力呢？ 最容易想到的，就是把无状态的逻辑计算部分，从DBMS进程内拆分出来，做成可扩展的微服务集群，实现“计算与存储分离”。 如上图所示： （1）CPU逻辑计算拆分出了独立的进程，可以集群部署，能够线程扩展； （2）DISK/MEM 仍耦合在一个进程内，仍处于竞争态，无法线性扩展； Oracle Rac，就是典型的“Shared Disk”架构，核心思路是“计算与存储分离”。 存储部分磁盘IO仍有集中的资源竞争，还有没有进一步的优化空间呢？ 最容易想到的，就是把数据打散，分布到不同的数据库实例上，每部分数据享有单独的资源。 如上图所示： （1）把整体数据存储分为了N份，每份之间没有交集； （2）每份数据的 DISK/MEM/CPU 都在一个DBMS进程内，部署在一台服务器上； （3）每份数据的资源之间的没有竞争； 没错，这就是“水平切分”，它是典型的”Shared Nothing”架构。 稍作总结，数据库扩展性scalability架构： Shared Everything：数据库单机系统，资源竞争； Shared Disk：Oracle Rac，计算与存储分离； Shared Nothing：水平切分，复制集群，资源完全隔离； 希望对你有帮助。... 展开详请

兄弟，何出此问？你是在国企，要做软件自主化改造吗？ 这么说吧，我了解到的互联网公司，没有用国产数据库的。别为了情怀，给自己埋坑。 补充： 读研的时候，曾在达梦数据库写过一些内核代码，达梦真的超牛逼！ 我很爱国，我买股票永远做多自己的国家！ 我很希望，有一天我们的数据库能霸榜全球！... 展开详请