简述数据库发展史

本文涉及的产品
RDS AI 助手,专业版
RDSClaw,2核4GB
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
简介: 数据库发展史

前言


现在是大数据时代,互联网需求比90年更大(90年网站的访问量一般不会太大,单个数据库足够),普通的mysql满足不了,数据库单表数据量超过三百万所以分离读写操作(数据库主要就是进行读写操作),缓存可以有效避免用户对数据库的直接访问减少压力(mysql单表数据300万以上就一定要建立索引!).缓存也从传统的memcached交换成新的缓存技术redis


关于数据库的写的发展:

早些年Myisam:表锁(每次查询只锁这一张表),十分影响效率!高并发的时候会出现严重的锁问题

后来转战Innodb:行锁(每次查询只锁这一行)

慢慢的就开始使用分库分表来解决写的压力,Mysql在那个年代推出了表分区!但是并没有多少公司使用

Mysql的集群,很好的满足了那个年代的所有需求

如今的年代(大数据年代)

Mysql等关系型数据库就不够用了,数据量很大,变化也很快(微博热搜,排行榜等)

关系型数据库什么意思?


关系型数据库:就好比我们的表格,是由行和列来记录的

关系型数据库,是指采用了关系模型来组织数据的数据库,其以行和列的形式存储数据,以便于用户理解,关系型数据库这一系列的行和列被称为表,一组表组成了数据库。

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
SQL 存储 关系型数据库
数据库发展史
数据库发展史
1054 0
|
存储 NoSQL 关系型数据库
数据库的发展史
数据库的发展史
|
存储 分布式计算 Oracle
数据库发展史2--数据仓库
回顾数据仓库的发展历程,大致可以将其分为几个阶段:萌芽探索到全企业集成时代、企业数据集成时代、混乱时代--"数据仓库之父"间的论战、理论模型确认时代以及数据仓库产品百家争鸣时代。
645 0
数据库发展史2--数据仓库
|
存储 SQL 分布式计算
浅谈数据库发展史和 OceanBase 的诞生
本文主要介绍数据库的发展,带大家共同回顾这一历史进程,也将首次揭秘 OceanBase 诞生的故事。
浅谈数据库发展史和 OceanBase 的诞生
|
7月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
495 158
|
7月前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。
|
7月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格:MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB,多种引擎优惠上线!MySQL倚天版88元/年,SQL Server 2核4G仅299元/年,PostgreSQL 227元/年起。高可用、可弹性伸缩,安全稳定。详情见官网活动页。
1246 152
|
7月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎,提供高性价比、稳定安全的云数据库服务,适用于多种行业与业务场景。
924 156
|
7月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(中)
使用MYSQL Report分析数据库性能
521 156
|
7月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
626 161

热门文章

最新文章

下一篇
开通oss服务