技术

下一个平台Agent 激发LLM涌现——提示工程 LLM微调理论及实践 大佬沉思 LLM外挂知识库 LLMOps 多模态LLM Python一些比较有意思的库 LLM部分技术源码学习 LangChain源码学习 通用分布式计算引擎Ray Python并发 go依赖注入 go collection gc的基本原理 golang性能分析及优化 数据湖 高性能计算与存储 Linux2.1.13网络源代码学习 《大数据经典论文解读》 三驾马车学习 Spark 内存管理及调优 Yarn学习 从Spark部署模式开始讲源码分析 容器狂占内存资源怎么办? 多角度理解一致性 golang io使用及优化模式 Flink学习 c++学习 学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器以及defer实现 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go堆内存分配 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 共识算法 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 容器日志采集 Kubernetes 控制器模型 容器狂占资源怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 如何分发计算 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂? 递归、回溯、动态规划 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型和jvm内存布局 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle/make使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

大模型推理服务框架 模型服务化(未完成) 大模型RHLF 大模型训练 大模型推理 从Attention到Transformer k8s设备管理 LLM工具栈 ddd从理念到代码 如何应用LLM 小鼠如何驾驭大象(LLM)? 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 AutoML和AutoDL 特征平台 实时训练 分布式链路追踪 helm tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 机器学习中的python调用c 机器学习训练框架概述 embedding的原理及实践 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从混部到统一调度 从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 tensorflow学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Admission Controller 与 Admission Webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 概率论 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 架构大杂烩 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

k8s设备管理 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 helm 从混部到统一调度 volcano特性源码分析 kubebuilder 学习 client-go学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 openkruise学习 基于Kubernetes选主及应用 Admission Controller 与 Admission Webhook k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? Kubernetes events学习及应用 CRI 资源调度泛谈 如何学习Kubernetes 以应用为中心 kubernetes operator kubernetes扩缩容 serverless 泛谈 什么是云原生 自定义CNI IPAM docker和k8s安全访问机制 Kubernetes监控 Kubernetes 控制器模型 Kubernetes资源调度——scheduler Kubernetes类型系统 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 Kubernetes源码分析——从kubectl开始 kubernetes yaml配置 CNI——容器网络是如何打通的 当我在说PaaS时,我在说什么 《深入剖析kubernetes》笔记 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件

数据库的一些知识

2016年09月21日

简介

数据库存储选型经验总结 未读

数据库治理的云原生之道 —— Database Mesh 2.0

数据的组织

从单机到分布式数据库存储系统的演进单机数据库存储,要从内存层和持久化层两个方面来解析。

  1. 在内存层,仅说关系型数据库,其内存数据结构特点可以总结为:一切都是“树”。我们以最常见的 B+ 树为例,B+ 树具有以下突出的特点:
    1. In memory 操作效率非常高: B+ 树搜索时间复杂度是 log 级别;并且 B+ 树的叶子节点构成链表,非常有利于在内存中对数据进行 scan 操作。
    2. 磁盘操作效率高:B+ 树的 Fanout 足够大,树的层级较少,呈矮胖状,可以减少磁盘 IO 数;同时 B+ 树的非叶子节点只存索引数据,叶子节点存实际数据,能大大压缩树高,进一步减少磁盘 IO 数。
    3. 数据结构高度统一:数据 & 索引都可以直接组织成 B+ 树,因此代码的可维护性、可读性和开发效率都比较好。
  2. 基于单机的 FS / 块存储去做持久化,我们会遇到哪些问题呢?
    1. 单机容量瓶颈:在 Database 层的单机服务器上运行着 database 进程,服务器上挂载了大量本地磁盘用作数据持久化。但一台物理服务器能挂载的磁盘容量总是有限的,这就导致了单机的容量瓶颈问题。
    2. 扩缩容困难:当容量、CPU 或者内存等资源不够时,我们需要进行扩容。在单机时代,扩容意味着将数据从这个磁盘搬迁到另一个磁盘。但不管我们是通过网络还是有线连接手段,都需要花费一定的时间,这可能导致业务较长时间的停写(不可用),因此扩缩容是非常困难的。
    3. 多份独立数据,成本高:如果我们要在“复制集”之间或者主备机之间去做数据冗余或数据同步,那么每新增一分计算能力(新增一个计算节点),就要新增一分存储冗余,就会导致存储成本提高。

存储

文件

关系型数据库中往往都包含 Log 数据和 Page 数据。

假定数据库存放数据的文件称为data file,数据库的内容在内存里是有缓存的,称为db buffer。某次操作,我们取了数据库某表格中的数据,这个数据会在内存中缓存一些时间。对这个数据的修改在开始时候也只是修改在内存中的内容。当db buffer已满或者遇到其他的情况,这些数据会写入data file。(为了维护这个db buffer和db file的一致性,引入了checkpoint)

db buffer的存在不仅提高了性能,系统也有机会对db buffer进行一定整理后集中写入,毕竟db数据随机写入的开销比较大。log file一般是追加内容,可以认为是顺序写。

kv

MyRocks: MySQL + RocksDB,是单机 SQL over kv 的典型代表。

  1. 核心理念:用 RocksDB 替换 InnoDB 。使用 RocksDB 能够有效缓解单机容量瓶颈的问题;
  2. 特点:一是:数据可压缩比例较高。RocksDB 实现了一种比较优秀的压缩算法,根据实际调研结果显示,在关系型数据库场景,基本上它能实现 2-4 倍的压缩比,能有效缓解单机的容量瓶颈问题。例如,单机原本挂载了 10 块磁盘,只能承载 10 TB 数据,使用 RocksDB 就能在不改变硬件条件下帮助单机承载 20 TB 或 30 TB 等更多的数据;二是,顺序写性能较好,这也是 LSM-Tree 这种数据结构在 HDD 年代出现的核心原因。
  3. 难点:Compaction 会导致性能抖动,且兼容性一般。众所周知,RocksDB 基于 LSM-Tree 构建,必然会遇到一些典型的 LSM-Tree-based 系统的问题。虽然 RocksDB 对顺序写特别友好,但它一定程度上牺牲了读性能—— RocksDB 在读的过程中会触发 Compaction,可能引发性能抖动,导致前台的写出现卡顿现象;同时,这一类 SQL over kv 解决方案的兼容性能表现较为一般。

计算存储分离

  1. Amazon Aurora核心理念:计算存储分离,Log is Database。存储层带有特定的数据库计算逻辑,除了具备存储能力之外,还具备 Redo Log 解析、回放生成数据库 Page、维护多版本数据的能力。
  2. Spanner 系: 计算存储分离,且 Share-Nothing。Spanner 系的数据库系统一般基于分布式 k-v 存储构建,由存储层保证事务特性,计算层做成纯计算的无状态节点。

列式存储

当一行数据有 100 个字段,而我们的分析程序只需要其中 5 个字段的时候,就很尴尬了。因为如果我们顺序解析读取数据,我们就要白白多读 20 倍的数据。那么,能不能跳着只读我们需要的字段呢?当然也是不行的,因为对于硬盘来说,顺序读远远要优于随机读。

不过,这样存储之后,数据写入就变得有些麻烦了。原先我们只需要顺序追加写入数据,而现在我们需要向很多个文件去追加写入数据,那有没有什么好办法呢?对于追加写入的数据,我们可以先写 WAL 日志,然后再把数据更新到内存中,接着再从内存里面,定期导出按列存储的文件到硬盘上。事实上,在一个分布式的环境里,我们的数据其实并不能称之为 100% 的列存储。因为我们在分析数据的时候,可能需要多个列的组合筛选条件。所以,更合理的解决方案是行列混合存储。在单个服务器上,数据是列存储的,但是在全局,数据又根据行进行分区,分配到了不同的服务器节点上。

未来发展

在谈及数据库存储的未来演进时,首先我们可以思考一下哪些因素会触发数据库存储架构的变革和演进?答案可能包含:存储架构自身的革命、数据库理论的突破、或者新硬件冲击引发存储系统架构迭代。基于这三个方向的思考,我们总结了以下几个数据库存储系统的演进趋势:

  1. 在 HTAP/HSAP 系统中,“实时”是第一关键词。为了支持实时,存储系统可能会发生架构演进和变革,因此我们需要探索:
    1. 行列存 All-in-one:既要存储行式的数据,又要存储列式的数据。
    2. 近实时,写时计算:我们需要在存储层实现写时计算的逻辑来支持实时性。
  2. 在硬件变革趋势上,我们总结了三个变革方向:
    1. 前几年,我们可能更多关注 SSD、HDD。目前我们处于 SSD 往 persistent memory 转变的风口,那么如何利用 persistent memory 去定制软件架构?
    2. 计算单元变革:CPU 产品已经从 multi-core 变成了 many-core (从 96c 变成了 192c、384c)。要怎么利用多核的能力?对于非计算密集型的存储系统而言,多余的算力能否用来加速数据库算子?一些无锁的数据结构是不是需要要重新设计?以上都需要我们认真考虑。
    3. 网络设施变革:例如 RDMA ,以及可编程的 P4 交换机这类全新的一些网络设施,可能会对我们的软件架构特别是分布式存储架构造成较大的冲击。相应地,我们需要在存储侧做出调整。

OceanBase CTO杨传辉:怎么理解HTAP? 未读

基于AI算法的数据库异常监测系统的设计与实现

为什么要用 Tair 来服务低延时场景 - 从购物车升级说起 未读

云原生数据库的优势到底体现在哪些方面?

  1. 大部分云原生数据库将 SQL 语句解析、物理计划执行、事务处理等都放在一层,统称为计算层。而将事务产生的日志、数据的存储放在共享存储层,统称为存储层。在存储层,数据采用多副本确保数据的可靠性,并通过 Raft 等协议保证数据的一致性。计算节点与存储节点之间采用高速网络互联,并通过 RDMA 协议传输数据,让 I/O 性能不再成为瓶颈。
  2. 云原生数据库拆解了计算、存储,并利用网络发挥分布式的能力,在这三个层面都充分结合新硬件的特性进行设计。未来的数据库将步入全栈优化时代,从硬件平台优化到架构层优化再到上面的应用层优化。所谓“软件优化三年不如硬件更新一代”,比如算力上,一定是充分利用 CPU 最底层的指令集和最新的加速器。

开发者的“技术无感化”时代,从 Serverless HTAP 数据库开始 “数据库作为一个软件形态本身会消亡,而数据库的平台化、微服务化会取代原来的数据库软件形式”。PS:我只是去调一个服务,接口是SQL,与XXService.QueryXX并没有区别。

  1. 我们一开始花了很长时间去构建了一个稳定的数据库内核,可以弹性扩展、自动 Failover、ACID Transaction 等非常硬核的基础能力。但这些都是基础能力,这些东西应该隐藏在发动机里。作为一个开车的人,不用关心变速箱里有哪些特性;
  2. HTAP 能够提供实时的一栈式数据服务。用户不需要关心什么是 OLAP,什么是 OLTP。一套系统可以支撑所有负载,也不用担心 OLAP 负载影响 OLTP 的正常服务;
  3. 基础设施层面,Serverless 部署的成本变得极低,极致的 Serverless 不用关心任何运维的细节。你可以通过代码和 open API 控制这些集群的起停。真正的按需计费。过去我们其实还是按照服务器、虚拟机这样的资源来去看待一个月多少钱,这个服务能不能粒度更细一些,只收业务流量的钱?尤其是对于偏分析的场景来说,有很多时候我们做大数据分析,比如每天半夜要去跑个报表,可能需要一千个虚拟机算,20 秒钟算完,然后再缩回来。
  4. 我自己写了一个小程序,在一个全新的环境下,通过代码启动一个 TiDB 的 Serverless Tier 实例。在这个过程里,我只是告诉这个程序,要启动一个集群,这个集群叫什么名字,然后把密码一输,20 秒之后可以直接拿一个 MySQL 客户端连上去了,这个时间未来会进一步缩短。你不用关心它的扩展性,即使上线以后,业务流量变得巨大无比的时候,它也能够很好地扩容上去,没有流量的时候,它还能缩回来。

如果重新设计一款数据库,架构会是什么样子?

  1. 我们过去开发程序,不同的模块看到的环境是同构且确定的,即使近几年的分布式系统的兴起,但对于经典的分布式软件来说,大致还是单机软件设计思路的延伸,只是通过 RPC 将多台计算机连接在一起,但是仍然环境是相对确定的,尽管很多软件对于底层的环境变化做了一些适配:例如分布式数据库的动态扩容,数据重均衡 Re-balance 等,但是本质并未变化,只是能够操控和调度的资源变多了。但是在云上,这些假设都发生了变化:
    1. 多样且几乎无限的资源通过 Service API 的形式提供,对于资源的调度和分配可以通过代码完成,这是革命性的变革。
    2. 一切资源明码标价,所以程序优化的方向从过去的一维的榨取最好的性能(因为硬件的成本已经事先支付),变成一个动态的问题:尽量花小钱办大事。
  2. 假设的变化带来的技术上的变化:云上的数据库,首先应该是 多个自治的微服务组成的网络。放弃掉对于同步和单机的幻想
    1. 最近几年被聊烂的存算分离
    2. 对于数据库来说,一些内部组件的微服务化,比如:日志(CPU 使用少,但是对于存储要求高),LSM-Tree 存储引擎的 Compaction,数据压缩,元信息服务,连接池,CDC 等等,都是可以且很适合被剥离的对象。

How do you build a database

摘自How do you build a database? ,为防止链接失效,贴上原文。

Its a great question, and deserves a long answer. Most database servers are built in C, and store data using B-tree type constructs. In the old days there was a product called C-Isam (c library for an indexed sequential access method) which is a low level library to help C programmers write data in B-tree format. So you need to know about btrees and understand what these are. BTree 很重要

Most databases store data separate to indexes. Lets assume a record (or row) is 800 bytes long and you write 5 rows of data to a file. If the row contains columns such as first name, last name, address etc. and you want to search for a specific record by last name, you can open the file and sequentially search through each record but this is very slow. Instead you open an index file which just contains the lastname and the position of the record in the data file. Then when you have the position you open the data file, lseek to that position and read the data. Because index data is very small it is much quicker to search through index files. Also as the index files are stored in btrees in it very quick to effectively do a quicksearch (divide and conquer) to find the record you are looking for. 一个表单单数据文件是不够的,需要一/多个索引文件。

So you understand for one “table” you will have a data file with the data and one (or many) index files. The first index file could be for lastname, the next could be to search by SS number etc. When the user defines their query to get some data, they decide which index file to search through. If you can find any info on C-ISAM (there used to be an open source version (or cheap commercial) called D-ISAM) you will understand this concept quite well.

Once you have stored data and have index files, using an ISAM type approach allows you to GET a record based on a value, or PUT a new record. However modern database servers all support SQL, so you need an SQL parser that translates the SQL statement into a sequence of related GETs. SQL may join 2 tables so an optimizer(优化器最初是为了加快join表的速度么?) is also needed to decide which table to read first (normally based on number of rows in each table and indexes available) and how to relate it to the next table. SQL can INSERT data so you need to parse that into PUT statements but it can also combine multiple INSERTS into transactions so you need a transaction manager to control this, and you will need transaction logs to store wip/completed transactions.

It is possible you will need some backup/restore commands to backup your data files and index files and maybe also your transaction log files, and if you really want to go for it you could write some replication tools to read your transaction log and replicate the transactions to a backup database on a different server. Note if you want your client programs (for example an SQL UI like phpmyadmin) to reside on separate machine than your database server you will need to write a connection manager that sends the SQL requests over TCP/IP to your server, then authenticate it using some credentials, parse the request, run your GETS and send back the data to the client. So these database servers can be a lot of work, especially for one person. But you can create simple versions of these tools one at a time. Start with how to store data and indexes, and how to retrieve data using an ISAM type interface. There are books out there - look for older books on mysql and msql, look for anything on google re btrees and isam, look for open source C libraries that already do isam. Get a good understanding on file IO on a linux machine using C. Many commercial databases now dont even use the filesystem for their data files because of cacheing issues - they write directly to raw disk. You want to just write to files initially. I hope this helps a little bit.

概要内容:

  1. 知道BTree 很重要
  2. 一个表单单数据文件是不够的,需要一/多个索引文件,数据文件和索引文件分开存储
  3. 有了数据文件和索引文件,你就可以读写数据了,但你需要SQL parser 将sql 翻译成读写操作,需要optimizer加快join表的速度,需要Transaction manager 管理事务
  4. 备份儿/恢复数据文件、索引文件、Transaction log文件。如果支持客户端程序的话,还需要一个Connection manager

其它

数据库治理利器:动态读写分离 未读t