分布式数据库和集中式数据库有什么区别，各有什么优势？

java线程池怎么用最安全？https://bbs.huaweicloud.com/forum/thread-02116134011080136032-1-1.htmlmysql大批量数组in查询的时候效率问题https://bbs.huaweicloud.com/forum/thread-0296134011022191031-1-1.html针对枚举类型字段是否有必要加索引https://bbs.huaweicloud.com/forum/thread-0273134010894710031-1-1.html 如何修改RDS实例管理员信息？ https://bbs.huaweicloud.com/forum/thread-0275133665350138039-1-1.html在控制台输入mysql -u root -p 报错command not foundhttps://bbs.huaweicloud.com/forum/thread-0235133622699806025-1-1.html华为云数据库的延迟和处理突发事件上对数据的安全怎么样？https://bbs.huaweicloud.com/forum/thread-0235133622363369024-1-1.html看到小助手回复的华为云数据库种类 这么多种类都是做什么的？https://bbs.huaweicloud.com/forum/thread-0291133621815356028-1-1.html什么是云数据库RDS？https://bbs.huaweicloud.com/forum/thread-0255132906325432004-1-1.htmlmysql数据库和华为云数据库的区别https://bbs.huaweicloud.com/forum/thread-0258133535980717021-1-1.htmljava解析KAKFKA从DRS获取的AVRO数据反序列化问题https://bbs.huaweicloud.com/forum/thread-02125134119629898043-1-1.html如何在华为云数据库中实现数据的加密和安全性？https://bbs.huaweicloud.com/forum/thread-0248134149790237068-1-1.html

什么是向量检索向量是具有一定大小和方向的量，可以简单理解为一串数字的集合，就像一行多列的矩阵，比如：[2,0,1,9,0,6,3,0]。每一行代表一个数据项，每一列代表一个该数据项的各个属性。特征向量是包含事物重要特征的向量。大家比较熟知的一个特征向量是RGB (红-绿-蓝)色彩。每种颜色都可以通过对红®、绿(G)、蓝(B)三种颜色的比例来得到。这样一个特征向量可以描述为：颜色 = [红，绿，蓝]。向量检索是指从向量库中检索出距离目标向量最近的 K 个向量。一般我们用两个向量间的欧式距离，余弦距离等来衡量两个向量间的距离，一次来评估两个向量的相似度Milvus 介绍Milvus的官网地址是：cid:link_10 github地址是：https://github.com/milvus-io/milvus，目前Fork数为：2.6k，Star有23.7kMilvus创建于2019年，其目标只有一个:存储、索引和管理由深度神经网络和其他机器学习(ML)模型生成的大量嵌入向量。作为一个专门设计用于处理输入向量查询的数据库，它能够在万亿规模上对向量进行索引。与现有的关系数据库主要按照预定义的模式处理结构化数据不同，Milvus是从自底向上设计的，以处理从非结构化数据转换而来的嵌入向量。Milvus 是一款开源的向量数据库，支持针对 TB 级向量的增删改操作和近实时查询，具有高度灵活、稳定可靠以及高速查询等特点。Milvus 集成了 Faiss、NMSLIB、Annoy 等广泛应用的向量索引库，Milvus 支持数据分区分片、数据持久化、增量数据摄取、标量向量混合查询、time travel 等功能，同时大幅优化了向量检索的性能，可满足任何向量检索场景的应用需求，提供了一整套简单直观的 API，让你可以针对不同场景选择不同的索引类型。此外，Milvus 还可以对标量数据进行过滤，进一步提高了召回率，增强了搜索的灵活性。Milvus 采用共享存储架构，存储计算完全分离，计算节点支持横向扩展。从架构上来看，Milvus 遵循数据流和控制流分离，整体分为了四个层次:分别为接入层（access layer）、协调服务（coordinator service）、执行节点（worker node）和存储层（storage）。各个层次相互独立，独立扩展和容灾。随着互联网的发展和发展，非结构化数据变得越来越普遍，包括电子邮件、论文、物联网传感器数据、Facebook照片、蛋白质结构等等。为了让计算机理解和处理非结构化数据，使用嵌入技术将这些数据转换为向量。Milvus存储并索引这些向量。Milvus能够通过计算两个向量的相似距离来分析它们之间的相关性。如果两个嵌入向量非常相似，则表示原始数据源也非常相似。Milvus 向量数据库专为向量查询与检索设计，能够为万亿级向量数据建立索引。与现有的主要用作处理结构化数据的关系型数据库不同，Milvus 在底层设计上就是为了处理由各种非结构化数据转换而来的 Embedding 向量而生。虚拟机+docker 搭建 milvus的硬件要求使用Docker Compose独立安装Milvus，安装前请检查硬件和软件的要求：至少使用2个vcpu和8gb的初始内存。否则可能导致安装失败。详见官网：cid:link_4下载docker-compose配置文件先安装wget命令yum install wget下载配置文件，通过docker-compose进行安装wget https://github.com/milvus-io/milvus/releases/download/v2.3.2/milvus-standalone-docker-compose.yml如果无法访问github，可以直接通过浏览器下载，然后通过rz命令上传到虚拟机yum install lrzsz -y由于后期milvus会在当前目录生成很多数据，因此建议创建一个新的目录，然后再上传 docker-compose.yml 文件mkdir milvus cd milvus rz安装 dockeryum install docker安装docker-compose直接下载release版本手动安装首先找到docker-compose的github路径：cid:link_5uname -a 查看系统信息uname -s 查看系统名称uname -a 查看系统架构下载安装文件sudo curl -L "cid:link_5/download/2.23.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose赋予执行权限sudo chmod +x /usr/local/bin/docker-compose创建软连接sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose测试，能出版本号就说明安装成功了docker-compose --version使用pip 命令自动安装安装 pipyum -y install epel-release yum -y install python-pip升级 pip pip install --upgrade pip安装 docker-compose 插件 pip install docker-compose验证安装是否成功 docker-compose --version通过 docker-compose 启动容器在没启动docker 的情况下，直接启动docker-compose会报错，因此要先启动docker，并将docker设置为开机自动启动systemctl start docker systemctl enable docker通过docker-compose up -d 命令在后台运行docker-compose容器，默认的配置文件名是 docker-compose.yml，可以通过-f 参数进行修改 sudo docker-compose -f milvus-standalone-docker-compose.yml up -d使用下面命令，查看容器允许状态，我这里全部启动失败了docker-compose ps -a使用下面命令，查看容器出错日志sudo docker-compose logs etcd | grep error报错的内容是目录无法访问： open /etcd: permission denied，这是因为CentOS7中的安全模块selinux把权限禁掉了。解决办法在控制台里面输入 setenforce 0 关闭 selinux在docker 命令中配置 --privileged=true，或者在 docker-compose 服务里增加 privileged: true (因为milvus会启动3个服务，因此这里一共要加3处) 注意，如果你修改了存放目录，这里要先删除之前的镜像docker rm milvus-standalone docker rm milvus-minio docker rm milvus-etcd然后重新启动容器（我这里在前台启动，目的是方便查看日志，所以我没加-d参数）sudo docker-compose -f milvus-standalone-docker-compose.yml up搭建python环境在外部window系统搭建如果你是在window上通过python连接虚拟机中的Milvus，只需要在window中安装 python 环境即可（ 我这里装的是 anaconda + python3.11.4 ）pip3 install pymilvus==2.3.2在虚拟机中搭建如果你要直接在虚拟机中运行python，则需要在虚拟机中安装python环境，具体步骤如下首先，安装anaconda：cid:link_8wget cid:link_8Anaconda3-2023.09-0-Linux-x86_64.sh由于我这里wget出错，因此我是直接从window上下载，然后使用rz命令传到centos7虚拟机的下载完sh安装文件后，先给文件加上可执行权限chmod +x Anaconda3-2023.09-0-Linux-x86_64.sh然后执行命令进行安装bash Anaconda3-2023.09-0-Linux-x86_64.sh# 按照安装提示，键入回车 Please, press ENTER to continue >>> ENTER # 中途大概按两次回车进行翻页 # 输入yes，表示同意安装协议 Do you accept the license terms? [yes|no][no] >>> yes # 多次yes后安装成功安装好后，anaconda会写入你的环境变量（用户名不同，地址也会有所不同）执行 source ~/.bashrc 命令刷新环境变量，然后就可以使用 conda --version 查看 conda 的版本了。目前最新版的 conda 是 23.7.4 版本，对应的python 版本是 3.11.5 （centos7 默认的python版本是2.7.5，这里是进入了conda 的base环境，所以是3.11.5版本）milvus需要的是python3.7+ 的运行环境。环境搭建好后，需要安装依赖库 pymilvus详见官网介绍：cid:link_6conda install numpy pip3 install pymilvus==2.3.2注意：pymilvus 默认conda 是安装不来的，但是pip3 可以直接安装可以用如下命令验证环境是否搭建成功（没报错就说明成功了）python3 -c "from pymilvus import Collection"也可以使用 python 命令行的方式执行连接 Milvusmilvus使用的端口是19530查看容器使用的端口：docker port milvus-standalone查看容器是否在某个端口上进行监听：docker port milvus-standalone 19530/tcp我这里使用的是开源的Virtual box，网络使用的是net方式。因此找到端口转发，配置19530即可这里，子系统的IP，可以通过ip a 查看并替换成你的虚拟机上的IP Milvus在Github上为其提供了python语言的测试demo，地址为：https://github.com/milvus-io/pymilvus/tree/master/examples。用来测试的文件是 hello_milvus.py由于需要vpn才能访问，我贴一下它的代码# hello_milvus.py demonstrates the basic operations of PyMilvus, a Python SDK of Milvus. # 1. connect to Milvus # 2. create collection # 3. insert data # 4. create index # 5. search, query, and hybrid search on entities # 6. delete entities by PK # 7. drop collection import time import numpy as np from pymilvus import ( connections, utility, FieldSchema, CollectionSchema, DataType, Collection, ) fmt = "\n=== {:30} ===\n" search_latency_fmt = "search latency = {:.4f}s" num_entities, dim = 3000, 8 ################################################################################# # 1. connect to Milvus # Add a new connection alias `default` for Milvus server in `localhost:19530` # Actually the "default" alias is a buildin in PyMilvus. # If the address of Milvus is the same as `localhost:19530`, you can omit all # parameters and call the method as: `connections.connect()`. # # Note: the `using` parameter of the following methods is default to "default". print(fmt.format("start connecting to Milvus")) connections.connect("default", host="localhost", port="19530") has = utility.has_collection("hello_milvus") print(f"Does collection hello_milvus exist in Milvus: {has}") ################################################################################# # 2. create collection # We're going to create a collection with 3 fields. # +-+------------+------------+------------------+------------------------------+ # | | field name | field type | other attributes | field description | # +-+------------+------------+------------------+------------------------------+ # |1| "pk" | VarChar | is_primary=True | "primary field" | # | | | | auto_id=False | | # +-+------------+------------+------------------+------------------------------+ # |2| "random" | Double | | "a double field" | # +-+------------+------------+------------------+------------------------------+ # |3|"embeddings"| FloatVector| dim=8 | "float vector with dim 8" | # +-+------------+------------+------------------+------------------------------+ fields = [ FieldSchema(name="pk", dtype=DataType.VARCHAR, is_primary=True, auto_id=False, max_length=100), FieldSchema(name="random", dtype=DataType.DOUBLE), FieldSchema(name="embeddings", dtype=DataType.FLOAT_VECTOR, dim=dim) ] schema = CollectionSchema(fields, "hello_milvus is the simplest demo to introduce the APIs") print(fmt.format("Create collection `hello_milvus`")) hello_milvus = Collection("hello_milvus", schema, consistency_level="Strong") ################################################################################ # 3. insert data # We are going to insert 3000 rows of data into `hello_milvus` # Data to be inserted must be organized in fields. # # The insert() method returns: # - either automatically generated primary keys by Milvus if auto_id=True in the schema; # - or the existing primary key field from the entities if auto_id=False in the schema. print(fmt.format("Start inserting entities")) rng = np.random.default_rng(seed=19530) entities = [ # provide the pk field because `auto_id` is set to False [str(i) for i in range(num_entities)], rng.random(num_entities).tolist(), # field random, only supports list rng.random((num_entities, dim)), # field embeddings, supports numpy.ndarray and list ] insert_result = hello_milvus.insert(entities) hello_milvus.flush() print(f"Number of entities in Milvus: {hello_milvus.num_entities}") # check the num_entities ################################################################################ # 4. create index # We are going to create an IVF_FLAT index for hello_milvus collection. # create_index() can only be applied to `FloatVector` and `BinaryVector` fields. print(fmt.format("Start Creating index IVF_FLAT")) index = { "index_type": "IVF_FLAT", "metric_type": "L2", "params": {"nlist": 128}, } hello_milvus.create_index("embeddings", index) ################################################################################ # 5. search, query, and hybrid search # After data were inserted into Milvus and indexed, you can perform: # - search based on vector similarity # - query based on scalar filtering(boolean, int, etc.) # - hybrid search based on vector similarity and scalar filtering. # # Before conducting a search or a query, you need to load the data in `hello_milvus` into memory. print(fmt.format("Start loading")) hello_milvus.load() # ----------------------------------------------------------------------------- # search based on vector similarity print(fmt.format("Start searching based on vector similarity")) vectors_to_search = entities[-1][-2:] search_params = { "metric_type": "L2", "params": {"nprobe": 10}, } start_time = time.time() result = hello_milvus.search(vectors_to_search, "embeddings", search_params, limit=3, output_fields=["random"]) end_time = time.time() for hits in result: for hit in hits: print(f"hit: {hit}, random field: {hit.entity.get('random')}") print(search_latency_fmt.format(end_time - start_time)) # ----------------------------------------------------------------------------- # query based on scalar filtering(boolean, int, etc.) print(fmt.format("Start querying with `random > 0.5`")) start_time = time.time() result = hello_milvus.query(expr="random > 0.5", output_fields=["random", "embeddings"]) end_time = time.time() print(f"query result:\n-{result[0]}") print(search_latency_fmt.format(end_time - start_time)) # ----------------------------------------------------------------------------- # pagination r1 = hello_milvus.query(expr="random > 0.5", limit=4, output_fields=["random"]) r2 = hello_milvus.query(expr="random > 0.5", offset=1, limit=3, output_fields=["random"]) print(f"query pagination(limit=4):\n\t{r1}") print(f"query pagination(offset=1, limit=3):\n\t{r2}") # ----------------------------------------------------------------------------- # hybrid search print(fmt.format("Start hybrid searching with `random > 0.5`")) start_time = time.time() result = hello_milvus.search(vectors_to_search, "embeddings", search_params, limit=3, expr="random > 0.5", output_fields=["random"]) end_time = time.time() for hits in result: for hit in hits: print(f"hit: {hit}, random field: {hit.entity.get('random')}") print(search_latency_fmt.format(end_time - start_time)) ############################################################################### # 6. delete entities by PK # You can delete entities by their PK values using boolean expressions. ids = insert_result.primary_keys expr = f'pk in ["{ids[0]}" , "{ids[1]}"]' print(fmt.format(f"Start deleting with expr `{expr}`")) result = hello_milvus.query(expr=expr, output_fields=["random", "embeddings"]) print(f"query before delete by expr=`{expr}` -> result: \n-{result[0]}\n-{result[1]}\n") hello_milvus.delete(expr) result = hello_milvus.query(expr=expr, output_fields=["random", "embeddings"]) print(f"query after delete by expr=`{expr}` -> result: {result}\n") ############################################################################### # 7. drop collection # Finally, drop the hello_milvus collection print(fmt.format("Drop collection `hello_milvus`")) utility.drop_collection("hello_milvus")下载好后，使用 docker ps -a 确保虚拟机中的milvus服务器已全部开启执行命令 python hello_milvus.py，或是使用编辑器执行均可（我这里用的是Anaconda提供的Spyder）完整的执行结果如下=== start connecting to Milvus === Does collection hello_milvus exist in Milvus: False === Create collection `hello_milvus` === === Start inserting entities === Number of entities in Milvus: 3000 === Start Creating index IVF_FLAT === === Start loading === === Start searching based on vector similarity === hit: id: 2998, distance: 0.0, entity: {'random': 0.9728033590489911}, random field: 0.9728033590489911 hit: id: 1262, distance: 0.08883658051490784, entity: {'random': 0.2978858685751561}, random field: 0.2978858685751561 hit: id: 1265, distance: 0.09590047597885132, entity: {'random': 0.3042039939240304}, random field: 0.3042039939240304 hit: id: 2999, distance: 0.0, entity: {'random': 0.02316334456872482}, random field: 0.02316334456872482 hit: id: 1580, distance: 0.05628091096878052, entity: {'random': 0.3855988746044062}, random field: 0.3855988746044062 hit: id: 2377, distance: 0.08096685260534286, entity: {'random': 0.8745922204004368}, random field: 0.8745922204004368 search latency = 0.4576s === Start querying with `random > 0.5` === query result: -{'embeddings': [0.20963514, 0.39746657, 0.12019053, 0.6947492, 0.9535575, 0.5454552, 0.82360446, 0.21096309], 'pk': '0', 'random': 0.6378742006852851} search latency = 0.5080s query pagination(limit=4): [{'random': 0.6378742006852851, 'pk': '0'}, {'random': 0.5763523024650556, 'pk': '100'}, {'random': 0.9425935891639464, 'pk': '1000'}, {'random': 0.7893211256191387, 'pk': '1001'}] query pagination(offset=1, limit=3): [{'random': 0.5763523024650556, 'pk': '100'}, {'random': 0.9425935891639464, 'pk': '1000'}, {'random': 0.7893211256191387, 'pk': '1001'}] === Start hybrid searching with `random > 0.5` === hit: id: 2998, distance: 0.0, entity: {'random': 0.9728033590489911}, random field: 0.9728033590489911 hit: id: 747, distance: 0.14606499671936035, entity: {'random': 0.5648774800635661}, random field: 0.5648774800635661 hit: id: 2527, distance: 0.1530652642250061, entity: {'random': 0.8928974315571507}, random field: 0.8928974315571507 hit: id: 2377, distance: 0.08096685260534286, entity: {'random': 0.8745922204004368}, random field: 0.8745922204004368 hit: id: 2034, distance: 0.20354536175727844, entity: {'random': 0.5526117606328499}, random field: 0.5526117606328499 hit: id: 958, distance: 0.21908017992973328, entity: {'random': 0.6647383716417955}, random field: 0.6647383716417955 search latency = 0.1996s === Start deleting with expr `pk in ["0" , "1"]` === query before delete by expr=`pk in ["0" , "1"]` -> result: -{'random': 0.6378742006852851, 'embeddings': [0.20963514, 0.39746657, 0.12019053, 0.6947492, 0.9535575, 0.5454552, 0.82360446, 0.21096309], 'pk': '0'} -{'random': 0.43925103574669633, 'embeddings': [0.52323616, 0.8035404, 0.77824664, 0.80369574, 0.4914803, 0.8265614, 0.6145269, 0.80234545], 'pk': '1'} query after delete by expr=`pk in ["0" , "1"]` -> result: [] === Drop collection `hello_milvus` ===停止 milvussudo docker-compose down删除milvus的数据在停止Milvus后，可以使用如下命令删除 milvus 容器挂载在本机上的数据sudo rm -rf volumes安装 Attu 可视化工具在github上有安装命令，地址为：cid:link_0docker 的运行命令如下docker run -p 8000:3000 -e HOST_URL=http://{ your machine IP }:8000 -e MILVUS_URL={your machine IP}:19530 zilliz/attu:latest注意：这里的本机IP可以直接使用127.0.0.1docker run -p 8000:3000 -e HOST_URL=http://127.0.0.1:8000 -e MILVUS_URL=127.0.0.1:19530 zilliz/attu:latest启动报错了$ node node[9]: ../src/node_platform.cc:61:std::unique_ptr<long unsigned int> node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Start(): Assertion `(0) == (uv_thread_create(t.get(), start_thread, this))' failed. 1: 0xb57f90 node::Abort() [node] 2: 0xb5800e [node] 3: 0xbc915e [node] 4: 0xbc9230 node::NodePlatform::NodePlatform(int, v8::TracingController*, v8::PageAllocator*) [node] 5: 0xb1b3d1 node::InitializeOncePerProcess(int, char**, node::InitializationSettingsFlags, node::ProcessFlags::Flags) [node] 6: 0xb1bc89 node::Start(int, char**) [node] 7: 0x7f2ca389fd90 [/lib/x86_64-linux-gnu/libc.so.6] 8: 0x7f2ca389fe40 __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6] 9: 0xa93f0e _start [node] Aborted (core dumped)使用 docker version 查看docker 版本可以发现 centos7 通过yum安装的docker版本应该是太旧了下面需要重装docker卸载原有dockersudo yum remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine安装yum-utils和源sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo开始安装docker引擎和客户端等sudo yum install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin启动docker并设置为开机自启动sudo systemctl start docker sudo systemctl enable docker查看docker版本(可以看到，现在显示的这个版本号才是正常的)docker version逐个删除原有镜像：docker rm <镜像ID>（镜像ID可以使用 docker ps -a进行查看）接着分别启动 milvus-standalone和attu（这个命令要在官网的基础上加个-d参数，使其在后台启动）docker-compose -f milvus-standalone-docker-compose.yml up -d docker run -d -p 8000:3000 -e HOST_URL=http://127.0.0.1:8000 -e MILVUS_URL=127.0.0.1:19530 zilliz/attu:latest然后在 Virtualbox 的 net网络地址转发这里加一个8000的端口映射接着打开window上的浏览器，输入 cid:link_9点击连接之后报错：Error: 14 UNAVAILABLE: No connection established查看所有容器ID，先关闭掉错误的attu容器，然后再进行删除docker ps -a docker stop <attu容器ID> docker rm <attu容器ID>将Milvus的IP从127.0.0.1改为本机IP（enp0s3）或docker（docker0）的IP，都是可以的。使用 ip a 或 ifconfig 命令，均可以查看到本机所有网卡对应的IP使用修改IP后的命令重启Attu容器docker run -d -p 8000:3000 -e HOST_URL=http://127.0.0.1:8000 -e MILVUS_URL=172.17.0.1:19530 zilliz/attu:latest然后使用外部浏览器输入 cid:link_9，进行连接，并登录。这里连接成功了另外，你也可以将Attu加入到docker-compose.xml文件中，让它们一起启动，命令如下 attu: container_name: attu image: zilliz/attu:v2.2.6 environment: MILVUS_URL: milvus-standalone:19530 ports: - "8000:3000" depends_on: - "standalone"参考：cid:link_2

背景PostgreSQL 9.1之前，主从复制传输以WAL日志文件为单位，主库写完WAL日志后再传输给从库，导致主从延迟较大。基于这种情况，PostgreSQL 9.1引入主从流复制，以WAL日志的record为传输单位，从库及时同步主库数据，并且应用每个WAL record，因此能做到同步复制。另外实现了Hot Standby，从库在应用WAL record的同事能够提供制度服务。架构PG主从流复制的核心有三个进程构成：    walsender：用于主库发送WAL日志记录到从库；    walreceiver：用于从库接收主库的WAL日志记录；    startup：用于从库apply日志。流复制的启动1.启动过程    启动主从服务器；    从库节点启动startup进程；    从库节点启动walreceiver进程；    walreceiver进程向主库节点发送连接请求，如果主库尚未启动，walreceiver会定期重发该请求；    当主节点收到连接请求时，将启动walsender进程，并建立walsender和walreceiver之间的TCP连接；    walreceiver发送从库节点最新的LSN；    如果从库最新的LSN小于主库最新LSN，即落后。walsender会将前一个LSN到后一个LSN之间的wal数据发送到walreceiver；    流复制开始工作。2.walsender状态通过pg_stat_replication试图可以查看所有运行的walsender状态walsender进程可能的状态如下    start-up    catch-up    streaming    backup3。从库节点长期停机启动    PostgreSQL 9.4之前，如果从库节点请求的WAL段在主库节点已经被覆盖，那么备份节点将无法追上主节点。暂时没有解决方案，需要把wal_keep_segments参数调大；    PostgreSQL 9.4之后，使用复制槽（replication）来预防——通过暂停walreceiver进程，将含有未发送wal段的pg_xlog保存在复制槽中。复制槽可以提供wal数据发送的灵活性，主要用于逻辑复制。流复制过程流复制包括两个方面：日志传输和数据同步    流复制基于日志传输，主节点会在写入日志记录时，将WAL数据发送到已连接的从库节点；    同步复制需要数据库同步，主库节点和多个从库节点通信，从而同步整个数据库集群。1.主从之间的通信假设在从库节点处于同步模式，hot_standby参数已禁用、wal_level为‘archive’，即主库配以下参数：synchronous_standby_names = 'standby1'hot_standby = offwal_level = archive假设后台进程在自动提交模式下在主节点发出一条insert语句。后台进程启动事务、发出一条insert语句、然后立即提交事务。分析如下：​    后台进程执行XLogInsert()和XLogFlush()函数，将wal数据写入缓存并flush到wal段文件；    walsender将写入的wal段文件的wal数据发送到walreceiver；    主库节点发送wal数据后，后端进程继续等待来自从库节点的ACK响应。即后台进程执行内部函数SyncRepWaitForLSN()来获取latch，并等待释放；    walreceiver通过write()函数将接收到的wal数据写入从库节点的wal缓存，并且返回ACK响应给walsender；    walreceiver通过fsync()函数将wal数据全部flush到wal段文件，并且再返回一个ACK响应给walsender，通知startup进程wal相关数据已更新；    startup进程应用写入wal段文件的wal数据；    walsender在接受到ACK响应后释放latch，然后后端进程完成commit或abort动作。latch释放的时间取决于synchronous_commit：如果参数是on，则在步骤(5)接收ACK响应后释放latch；如果是remote_wirte，那么在步骤（4）接收ACK就释放latch，2.ACK响应内容ACK响应将从库节点的内部信息发送给主节点，包括以下四个项目：    已写入的最新WAL数据的LSN位置    已刷新的最新WAL数据的LSN位置    startup进程最新应用的wal数据的LSN位置    发送此ACK的时间戳walreceiver不仅在写入和刷新WAL数据的时候返回ACK响应，还定期发送从库节点心跳（心跳发送间隔通过wal_receiver_status_interval设置，默认10秒）。因此，主库节点始终掌握所有已连接的从库节点状态。可通过以下查询看到所连接从库相关的LSN信息SELECT application_name AS host,write_location AS write_LSN,flush_location AS flush_LSN,replay_location AS replay_LSN FROM pg_stat_replication;   host   | write_lsn | flush_lsn | replay_lsn----------+-----------+-----------+------------ standby1 | 0/5000280 | 0/5000280 | 0/5000280 standby2 | 0/5000280 | 0/5000280 | 0/5000280    1    2    3    4    5    63.发生故障时的行为即使同步从库节点故障，不能再返回ACK响应到主库节点，主库节点也会继续等待从库节点的ACK响应。因此，在主库节点运行的事务会无法提交，后续的查询也无法执行，即主库节点的所有操作都停止（流复制不支持由于超时自动降级为异步模式）。两种方法避免该情况的发生：    提供多台从库节点来提高系统的可用性；    通过手动执行以下步骤来同步流复制转换到异步流复制。    # 1.设置synchronous_standby_names为空串    synchronous_standby_names = ''         #2.执行reload命令重载配置文件    pg_ctl -D $PGDATA reload    ​管理多个从库节点1.同步优先级与同步状态主库节点会为所有的从库节点指定sync_priority（同步优先级）和sync_state（同步状态）；同步优先级sync_priority表示从库节点在同步模式下的优先级，是一个固定值，其值越小则优先级越高。0是一个特殊值，表示异步模式。从库节点优先级是一个有序列表，按照synchronous_standby_names中的顺序一次给出。同步状态sync_stat表示从库节点的状态，其值是由各个从库节点的运行状态以及优先级而定，以下是可能的值：    sync：具有最高优先级的同步模式从库节点状态；    potential：同步模式下优先级>=2的从库节点状态。如果sync状态（最高优先级）的从库节点故障，优先级第二稿（优先级=2）的从库节点会代替故障节点变为最高优先级；    aysnc：异步模式从库节点的固定值，除非修改同步模式，否则他们的状态永远不会是sync和potential；可以通过pg_stat_replication视图查看这两个值SELECT application_name AS host,sync_priority,sync_state FROM pg_stat_replication;   host   | sync_priority | sync_state----------+---------------+------------ standby1 |             1 | sync standby2 |             2 | potential2.主库节点管理多个从库节点主库节点仅等待sync状态从库节点的ACK响应，即主库节点只确保sync主功能太从库节点已写入并刷新WAL数据。因此，在流复制中，只有sync状态的从库节点和主库节点是一直同步的；下图展示potential状态下从库ACK响应应该早于sync状态从库的情况：此时主库不会完成当前事务的提交，而是要继续等待sync状态从库ACK响应。当收到sync状态从库ACK响应时，主库后端进程才会释放latch并完成事务提交。    如果主库先接受到sync从库的ACK响应，则会立即完成当前事务的提交，而不会去确认potential状态的从库是否已经写入并刷新WAL数据。3.从库发生故障时的行为potential或async状态从库节点故障主库节点会终止连接到故障备份节点walsender进程，并继续进行职级的事务处理。即主库节点的事务处理不厚道这两类从库节点故障的而影响。sync状态从库节点故障主库终止连接到故障节点的walsender进程，potential状态从库节点顶替故障的从库节点变为sync状态（期间主库不可用），在替换完成后主库胡肌肤事务处理。因此，从库节点的故障检查对提高流复制高可用至关重要。从库节点的故障检测1.从库节点的故障检测    当检测到walsender与walreceiver的连接中断时，主节点立即判定从库节点或walreceiver出现故障；    当底层网络函数由于未能成功读/写walreceiver套接字接口而返回错误时，主库节点会立即判定其失效。2.硬件或者网络故障检测如果walreceiver在wal_sender_timeout（默认60s）乜有返回任何节点，则主库节点会认为从库节点出现故障。根据故障类型，在故障和检测之间可能会有时间差，特别是如果在sync状态从库中发生第二种故障，那么即使有多个potential状态从库节点正常工作，检测到sync状态从库失效，主库仍然会有一段时间不可用。进程通信详细过程1.walsender和walreceiver的流复制过程2.walreceiver和startup进程————————————————版权声明：本文为CSDN博主「LanceJerry」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/LanceJerry/article/details/123641114

0、前言之前也做了一些流复制的实验，今天就想着把了解的PostgreSQL流复制的内容总结下，整理了这篇文章。1、概述1.1、什么是流复制？如果有人问你PostgreSQL的流复制究竟是什么？你大概会说通过wal日志来进行数据同步之类的，的确如此，流复制大概就是这么回事。但是准确的来说：PostgreSQL通过wal日志来传送的方式有两种：基于文件的日志传送和流复制。不同于基于文件的日志传送，流复制的关键在于“流”，所谓流，就是没有界限的一串数据，类似于河里的水流，是连成一片的。因此流复制允许一台后备服务器比使用基于文件的日志传送更能保持为最新的状态。比如我们有一个大文件要从本地主机发送到远程主机，如果是按照“流”接收到的话，我们可以一边接收，一边将文本流存入文件系统。这样，等到“流”接收完了，硬盘写入操作也已经完成。1.2、流复制发展历史流复制之前的手段：像我们上面说的，pg在流复制出现之前，使用的就是基于文件的日志传送：对wal日志进行拷贝，因此从库始终落后主库一个日志文件，并且使用rsync工具同步data目录。而流复制出现是从2010年推出的pg9.0开始的，其历史大致为：    起源：pg9.0开始支持流式物理复制，用户可以通过流式复制，构建只读备库    (主备物理复制，块级别一致)。流式物理复制可以做到极低的延迟(通常在1毫秒以内)。    同步流复制：pg9.1开始支持同步复制，但是当时只支持一个同步流复制备节点(例如配置了3个备，只有一个是同步模式的，其他都是异步模式)。同步流复制的出现，保证了数据的0丢失。    级联流复制：pg9.2支持级联流复制。即备库还可以再连备库。    流式虚拟备库：pg9.2还支持虚拟备库，即就是只有WAL，没有数据文件的备库。    逻辑复制：pg9.4开始可以实现逻辑复制，逻辑复制可以做到对主库的部分复制，例如表级复制，而不是整个集群的块级一致复制。    增加多种同步级别：pg9.6版本开始可以通过synchronous_commit参数，来配置事务的同步级别。1.3、流复制概述流复制其原理为：备库不断的从主库同步相应的数据，并在备库apply每个WAL record，这里的流复制每次传输单位是WAL日志的record。PostgreSQL物理流复制按照同步方式分为两类：    异步流复制    同步流复制物理流复制具有以下特点：1、延迟极低，不怕大事务2、支持断点续传3、支持多副本4、配置简单5、备库与主库物理完全一致，并支持只读2、流复制基础在学习流复制之前，我们先来了解一些相关的基础知识。2.1、wal日志介绍在这篇文章中我曾经详细介绍过PostgreSQL中的wal日志：PostgreSQL WAL日志详解这里再简单介绍下：WAL日志机制保证了事务的持久性和数据完整性，同时又避免了频繁IO对性能的影响。为了保证数据库中数据的持久性，即事务提交后，即使数据库出现故障也能保证数据的可靠性。最简单的方法就是：数据一提交就刷到磁盘上。但是这样对于事务非常频繁的系统，一有事务提交就去刷新脏数据，会对数据库性能产生非常不好的影响。因此使用wal日志来记录数据的更改，这样每当发生事务提交，只需要通过提交wal日志即可，而且wal日志的提交是顺序的，性能也很高。2.2、wal日志解读对数据库操作会以record为单位首先记录到wal日志中，在checkpoint时才对数据进行刷盘(background writer会定时刷脏数据，但最终还是都由checkpoint确认都刷盘成功)。聊了这么久wal日志，我们都还不知道wal日志在哪？长啥样。。。wal日志位置：$PGDATA/pg_wal(pg10之前叫pg_xlog)wal日志文件命名规则：我们看到的wal日志是这样的：000000010000000100000092其中前8位:00000001表示timeline；中间8位：00000001表示logid；最后8位：00000092表示logsegwal日志LSN编号规则:1/920001F8(高32位/低32位)对照关系：1、wal日志的logseg前6位始终是0，后两位是LSN低32位/16MB(2*24)，即LSN的前两位。如上例中logseg最后两位是92，LSN低32前两位也是92。2、LSN在wal日志中的偏移量即LSN低32位中后24位对应的十进制值。例如当前wal日志偏移量为504bill=# select pg_walfile_NAME_OFFSET(pg_current_wal_lsn());     pg_walfile_name_offset     -------------------------------- (000000010000000100000092,504)(1 row)bill=# select x'1F8'::int; int4------  504(1 row)    1    2    3    4    5    6    7    8    9    10    112.3、wal日志内部详解接下来我们来看看wal日志里面究竟记录的是些什么内容。如果你直接查看wal日志，可能会收到下面这样的提示：因为wal日志是二进制格式的文件，不过我们可以使用pg_waldump这个工具来将其转换成可读的文件。例1：首先来看看insert数据时wal日志里面记录了些什么。bill=# begin;BEGINbill=# select pg_current_wal_lsn(); pg_current_wal_lsn-------------------- 1/92021290(1 row)bill=# insert into tbl values(1,'bill');INSERT 0 1bill=# select pg_current_wal_lsn(); pg_current_wal_lsn-------------------- 1/92021308(1 row)bill=# end;COMMIT    1    2    3    4    5    6    7    8    9    10    11    12    13    14    15    16    17    18接下来我们看看wal日志里面内容：可以看到wal日志里面记录了上面的insert操作。例2:我们再看看update时wal日志里面记录的内容：bill=# select pg_current_wal_lsn(); pg_current_wal_lsn-------------------- 1/92021450(1 row)bill=# update tbl set info = 'foucus' where id = 1;UPDATE 1    1    2    3    4    5    6    7    8在这里插入图片描述这里简单介绍下这条记录的内容：rmgr: Heap        len (rec/tot):     65/   177, tx:        717, lsn: 1/92021450, prev 1/92021418, desc: HOT_UPDATE off 1 xmax 717 flags 0x20 ; new off 2 xmax 0, blkref #0: rel 1663/16395/17623 blk 0 FPW    1    rmgr: Heap ：PostgreSQL内部将WAL日志归类到20多种不同的资源管理器。这条WAL记录所属资源管理器为 Heap,即堆表。除了Heap还有Btree,Transaction等。    len (rec/tot): 65/ 177：wal记录的长度。    tx: 717： 事务号。    lsn: 1/92021450：本条wal记录的lsn。    prev 1/92021418：上条wal记录的lsn。    desc: HOT_UPDATE off 1 xmax 717 flags 0x20 ; new off 2 xmax 0： 这是一条热更新类型的记录，旧数据    offset为1，xmax为717。旧tuple在page中的位置为1(即ctid的后半部分)，新tuple在page中的位置为2。    blkref #0: rel 1663/16395/17623 blk 0 ：引用的第一个page(新tuple所在page)所属的堆表文件为1663/13543/16469,块号为0(即ctid的前半部分)。3、流复制原理3.1、日志提交过程从上图我们可以看到流复制中日志提交的大致流程为：1、事务commit后，日志在主库写入wal日志，还需要根据配置的日志同步级别，等待从库反馈的接收结果。2、主库通过日志传输进程将日志块传给从库，从库接收进程收到日志开始回放，最终保证主从数据一致性。3.2、流复制同步级别PostgreSQL通过配置synchronous_commit (enum)参数来指定事务的同步级别。我们可以根据实际的业务需求，对不同的事务，设置不同的同步级别。synchronous_commit = off                # synchronization level;                                          # off, local, remote_write, or on      1    2    remote_apply：事务commit或rollback时，等待其redo在primary、以及同步standby(s)已持久化，并且其redo在同步    standby(s)已apply。    on：事务commit或rollback时，等待其redo在primary、以及同步standby(s)已持久化。    remote_write：事务commit或rollback时，等待其redo在primary已持久化; 其redo在同步standby(s)已调用write接口(写到 OS, 但是还没有调用持久化接口如fsync)。    local：事务commit或rollback时，等待其redo在primary已持久化;    off：事务commit或rollback时，等待其redo在primary已写入wal buffer，不需要等待其持久化;不同的事务同步级别对应的数据安全级别越高，对应的对性能影响也就越大。上述从上至下安全级别越来越低。详细的同步流复制原理见：CommitTransaction @ src/backend/access/transam/xact.c   RecordTransactionCommit @ src/backend/access/transam/xact.c      1    24、流复制配置过程PostgreSQL物理流复制大致过程为：1、PG软件安装2、postgresql.conf参数配置3、pg_hba.conf配置4、pg_basebackup方式部署备库5、配置简单6、备库与主库物理完全一致，并支持只读具体的配置步骤可以参考我之前写的这篇文章：PostgreSQL流复制4.1、异步流复制参数配置postgresql.conf :wal_level = replica # minimal, replica, or logicalmax_wal_senders = 10 wal_keep_segments = 1024 hot_standby = on    1    2pg_hba.conf :host replication postgres# max number of walsender processes# in logfile segments, 16MB each; 0 disables192.168.7.180/32 md5    1    2    3    4standby recovery.conf :recovery_target_timeline = 'latest'standby_mode = onprimary_conninfo = 'host=192.168.7.180 port=1921 user=bill password=xxx    1    2    34.2、同步流复制参数配置postgresql.conf :wal_level = replica # minimal, replica, or logicalmax_wal_senders = 10 # max number of walsender processes wal_keep_segments = 1024 # in logfile segments, 16MB each; 0 disables hot_standby = onsynchronous_commit = remote_write、on、remote_apply synchronous_standby_names = 'standby2'    1    2    3pg_hba.conf :host replication postgres 192.168.7.180/32 md5    1standby recovery.conf :recovery_target_timeline = 'latest'standby_mode = onprimary_conninfo = 'host=192.168.7.180 port=1921 user=bill password=xxx application_name=standby2'    1    2    3另外我们可以通过设置synchronous_standby_names参数来指定一个支持同步复制的后备服务器的列表，其支持格式大致为：1、synchronous_standby_names =standby_name [, ...]2、synchronous_standby_names =[FIRST] num_sync ( standby_name [, ...])3、synchronous_standby_names =ANY num_sync ( standby_name [, ...] )    1    2    34.3、主备切换流程1、关闭主库，建议使用-m fast模式关闭。2、在备库上执行pg_ctl promote命令激活备库，如果recovery.conf变成recovery.done表示 备库已切换成为主库。3、这时需要将老的主库切换成备库，在老的主库的$PGDATA目录下创建recovery.conf文 件(如果此目录下不存在recovery.conf文件，可以根据$PGHOME/recovery.conf. sample模板文件复制一个，如果此目录下存在recovery.done文件，需将recovery.done文件重命名为 recovery.conf)，配置和老的从库一样，只是primary_conninfo参数中的IP换成对端IP。4、启动老的主库，这时观察主、备进程是否正常，如果正常表示主备切换成功。    1    2    3    4    5    6    7    84.4、复制槽slot因为pg在归档模式下，对于已经完成归档的wal日志会自动清理，所以提供了复制槽来避免主库在所有的备库收到 WAL 日志之前不会移除它们，并且主库也不会移除可能导致恢复冲突的行，即使备库断开也是如此。例子：创建一个复制槽：bill=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');slot_name | lsn-------------+----- node_a_slot |    1    2    3    4bill=# SELECT slot_name, slot_type, active FROM pg_replication_slots; slot_name | slot_type | active-------------+-----------+--------node_a_slot | physical | f(1 row)    1    2    3    4要配置后备机使用这个槽，在备库的recovery.conf中应该配置 primary_slot_name，例如：standby_mode = 'on'primary_conninfo = 'host=192.168.7.180 port=1921 user=bill password='xxx' primary_slot_name = 'node_a_slot'    1    25、pg12流复制新特性PostgreSQL12中流复制有了一些改变：把recovery.conf的内容全部移入postgresql.conf，配置恢复、archive based standby、stream based standby，都在postgresql.conf中。postgresql.conf以及对应的两个signal文件来表示进入recovery 模式或standby模式。在这里插入图片描述例子：1、典型恢复模式配置postgresql.conf：# stream恢复模式配置  #primary_conninfo = ''  或  # archvie恢复模式配置  #restore_command = ''  hot_standby = on   # 配置是否跨时间线  #recovery_target_timeline = 'latest'  # 配置恢复目标，例如  # 立即（达到一致性即停止恢复）、时间、XID、restore point name, LSN.  #recovery_target = ''           # 'immediate' to end recovery as soon as a                                  # consistent state is reached                                  # (change requires restart)  #recovery_target_name = ''      # the named restore point to which recovery will proceed                                  # (change requires restart)  #recovery_target_time = ''      # the time stamp up to which recovery will proceed                                  # (change requires restart)  #recovery_target_xid = ''       # the transaction ID up to which recovery will proceed                                  # (change requires restart)  #recovery_target_lsn = ''       # the WAL LSN up to which recovery will proceed                                  # (change requires restart)  #recovery_target_inclusive = on # Specifies whether to stop:                                  # just after the specified recovery target (on)                                  # just before the recovery target (off)                                  # (change requires restart)  # 恢复目标到达后，暂停恢复、激活、停库  #recovery_target_action = 'pause'  # 'pause', 'promote', 'shutdown'                                     # (change requires restart)      1    2    3    4    5    6    7    8    9    10    11    12    13    14    15    16    17    18    19    20    21    22    23    24    25    26    27    28    29    30    31    32在 $PGDATA目录中，touch recovery.signal2、典型standby模式配置postgresql.conf：# stream恢复模式配置  #primary_conninfo = ''  或   # archvie恢复模式配置  #restore_command = ''  hot_standby = on   # 配置是否跨时间线  #recovery_target_timeline = 'latest'      1    2    3    4    5    6    7    8    9    10在 $PGDATA目录中，touch standby.signal3、如果standby.signal , recovery.signal两个文件都配置了，则优先为standby modePostgreSQL12中流复制的搭建详见我之前的这篇文章：PostgreSQL12同步流复制搭建及主备切换参考链接：https://www.postgresql.org/docs/12/release-12.htmlhttps://www.postgresql.org/docs/12/high-availability.html————————————————版权声明：本文为CSDN博主「foucus、」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/weixin_39540651/article/details/106122610

判断对象是否存在于某个子查询的3种写法在数据库中中，我们可以使用in、exists语句来判断对象是否存在某个子查询中。在PostgreSQL里，除了支持上述两种语法外，还支持= any的语法。例如下面这3个SQL返回的结果都是一样的select * from tbl where id in (select id from t); select * from tbl where exists (select 1 from t where t.id=tbl.id); select * from tbl where id = any (array( select id from t )); 性能分析in 操作： in 操作会在查询时遍历指定的范围，检查目标值是否在给定的范围内。如果范围内存在匹配的值，则结果为真。in 操作在以下情况下性能较好：范围较小：当给定的范围较小时，in 操作的性能较好，因为数据库可以快速地查找匹配的值。索引可用：如果查询涉及的自建索引包含目标范围，则 in 操作的性能会显著提高。exists 操作： exists 操作用于检查表中是否存在满足条件的记录。它会在查询时遍历表中的所有记录，判断给定条件是否满足。exists 操作在以下情况下性能较好：条件较简单：当查询条件较简单，如仅涉及单一列时，exists 操作的性能较好。数据量较小：数据量较小的情况下，exists 操作的性能优于 in 操作，因为 exists 操作不需要遍历范围，只需判断条件是否满足。= any 操作： = any 操作用于检查目标值是否存在于给定的值列表中。它会在查询时使用 UNION ALL 操作将给定的值列表与表中的数据进行比较。= any 操作在以下情况下性能较好：值列表较小：当给定的值列表较小时，= any 操作的性能较好，因为数据库可以快速地查找匹配的值。索引可用：如果查询涉及的自建索引包含目标值，则 = any 操作的性能会显著提高。 总结： 在实际应用中，in、exists 和 = any 的性能取决于数据量、范围和查询条件。在评估性能时，请根据具体场景和实际需求选择合适的操作。如果数据量较小且条件简单，可以考虑使用 exists 操作；如果需要使用索引，则 in 和 = any 操作可能具有更好的性能。在实际应用中，建议根据具体需求进行性能测试和优化。总结不同的写法，性能还是有一定的差距。可能对in、exists这两种写法比较熟悉的人都知道这么一个结论：IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况。具体的说：= any这种写法，不会走subplan，因此不涉及hash table的问题。和work_mem设置大小无关。因此在pg中十分推荐使用这种写法。exists，由于优化器会默认它只需要搜索到1条命中目标就不搜了，所以优化器评估是否使用hash table时，需要的内存相对较少，即使较小的work_mem也可能使用hashtable。in ，当出现在subquery中时，优化器评估这个subquery是否要构建哈希TABLE，直接和subquery的大小相关，所以需要较大的work_mem才会选择使用hashtable。

典型分布式数据库系统架构数据库系统架构典型的架构有Shared Everything、Shared Memory、Shared Disk和Shared Nothing。这里Share的资源主要是指内存，磁盘。单机数据库系统称为shared everything，因为是单机节点，有自己独立的内存空间和独立的磁盘Shared Memory 现实中并不常见，多个cpu通过网络来共享一个内存地址空间，并且共享同一个disk。Shared Disk 多个数据库实例，每个实例有自己的内存，但是通过网络共享同一个disk。Shared Disk架构在云原生比较常见，这样的好处就是利于存算分离，计算层和存储层能够解耦，因此计算层和存储层在扩缩容的时候彼此不影响。缺点是因为共享disk，因此对于高并发的写请求势必性能会比较差，因此这种架构比较适合OLAP这种读多写少的数仓。Shared Nothing 各个数据库实例，都有自己的内存和disk，这些实例之间只能通过网络通信来感知各个实例的状态变化。通常表会水平划分到各个节点，每个节点只负责其本地磁盘上的数据行。 这种设计非常适合星型模式查询，因为连接维度比较小的维度表和宽的事实表所需的带宽非常少。Share Nothing架构的优点在于性能和效率比较高，缺点在于灵活性较差，因为扩缩容的时候，需要在节点之间移动数据。而且对于事物的支持性较差，因为各个节点之间必须通过网络进行协调。什么是存算分离存算分离是一种数据处理技术，它将数据存储和数据处理（计算）分开，使得存储和计算可以独立地进行优化和扩展。在这种架构下，存储系统负责存储和管理数据，而计算系统负责对数据进行处理和分析。这种技术旨在提高数据处理的效率、降低成本并满足大规模数据存储和分析的需求。为什么需要存算分离异构的工作负载: 得益于现在云原生的环境，用户可以自由配置每台云服务器的cpu型号，内存，磁盘，带宽。但是存在的问题是适合高 I/O 带宽、轻计算的系统配置不适合复杂查询,而适合复杂查询的系统配置却不能满足高吞吐的要求。简单的理解为需要在计算和IO之间做平衡。扩缩容: 由于计算和存储的耦合，当扩缩容的时候势必需要在节点之间移动数据，而节点同时需要对外提供计算服务，因此此时的性能可能会收到很大影响。如果存储分离，那么计算层和存储层可以独立增加减少节点而互不干扰。存算分离的优点存算分离的主要优点如下：高效性：存储和计算可以独立进行优化，使得存储系统可以专注于提高数据的存储和访问效率，计算系统可以专注于优化数据处理算法和提高计算性能。可扩展性：存算分离架构允许存储和计算资源独立扩展，方便应对不断增长的数据存储和处理需求。成本降低：通过将存储和计算分开，可以更加灵活地选择适合各自任务的硬件和软件，从而降低整体成本。灵活性：存算分离使得数据处理任务可以根据实际需求进行调整，如快速切换计算引擎、修改查询算法等。容错性：存算分离架构可以提高系统的容错性，当某个部件出现问题时，其他部分可以继续正常工作。易于维护：存算分离使得系统组件的维护和升级更加容易进行，无需对整个系统进行改造。 在实际应用中，存算分离技术已在大数据、云计算、人工智能等领域得到广泛应用。例如，海量数据公司自主研发的 Vastbase 海量数据库，就致力于提高数据库的存算分离能力，并向 openGauss 社区持续贡献代码。

向量数据库定义向量数据库（Vector Database）是一种专门用来处理向量嵌入（Vector Embedding）的数据库。它通过比较向量值并找到彼此相似的值来索引和检索数据，适用于处理复杂数据类型，如文档、图像、视频和网页等非结构化数据。向量数据库与传统数据库的主要区别在于数据存储方式、数据类型和应用场景。向量数据库与传统数据库的主要区别如下：数据存储方式：传统数据库通常采用表格形式存储结构化数据，如客户信息、订单记录等。向量数据库则将数据存储为高维空间中的点，通过向量表示数据，便于计算和比较相似度。数据类型：传统数据库主要处理结构化数据，如关系型数据。向量数据库可以处理非结构化数据，如文本、图像、音频等，并将这些数据转化为向量形式进行存储和检索。应用场景：传统数据库适用于处理关系型数据和结构化数据，如查询、统计和分析等任务。向量数据库适用于人工智能和机器学习领域，如相似度搜索、推荐系统、图像识别等任务。 向量数据库在处理非结构化数据和复杂场景方面具有优势，能够更快地找到相似的数据点，从而在搜索引擎、内容推荐、图像识别等领域发挥作用。随着大数据和人工智能技术的发展，向量数据库在未来有望得到更广泛的应用。常见的向量数据库向量数据库近年来逐渐受到关注，一些知名的向量数据库包括：Pinecone：这是一家成立于 2021 年的初创公司，专注于向量数据库领域。Pinecone 可以为各种应用提供高性能的向量搜索，包括计算机视觉、自然语言处理、音频识别等。该公司已成为 OpenAI 的合作伙伴，并获得了 7.5 亿美元的估值。Zilliz：作为一家中国初创公司，Zilliz 致力于提供高性能的向量数据库解决方案。其产品 Metis 向量数据库适用于各种场景，如广告推荐、内容审核、图像识别等。Zilliz 已完成数亿元人民币的融资。Chroma：Chroma 是一家成立于 2021 年的美国初创公司，专注于构建向量数据库。其产品可以处理大规模的图像、视频和文本数据，并应用于相似度搜索、推荐系统和内容审核等领域。Milvus：Milvus 是一款开源的向量数据库，由北京智臻科技有限公司开发。它可以处理多种非结构化数据类型，如文本、图像和音频等，并支持高效的向量搜索。Milvus 已在多个行业领域得到广泛应用，如智能客服、短视频推荐等。Faiss：Faiss（Facebook AI Similarity Search）是 Facebook 人工智能研究院开发的一款向量数据库。它旨在为大规模图像、文本和视频数据提供高效的相似度搜索功能。Faiss 已经开源，可供研究人员和开发者免费使用。 这些向量数据库在处理复杂数据类型和相似度搜索方面具有优势，随着人工智能技术的发展，它们在各个领域的应用将进一步拓宽。

Windows操作系统自带ODBC数据源管理器，无需用户手动安装管理器便可直接进行配置。操作步骤步骤一 下载客户端GaussDB驱动程序并进行安装：下载地址：cid:link_0在本地（例如D:/download）下载ZIP文件后进行解压缩，解压缩后文件如下。由于本实验openGauss安装在ECS（openEuler ARM）上，所以进入Euler2.8_arm_64文件夹，显示如下：解压缩GaussDB-Kernel-V500R001C10-Windows-Odbc.tar.gz文件，显示如下：点击psqlodbc_x86.msi进行安装：默认设置，直到安装完毕。步骤二 打开驱动管理器。在配置数据源时，请使用对应的驱动管理器（假设操作系统安装盘符为C盘，如果是其他盘符，请对路径做相应修改）：64位操作系统上进行64位程序开发，安装64位驱动程序后，使用64位的驱动管理器：C:\Windows\System32\odbcad32.exe 或者直接使用“控制面板 > 管理工具 > ODBC 数据源(64 位)。步骤三 配置数据源。在打开的驱动管理器上，选择“用户DSN > 添加 > PostgreSQL Unicode(x64)”，然后进行配置：Data Source:openGauss （数据源名称，可以自定义）。Database:db_tpcc (需要连接的Datebase名称)。Server：openGauss数据库服务器的公网IP，请根据实际情况填写。Pot:26000 (端口号)。User Name:joe （连接数据库的用户名，不能使用omm用户，需要在数据库中创建）Password：dbuser用户的密码，请根据实际情况填写。步骤四 验证并保存设置。点击Test，显示 Connection successful 表示设置成功：点击保存：配置成功！

open gauss数据库和华为云mysql数据库区别

数据库论坛10月份热门问题合集云数据库有哪些优点特点？cid:link_0相比自建数据库，云数据库在机房风火水电网络等基础设施方面、服务器部署及维护、数据库软件安装、数据库软件版本升级和补丁等云数据库相比自建数据库在机房、电力、空调、网络等基础设施方面节省了很多的人力、硬件、维护服务成本，尤其对于中小型企业，没有足够的财力和技术基础建设专业的机房网络等环境，则很容易导致各种各样让人抓狂的问题，比如机房所在的大楼动辄断电停电、空调停摆、UPS故障，总是让人心里慌慌，睡觉不踏实，更有时候会出现老鼠窜进去咬断网线之类的让人匪夷所思的事情，导致整个IT环境的不稳定。往往在这些不太起眼细节上的一个疏忽，会消耗掉管理维护人员的很多时间精力，甚至导致业务中断等故障。高斯数据库相比普通的数据库有什么优点？cid:link_1高性能：高斯数据库采用了自主设计的高性能存储引擎，具备快速的数据读写能力，能够处理大规模数据并发访问的场景。高可靠性：高斯数据库支持主备容灾机制，数据备份与恢复以及故障切换等功能，能够提供可靠的数据保护与高可用性。数据安全：高斯数据库采用了多层次的数据安全措施，包括权限管理、数据加密、审计日志等功能，保护数据的安全性和完整性。可扩展性：高斯数据库支持分布式架构，可以通过增加节点实现水平扩展，适应数据量和用户数的快速增长。数据库连接方面出现问题，目前还不知道如何解决，与delphi链接总是超时cid:link_2代码哪里写错了。我用python和java试过，链接完全没有问题交换数据空间EDS是如何实现可信、可控功能的？cid:link_3交换数据空间（Encrypted Data Space，EDS）是一种用于保护数据隐私的技术，它通过加密和分割数据，实现了可信和可控的功能。下面是关于EDS如何实现这些功能的一般原理：加密保护：EDS使用加密算法对数据进行加密，确保数据在传输和存储过程中的安全性。加密可以防止未经授权的访问者获取敏感信息，即使数据被盗或泄露，也无法直接访问其内容。数据分割：EDS将数据分割成多个部分，并将这些部分分散存储在不同的位置。这种分割和分散存储的方式可以减少数据泄露的风险，即使某个部分的数据被获取，也无法还原出完整的数据。访问控制：EDS采用访问控制机制来管理数据的访问权限。只有经过授权的用户或实体才能够解密和访问数据。这种控制机制可以确保只有合法的用户可以访问数据，提高了数据的可信度。审计和监控：EDS提供审计和监控功能，可以记录数据的访问记录和操作日志。这样可以对数据的使用情况进行监控和审计，发现异常行为或违规操作，并及时采取相应的措施。【鲲鹏服务器】【编译安装mysql】【openEuler】【openssl】编译安装mysql报错cid:link_4指定 OpenSSL 路径：如果已经安装了 OpenSSL，但编译过程仍然找不到相关库或头文件，可以通过指定 OpenSSL 的路径来解决。在运行 configure 脚本时，使用 --with-openssl= 参数指定 OpenSSL 路径。例如：./configure --with-openssl=/usr/local/openssl其中 是 OpenSSL 的安装路径。国产神通数据库ENCRYPT_ORA加密函数如何用Java代码实现cid:link_5Java Cryptography Architecture (JCA) 是一组 API，用于实现现代密码学的概念，例如数字签名、消息摘要、证书、加密、密钥生成和管理、安全随机数生成等。使用 JCA 开发人员可以通过以下方式构建他们的应用程序将安全性融入其中。要在您的应用程序中集成安全性，而不是依赖于复杂的安全算法，您可以轻松调用 JCA 中提供的相应 API 来获取所需的服务。创建分区表时，分区键需要是generated always的生成列，执行报错，请问oracle可以，到gaussDB的话，该如何处理？cid:link_6在GaussDB for openGauss中，分区表的分区键可以是generated always的生成列。然而，对于某些特定情况，由于openGauss版本的差异，可能会导致从Oracle迁移到openGauss时遇到一些兼容性问题。如果您在创建分区表时遇到了报错，请确保按照openGauss的语法和规范进行操作。以下是一些处理方法和注意事项：确认openGauss版本：不同版本的openGauss可能有略微不同的语法和支持特性。请确保您正在使用最新版本，并参考相应版本的文档。检查数据类型和语法差异：数据库系统之间存在数据类型和语法差异的情况，例如数据类型名称、函数用法等。在迁移过程中，请检查并调整相关代码以符合openGauss的语法规范。检查限制和约束：openGauss中有一些与分区表相关的限制和约束，例如每个分区表的最大分区数、生成列的限制等。请确保您的表定义符合这些限制。考虑手动处理：如果无法直接将Oracle的创建表语句转换为openGauss的语法，请考虑手动重建表结构并添加分区键。这样可以更好地适应openGauss的语法和规范要求。Gauss DB 查询数据库全量表的行信息问题cid:link_7use information_schema; select sum(table_rows) from tables where TABLE_SCHEMA = "test" order by table_rows asc;鲲鹏架构默认的char是有符号还是无符号呢？鲲鹏的问题有专门的渠道进行支持，欢迎到昇腾新论坛发帖进行求助~鲲鹏新论坛地址：cid:link_11解锁新论坛：在新论坛中发帖需要大家先注册账号，建议大家新账号的昵称与老账号一致哦！欢迎大家多多提问和分享技术干货，感谢大家支持和谅解。鲲鹏论坛迁移公告：cid:link_8大二电子信息工程专业在鲲鹏华为云数据库上有啥推荐的学习路径吗cid:link_9数据库学习路线，cid:link_10

问题背景测试环境后台开启log_min_duration_statement为3s抓取慢sql时(版本低没开topsql),突然发现后台日志有条sql语句执行了65s,业务sql语句一般执行时间很短,这个不正常,得拿出来看下了. 计划见下图-----(**表名,字段和值已自定义化**)排查思路从计划可以看出为明显的nested loop导致的慢 1.计划选择nested loop的原因为where后面的条件为not in 2.此计划慢的原因为not in里面的语句过滤后的数据量太大，且无法走索引（year条件过滤性太差吧,我怀疑表里面一半值都是这个）。解决方案：从上面分析可知慢的原因，就好下手去优化了。 首先去掉nested loop，改为hash join方式 以下为改下后的语句和计划从计划可以看到改写后的语句走的是hash join的方式，且总体执行代价从38万降到8万，执行时间也从65s下降到1s。问题思考：1.为啥数据库会选择nested loop计划 对于非等值条件数据库无法走hash join 2.是不是hash join一定比nest loop快? 对于被驱动表，如果存在索引的场景下，且整体过滤后的结果很少，走nested loop往往会优于hash join。 本问题语句被驱动表查询结果集很大，且无法走索引，因此nested loop计划就会很慢。

大二电子信息工程专业在鲲鹏华为云数据库上有啥推荐的学习路径吗

高斯数据库相比普通的数据库有什么优点？

mybatis缓存之一级缓存一级缓存的产生一级缓存的产生，并不是看mappper的xml文件的select方法，看下面的例子mapper.xml <select id="getById" resultType="entity.TempEntity"> select * from temp where id = #{id} </select>test @Test public void testSelectAsUpdate() throws IOException { InputStream inputStream = Resources.getResourceAsStream("mybatis.xml"); SqlSessionFactory build = new SqlSessionFactoryBuilder().build(inputStream); SqlSession sqlSession = build.openSession(); sqlSession.update("dao.Temp03Dao.getById", 1); sqlSession.update("dao.Temp03Dao.getById", 1); }执行结果2020-06-26 17:33:27,899 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:33:27,922 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:33:27,923 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:33:27,923 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer)我们可以看到执行了2次查询。说明并没有产生缓存。说明和sqlsession调用的方法是有关系的只有调用上图中的方法才会产生一级缓存一级缓存的销毁1.关闭session这个是根据debug看到的一级缓存的最终结构。下面是整个依赖的类图test @Test public void test() throws IOException, NoSuchFieldException, IllegalAccessException { InputStream inputStream = Resources.getResourceAsStream("mybatis.xml"); SqlSessionFactory build = new SqlSessionFactoryBuilder().build(inputStream); SqlSession sqlSession = build.openSession(); TempEntity tempEntity1 = sqlSession.selectOne("dao.Temp03Dao.getById", 1); logger.info(tempEntity1); Field executorField = sqlSession.getClass().getDeclaredField("executor"); executorField.setAccessible(true); CachingExecutor cachingExecutor = (CachingExecutor) executorField.get(sqlSession); Field declaredField = cachingExecutor.getClass().getDeclaredField("delegate"); declaredField.setAccessible(true); SimpleExecutor simpleExecutor = (SimpleExecutor) declaredField.get(cachingExecutor); Field localCacheField = simpleExecutor.getClass().getSuperclass().getDeclaredField("localCache"); localCacheField.setAccessible(true); PerpetualCache perpetualCache = (PerpetualCache) localCacheField.get(simpleExecutor); Field cacheField = perpetualCache.getClass().getDeclaredField("cache"); cacheField.setAccessible(true); Map<Object,Object> map= (Map<Object, Object>) cacheField.get(perpetualCache); logger.info("缓存关闭前"); for (Map.Entry<Object,Object> objectObjectEntry:map.entrySet()){ logger.info(objectObjectEntry.getKey() + "===" + objectObjectEntry.getValue()); } sqlSession.close(); logger.info("缓存关闭后"); for (Map.Entry<Object,Object> objectObjectEntry:map.entrySet()){ logger.info(objectObjectEntry.getKey() + "=" + objectObjectEntry.getValue()); } }运行结果2020-06-26 17:38:52,777 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:38:52,801 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:38:52,824 DEBUG [dao.Temp03Dao.getById] - <== Total: 1 2020-06-26 17:38:52,824 INFO [TempTest] - TempEntity{id=1, value1='11111', value2='aaaaa'} 2020-06-26 17:38:52,825 INFO [TempTest] - 缓存关闭前 2020-06-26 17:38:52,826 INFO [TempTest] - -1654591322:461730790:dao.Temp03Dao.getById:0:2147483647:select * from temp where id = ?:1:dev===[TempEntity{id=1, value1='11111', value2='aaaaa'}] 2020-06-26 17:38:52,827 INFO [TempTest] - 缓存关闭后可以看到session关闭后，缓存就不存在了2.Commit提交test @Test public void testCommit() throws IOException { InputStream inputStream = Resources.getResourceAsStream("mybatis.xml"); SqlSessionFactory build = new SqlSessionFactoryBuilder().build(inputStream); SqlSession sqlSession = build.openSession(); TempEntity tempEntity1 = sqlSession.selectOne("dao.Temp03Dao.getById", 1); logger.info(tempEntity1); sqlSession.commit(); TempEntity tempEntity2 = sqlSession.selectOne("dao.Temp03Dao.getById", 1); logger.info(tempEntity2); logger.info(tempEntity1 == tempEntity2); }运行结果2020-06-26 17:40:40,821 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:40:40,846 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:40:40,862 DEBUG [dao.Temp03Dao.getById] - <== Total: 1 2020-06-26 17:40:40,862 INFO [TempTest] - TempEntity{id=1, value1='11111', value2='aaaaa'} 2020-06-26 17:40:40,863 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:40:40,863 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:40:40,864 DEBUG [dao.Temp03Dao.getById] - <== Total: 1 2020-06-26 17:40:40,864 INFO [TempTest] - TempEntity{id=1, value1='11111', value2='aaaaa'} 2020-06-26 17:40:40,864 INFO [TempTest] - false说明sqlSession.commit时会清空缓存3.Rollbacktest @Test public void testRollback() throws IOException { InputStream inputStream = Resources.getResourceAsStream("mybatis.xml"); SqlSessionFactory build = new SqlSessionFactoryBuilder().build(inputStream); SqlSession sqlSession = build.openSession(); TempEntity tempEntity1 = sqlSession.selectOne("dao.Temp03Dao.getById", 1); logger.info(tempEntity1); sqlSession.rollback(); TempEntity tempEntity2 = sqlSession.selectOne("dao.Temp03Dao.getById", 1); logger.info(tempEntity2); logger.info(tempEntity1 == tempEntity2); }执行结果2020-06-26 17:42:23,793 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:42:23,833 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:42:23,843 DEBUG [dao.Temp03Dao.getById] - <== Total: 1 2020-06-26 17:42:23,843 INFO [TempTest] - TempEntity{id=1, value1='11111', value2='aaaaa'} 2020-06-26 17:42:23,844 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:42:23,844 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:42:23,845 DEBUG [dao.Temp03Dao.getById] - <== Total: 1 2020-06-26 17:42:23,845 INFO [TempTest] - TempEntity{id=1, value1='11111', value2='aaaaa'} 2020-06-26 17:42:23,845 INFO [TempTest] - falsesqlSession.rollback()也会清空缓存4.update更新这里是在第一次查询后，紧接着进行update操作。这里与表无关。就是操作其它表，也会清空缓存。test @Test public void testForUpdate() throws IOException { InputStream inputStream = Resources.getResourceAsStream("mybatis.xml"); SqlSessionFactory build = new SqlSessionFactoryBuilder().build(inputStream); SqlSession sqlSession = build.openSession(); TempEntity tempEntity1 = sqlSession.selectOne("dao.Temp03Dao.getById", 1); logger.info(tempEntity1); sqlSession.update("dao.Temp03Dao.updateById", 1); TempEntity tempEntity2 = sqlSession.selectOne("dao.Temp03Dao.getById", 1); logger.info(tempEntity2); logger.info(tempEntity1 == tempEntity2); }运行结果2020-06-26 17:45:43,997 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:45:44,034 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:45:44,048 DEBUG [dao.Temp03Dao.getById] - <== Total: 1 2020-06-26 17:45:44,049 INFO [TempTest] - TempEntity{id=1, value1='11111', value2='aaaaa'} 2020-06-26 17:45:44,049 DEBUG [dao.Temp03Dao.updateById] - ==> Preparing: update temp set value1 = 'ffffff' where id = ? 2020-06-26 17:45:44,049 DEBUG [dao.Temp03Dao.updateById] - ==> Parameters: 1(Integer) 2020-06-26 17:45:44,050 DEBUG [dao.Temp03Dao.updateById] - <== Updates: 1 2020-06-26 17:45:44,051 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:45:44,051 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:45:44,052 DEBUG [dao.Temp03Dao.getById] - <== Total: 1 2020-06-26 17:45:44,053 INFO [TempTest] - TempEntity{id=1, value1='ffffff', value2='aaaaa'} 2020-06-26 17:45:44,053 INFO [TempTest] - false这里还是在一个session会话中。记得之前有人给我说只要在一个session会话中，执行update不会清空缓存。这里的代码就证明了5.clearCache 主动清除test @Test public void testClearCatch() throws IOException { InputStream inputStream = Resources.getResourceAsStream("mybatis.xml"); SqlSessionFactory build = new SqlSessionFactoryBuilder().build(inputStream); SqlSession sqlSession = build.openSession(); TempEntity tempEntity1 = sqlSession.selectOne("dao.Temp03Dao.getById", 1); logger.info(tempEntity1); sqlSession.clearCache(); TempEntity tempEntity2 = sqlSession.selectOne("dao.Temp03Dao.getById", 1); logger.info(tempEntity2); logger.info(tempEntity1 == tempEntity2); }运行结果2020-06-26 17:48:42,085 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:48:42,110 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:48:42,124 DEBUG [dao.Temp03Dao.getById] - <== Total: 1 2020-06-26 17:48:42,124 INFO [TempTest] - TempEntity{id=1, value1='11111', value2='aaaaa'} 2020-06-26 17:48:42,125 DEBUG [dao.Temp03Dao.getById] - ==> Preparing: select * from temp where id = ? 2020-06-26 17:48:42,125 DEBUG [dao.Temp03Dao.getById] - ==> Parameters: 1(Integer) 2020-06-26 17:48:42,126 DEBUG [dao.Temp03Dao.getById] - <== Total: 1 2020-06-26 17:48:42,126 INFO [TempTest] - TempEntity{id=1, value1='11111', value2='aaaaa'} 2020-06-26 17:48:42,126 INFO [TempTest] - false一级缓存 脏读问题