diff --git a/Cesium待实现功能.md b/Cesium待实现功能.md new file mode 100644 index 0000000..3dbf9f0 --- /dev/null +++ b/Cesium待实现功能.md @@ -0,0 +1,14 @@ +## Cesium待实现功能 + +### 1.展示型功能 + +- [ ] 1. 分层分户单体化功能 +- [ ] 2. 模型简化（优化加载） +- [ ] 3. 地下模式 + + + +### 2. 分析型功能 + +- [ ] + diff --git a/docs/article/db/neo4j_cypher.md b/docs/article/db/neo4j_cypher.md new file mode 100644 index 0000000..90b60a0 --- /dev/null +++ b/docs/article/db/neo4j_cypher.md @@ -0,0 +1,308 @@ +## Neo4j的cyhper基本语法 + +### 1. 创建节点和关系 + +#### 1.1创建节点 + +```sql + +create (n) +create (n),(m) +create(n:Movie) +create(n:Movie:Person) + +# 创建一个带有标签（Person）和属性（name:'TEST-NAME', age:1）的节点 +create(n:Person {name:'qiusj',age:18}) + +# 返回创建的节点 +CREATE(n:TEST {name:'TEST-NAME1', age:2}) return n +``` + + + +#### 1.2 创建关系 + +```sql +# 创建两个节点之间的关系 +MATCH (a:TEST),(b:TEST) +WHERE a.name = 'TEST-NAME' AND b.name = 'TEST-NAME1' +CREATE (a)-[r:RELTYPE] -> (b) +RETURN r + +# 创建两个节点之间的关系，并调用两个节点的属性： +MATCH (a:TEST),(b:TEST) +WHERE a.name = 'TEST-NAME' AND b.name = 'TEST-NAME1' +CREATE (a)-[r:RELTYPE { name: a.name + b.name}] -> (b) +RETURN r +``` + + + +#### 1.3 `merge` 命令 + +在Neo4j数据库中，**MERGE**命令是一个非常强大的工具，它结合了**CREATE**和**MATCH**命令的功能。当你需要确保一个特定的节点或关系在图中存在时，MERGE命令就显得尤为重要。如果该节点或关系不存在，MERGE将会创建它；如果已经存在，MERGE则会匹配到这个现有的元素。 + +> 如果这个节点已经存在，那么MERGE命令的作用就相当于MATCH命令。判断是否存在的方式是表达式中所有的属性组合匹配的：如 MERGE (p:Person {name: 'Alice'}) RETURN p;只要在已有的Person中name属性没有等于'Alice'的就是不存在，MERGE (p:Person {name: 'Alice,age:18}) 则要求现有的Person中的name和age都不相同才表示不存在 + +```sql +MERGE (robert:Person { name: 'Robert' }) +RETURN robert, labels(robert) +``` + +MERGE还可以用来创建节点之间的关系。如果两个节点之间的关系不存在，MERGE会创建这个关系。例如，以下命令会创建一个名为"Robert"的Person节点和一个名为"hanscal"的Person节点之间的FAMILY关系: + +```sql +MATCH (n:Person { name: 'Robert' }), (m:Person { name: "hanscal" }) +MERGE (n)-[r:FAMILY]->(m) +RETURN n.name, type(r), m.name +``` + +**使用ON CREATE和ON MATCH** + +MERGE命令可以与**ON CREATE**和**ON MATCH**子句结合使用，这允许你根据元素是被匹配到还是被创建来执行不同的操作。例如，以下命令在创建新节点时设置一个时间戳属性： + +```sql +MERGE (c:Person { name: 'Hanscal' }) +ON CREATE SET c.create = timestamp() +RETURN c.name, c.create +``` + +如果节点"Hanscal"已经存在，则不会设置任何属性。相反，如果使用**ON MATCH**，则只有在匹配到节点时才会设置属性。 + +**批量操作** + +MERGE命令也可以用于批量操作，快速创建大量的节点和关系。例如，以下命令会将所有Person节点的出生地属性与City节点连接起来，并创建BORN_IN关系： + +```sql +MATCH (person:Person) +MERGE (city:City { name: person.bornIn }) +MERGE (person)-[r:BORN_IN]->(city) +RETURN person.name, person.bornIn, city +``` + +总的来说，`MERGE`命令在确保数据一致性和避免重复创建相同的元素时非常有用。 + +**约束与 MERGE 命令的关系** + +- **唯一性约束**：确保指定标签的节点在特定属性上具有唯一性，是 Neo4j 保证数据完整性的重要机制 +- MERGE 命令行为： + + - 若匹配条件的节点 / 关系存在，则返回现有节点 / 关系 +- 若不存在，则创建新的节点 / 关系 +- **冲突点**：当 MERGE 的匹配条件触发唯一性约束时，会因重复数据导致操作失败 + + + +#### 1.4 添加属性 + + 方案 1：使用 MATCH 而非 MERGE（推荐） + +```sql +MATCH (p:Person {name: 'Robert'}) +SET p.age = 18 +RETURN p; +``` + +方案 2：修改 MERGE 语句避免重复创建 + +```sql +# 安全的MERGE写法（先检查节点是否存在） +MERGE (p:Person {name: 'Robert'}) +# 仅当节点不存在时才创建新属性（避免冲突） +ON CREATE SET p.create = timestamp() +# 无论是否创建都可以设置属性（不会触发约束） +SET p.money = 1 +RETURN p; +``` + + + +#### 1.5 修改节点的关系类型 + +在 Neo4j 中，关系类型（Relationship Type）是不可变的，无法直接修改。若要更改关系类型，需通过以下步骤实现：**创建新关系 → 复制属性 → 删除旧关系**。以下是详细方法： + +**方法一：使用 Cypher 手动转换关系类型** + +```sql +// 示例：将 KNOWS 关系转换为 FRIEND 关系 +MATCH (p1:Person)-[r:KNOWS]->(p2:Person) +WHERE p1.name = 'Alice' AND p2.name = 'Bob' +// 创建新类型的关系 +CREATE (p1)-[r2:FRIEND]->(p2) +// 复制旧关系的所有属性到新关系 +SET r2 = r +// 删除旧关系 +DELETE r +RETURN p1, r2, p2; +``` + + + + + + + + + + + + + +### 2.查询语法 + +> match、optional match、where、start和aggregation聚合 + +#### 2.1 match语法 + +**简单查询** + +```sql +# 查询所有节点 +match (n) return n + +# 查询指定标签的节点 +match (n:Person) return n + +# 查询指定标签和属性的节点 +match (n:Person {name:"张三"}) return n +``` + + + +**关系查询** + +```sql +# 查询出度1的节点 +match (n:Person{name:"张三"})-[r]->(m) return m +match (n:Person{name:"zhangsan"})-->(m) return m + +# 查询入度1节点: +match (n:Person{name:"zhangsan"})<-[r]-(m) return m +match (n:Person{name:"zhangsan"})<--(m) return m + +``` + + + +### 3.删除节点 + +- 删除无关系的孤立节点 + + 使用`DELETE`语句直接删除节点 + + ```sql + // 删除单个节点（无关系） + MATCH (p:Person {name: 'Alice'}) + DELETE p; + + // 批量删除符合条件的节点 + MATCH (p:Person) + WHERE p.age < 18 + DELETE p; + ``` + +- 删除带有关联关系的节点 + + 需先删除关系，再删除节点。可使用`DETACH DELETE`一次性完成： + + ```sql + // 方法1：分步删除（手动删除关系） + MATCH (p:Person {name: 'Bob'})-[r]->() + DELETE r; // 先删除所有外出关系 + MATCH (p:Person {name: 'Bob'}) + DELETE p; // 再删除节点 + + // 方法2：使用DETACH DELETE（推荐） + MATCH (p:Person {name: 'Charlie'}) + DETACH DELETE p; // 自动删除节点及其所有关系 + ``` + +- 基于关系条件删除节点 + + 删除符合特定关系条件的节点： + + ```sql + // 删除所有没有朋友的人（无FOLLOWS关系） + MATCH (p:Person) + WHERE NOT (p)-[:FOLLOWS]->() + DELETE p; + + // 删除被超过100人关注的明星节点 + MATCH (s:Star)<-[r:FOLLOWS]-() + WITH s, count(r) as followers + WHERE followers > 100 + DETACH DELETE s; + ``` + + + +- 删除整个标签的所有节点 + + ```sql + // 删除所有Person节点及其关系 + MATCH (p:Person) + DETACH DELETE p; + + // 更安全的分批删除方法 + CALL apoc.periodic.iterate( + "MATCH (p:Person) RETURN p", + "DETACH DELETE p", + {batchSize:1000, parallel:false} + ); + ``` + + + +- 删除节点并返回删除数量 + + ```sql + MATCH (p:Person) + WHERE p.lastLogin < date("2023-01-01") + DETACH DELETE p + RETURN count(*) as deletedNodes; + ``` + + + + +### 4. 删除关系 + +场景一：删除特定关系 + +```sql +// 方法1：通过匹配节点和关系类型删除 +MATCH (p1:Person {name: 'Alice'})-[r:FRIEND]->(p2:Person {name: 'Bob'}) +DELETE r; + +// 方法2：使用更精确的匹配条件（如属性） +MATCH (p1:Person)-[r:WORKS_ON {projectId: 'PRJ-123'}]->(p2:Project) +DELETE r; +``` + +场景二：只有查询返回的ID + +```sql +// 方法1：使用关系ID直接删除 +MATCH ()-[r]->() +WHERE id(r) = 5678 // 替换为实际关系ID +DELETE r; // 仅删除关系，保留节点 + +// 方法2：验证关系后删除 +MATCH ()-[r]->() +WHERE id(r) = 5678 +RETURN r; // 先查询确认关系是否存在 + +// 确认无误后执行删除 +MATCH ()-[r]->() +WHERE id(r) = 5678 +DELETE r; +``` + + + + + + + + + diff --git a/docs/article/devops/docker/docker_commond.md b/docs/article/devops/docker/docker_commond.md index 249044a..721c301 100644 --- a/docs/article/devops/docker/docker_commond.md +++ b/docs/article/devops/docker/docker_commond.md @@ -42,6 +42,23 @@ docker 命令 --help # 帮助命令 ``` +较常用的是`docker run [OPTIONS] IMAGE [COMMAND] [ARG...] `命令 + +参数说明： + +- **`-d`**: 后台运行容器并返回容器 ID。 +- **`-it`**: 交互式运行容器，分配一个伪终端。 +- **`--name`**: 给容器指定一个名称。 +- **`-p`**: 端口映射，格式为 `host_port:container_port`。 +- **`-v`**: 挂载卷，格式为 `host_dir:container_dir`。 +- **`--rm`**: 容器停止后自动删除容器。 +- **`--env` 或 `-e`**: 设置环境变量。 +- **`--network`**: 指定容器的网络模式。 +- **`--restart`**: 容器的重启策略（如 `no`、`on-failure`、`always`、`unless-stopped`）。 +- **`-u`**: 指定用户。 + + + ### 查看容器的元数据 > docker inspect 容器ID diff --git a/docs/article/devops/docker/docker_install.md b/docs/article/devops/docker/docker_install.md index 96b15a6..857d59c 100644 --- a/docs/article/devops/docker/docker_install.md +++ b/docs/article/devops/docker/docker_install.md @@ -167,7 +167,7 @@ yum install docker-ce docker-ce-cli containerd.io 登陆阿里云，找到容器镜像服务，找到镜像加速器。 -![Image](../images/docker03.png) +![Image](http://192.168.28.248:9000/mk-images/docker03_repeat_1731330405649__118815.png) 配置使用 diff --git a/docs/article/devops/gitlabeci.md b/docs/article/devops/gitlabeci.md new file mode 100644 index 0000000..e43d819 --- /dev/null +++ b/docs/article/devops/gitlabeci.md @@ -0,0 +1,352 @@ +## gitlab-ci.yml文件编写 + +> 转自：[02: gitlab-ci.yml 文件编写](https://blog.csdn.net/weixin_43730107/article/details/135839032) + +### 1.什么是gitlab-ci.yml文件 + +`gitlab-ci.yml` 文件是 GitLab CI/CD 的配置文件，它描述了各项任务如何和何时在版本控制过程中执行。文件中定义了一系列的任务或`jobs`，这些jobs可以被组织到各个阶段，并在触发某些事件时自动运行，如代码提交或代码合并。每次提交或推送都会触发一个新的 CI/CD `pipeline`，`gitlab-ci.yml` 文件便是负责协调和控制这个 `pipeline` 执行过程的大脑。 + +### 2.创建第一个 gitlab-ci.yml 文件 + +**文件结构示例** + +```shell +stages: + - build + - test + - deploy + +build_job: + stage: build + script: + - echo "This is the build stage" + +test_job: + stage: test + script: + - echo "This is the test stage" + +deploy_job: + stage: deploy + script: + - echo "This is the deploy stage" +``` + +`stages` 定义一组阶段，然后在每个工作描述中使用 `stage` 关键字指定其属于哪个阶段。`GitLab CI/CD`将会按照 `stages` 定义的**阶段顺序以及每个阶段内的作业并行度来执行作业**。 + +### 3.特殊指令 + +#### before_script + +通常`before_script`在`gitlab-ci.yml` 文件的顶层定义，作为全局设置。这样定义的 `before_script` 会在每个作业（job）执行前都会运行。before_script 虽然有全局配置的偏好，但也可以根据需要在单独的作业中定义。 + +```shell +# 在这个配置中，全局 before_script 会在 job1 和 job2 两个作业之前都执行一次。 +stages: + - build + +before_script: + - echo "This is a global before_script." + +job1: + stage: build + script: echo "This is job1." + +job2: + stage: build + script: echo "This is job2." + +``` + +也可以在具体的作业中定义 before_script，这样设置的 before_script 会只影响这个作业。 + +```shell +# job1 的 before_script 被重写为 "echo "This is a job-specific before_script.""，并且只在 job1 执行前运行。 +# 全局的 before_script 不会在 job1 之前执行，但会在 job2 之前执行。 +# 作业特定的 before_script 会覆盖全局的定义。 +stages: + - build + +before_script: + - echo "This is a global before_script." + +job1: + stage: build + before_script: + - echo "This is a job-specific before_script." + script: echo "This is job1." + +job2: + stage: build + script: echo "This is job2." +``` + +--- + +#### after_script + +after_script：它类似于 before_script，定义在这里的命令会在每个作业（job）的 script 部分执行完毕后运行。这常常用来在作业完成之后清理环境或存储日志等。 + +--- + +#### variables + +可以定义一组环境变量，这些变量会在所有作业中可用。例如，你可能需要在多个作业中使用同一个数据库的链接地址。 + +```shell +stages: + - build +variables: + DATABASE_URL: "postgres://user:pass@example.com:5432/dbname" +job1: + stage: build + script: echo "The database url is $DATABASE_URL." +``` + +--- + +#### stages + +定义作业的执行阶段。GitLab CI/CD 会按照 `stages` 的顺序执行作业。 + +```shell +stages: + - build + - test +job1: + stage: build + script: echo "Build stage" +job2: + stage: test + script: echo "Test stage" + +``` + +--- + +#### rules and only/except + +这两个指令都用于定义作业执行的条件。例如，你可以设置一个作业只在特定分支的提交时运行。 + +```shell +stages: + - build + - test + - deploy + +build_job: + stage: build + script: echo "This is building stage." + only: + - master + +test_job: + stage: test + script: echo "This is testing stage." + except: + - master + +deploy_job: + stage: deploy + script: echo "This is deploying stage." + rules: + - if: '$CI_COMMIT_BRANCH == "master"' + when: always + - if: '$CI_COMMIT_BRANCH != "master"' + when: never + +``` + +`build_job` 仅在主分支（`master`）上运行。相反，test_job会在所有分支上运行，除非是主分支。deploy_job 也仅在主分支上运行，使用了 `rules` 指令来实现这个条件，这是一个更复杂的条件判断，不同的规则 (if 语句)可以应对更为复杂的情况。 + +--- + +#### cache + +允许你定义一个缓存，这个缓存可以在作业之间共享。这常常用于缓存依赖，以加快构建的速度。 + +```shell +stages: + - install + - build + +variables: + BUNDLE_PATH: vendor/bundle + +cache: + paths: + - vendor/bundle + +install: + stage: install + script: + - bundle install --path vendor/bundle + +build: + stage: build + script: + - bundle exec rake build +``` + +在这个示例中，我们将 Ruby gems 安装到 vendor/bundle 目录下，然后在 cache 指令中声明这个路径来缓存这些 gems。 + +这样做的好处是，当在后续的作业或者后续的 pipeline 运行时，不需要重新下载和安装这些 gems，在此 .gitlab-ci.yml 文件的配置中，如果 cache 设置正确并且有效，然后在 vendor/bundle 路径下的gems没有发生变化（即 Gemfile 和 Gemfile.lock 文件没有发生改变），那么 bundle install --path vendor/bundle 命令就不会再次下载已经缓存的 gems。这是因为 Bundler（Ruby的依赖管理工具）会检查 gems 是否已经存在，如果已经存在并且版本匹配，那么就不会再次下载。 + +综上，对于重复的 install 作业，如果 Gemfile 和 Gemfile.lock 中的内容没有发生变化，那么即使在 pipeline 再次运行此作业，也不会再次下载已经缓存的 gems，从而可以加快构建的速度。可以大大减少构建的时间。 + +`install` 和 `build` 两个作业分别在 `install` 和 `build` 阶段运行。`install` 阶段会使用 `bundle install` 命令来下载和安装 gems，build 阶段则使用 `bundle exec` 来执行构建命令。 +通过这个配置，我们就可以在多个作业之间，以及多次 `pipeline` 运行之间共享这些 `gem` 的缓存，以此来加快构建的速度。 + +对于重复的 install 作业，在下次pipeline中会再次运行吗？ +如果 cache 设置正确并且有效，然后在 vendor/bundle 路径下的gems没有发生变化（即 Gemfile 和 Gemfile.lock 文件没有发生改变），那么 bundle install --path vendor/bundle 命令就不会再次下载已经缓存的 gems。这是因为 Bundler（Ruby的依赖管理工具）会检查 gems 是否已经存在，如果已经存在并且版本匹配，那么就不会再次下载。 + +综上，对于重复的 install 作业，如果 Gemfile 和 Gemfile.lock 中的内容没有发生变化，那么即使在 pipeline 再次运行此作业，也不会再次下载已经缓存的 gems，从而可以加快构建的速度。 + +--- + +#### artifacts + +声明一些构建产物，这些产物将会在 `gitlab-ci.yml` 文件中其他作业或后续阶段的作业中可用，或者可供直接下载查看。 + +```shell +stages: + - build + - test + +build: + stage: build + script: + - mkdir build + - echo "Build artifacts" > build/artifacts.txt + artifacts: + paths: + - build/ + +test: + stage: test + script: + - cat build/artifacts.txt + +``` + +在这个示例中，我们的 pipeline 分为两个阶段：build 和 test。在 build 阶段运行的 build 作业中，我们创建了一个 build 目录，并在其中生成了一个名为 artifacts.txt 的文件。 + +然后，我们使用 `artifacts` 指令声明了 `build/` 路径下的所有文件都是构建产物，GitLab CI/CD 将会在构建完成后收集这些产物。 + +在后续的 test 阶段的 test 作业中，我们可以直接访问到这个 artifacts.txt 文件。也就是说，通过 `artifacts` 允许我们在后续阶段的作业中使用到前一阶段的构建产物。 + +--- + +#### include + +用于在当前 .gitlab-ci.yml 文件中引入其他的 CI/CD 配置文件，可以实现配置的模块化和共享。被引入的文件可以位于同一项目的其它位置，也可以位于其他项目，甚至可以从远程的 HTTP(S) URL 中引入。引入的文件将像是在主配置文件中一样被解析和执行，这对于大型项目或需要共享 CI/CD 配置的情况很有用。 +比如说，你有一个库 my-great-library。该库有自己的 .gitlab-ci.yml 文件，如下： + +```shell +variables: + BUILD_DIR: build + +stages: + - build + - test + +build: + stage: build + script: + - mkdir ${BUILD_DIR} + - echo "Building the library" > ${BUILD_DIR}/result.txt + +test: + stage: test + script: + - echo "Testing the library" + +``` + +而你在其他许多项目里都依赖这个库，并且需要对这个库进行构建和测试。这时，你可以在其他项目的 CI 标记 include，将这个库的 CI/CD 配置包含进来，例如： +项目 project-1 的 .gitlab-ci.yml： + +```shell +include: + - project: 'yourusername/my-great-library' + file: '.gitlab-ci.yml' +``` + +这样就可以实现在多个项目中共享一个统一的 CI/CD 配置，避免了每个项目都需要重复编写相同的配置，从而大大提高了效率。同时也有利于集中管理和修改这个共享的配置。 + +--- + +#### extends + +用于复用已经定义的特定配置。在 GitLab CI/CD 配置中，我们可以定义一些通用的配置作为模板，例如设定重用的 `script` 块或者 `before_script` 块等，然后在需要的地方使用 `extends` 进行引用。不同于 `include` 关键词，`extends `并不会引入新的文件，而是仅仅在当前文件内部进行配置的重用。 + +```shell +# 我们首先声明一个 '.base_job'，这个定义包含了所有作业共有的部分 +.base_job: + before_script: + - echo "Setting up the job environment" + after_script: + - echo "Cleaning up after job" + +# '.build_template' 扩展了 '.base_job'，并添加了构建阶段特有的设定 +.build_template: + extends: .base_job + variables: + BUILD_DIR: build + script: + - mkdir ${BUILD_DIR} + - echo "Building the project" > ${BUILD_DIR}/output.txt + stage: build + +# '.test_template' 也扩展了 '.base_job'，然后添加了测试阶段特有的设定 +.test_template: + extends: .base_job + script: + - echo "Testing the project" + stage: test + +# 现在我们定义具体的构建和测试作业，它们分别扩展了 '.build_template' 和 '.test_template' +job1: + extends: .build_template + variables: + JOB_NAME: JOB1 + +job2: + extends: .test_template + variables: + JOB_NAME: JOB2 + +stages: + - build + - test + +``` + +通过 .base_job，我们为所有作业指定了公共的 before_script 和 after_script。然后，对于构建和测试阶段，我们又分别创建了扩展了 .base_job 的 .build_template 和 .test_template。最后，我们创建了两个具体的作业 job1 和 job2，它们扩展了各自的模板并添加了一些特定的配置。.base_job作为模板，.build_template和.test_template去继承它，如果二者都有相同的key，则使用子类的value覆盖父类，同理job1和job2。 + +--- + +#### tags + +`tags`是用来选择执行该 `job` 的特定 `Runner`。 + +Runner 是 GitLab 提供的用于执行 CI/CD 任务的服务。每个 Runner 可以配置一组标签（tags），这样在定义 CI/CD 任务时，就可以通过设置相应的 tags 来选择对应的 Runner 来执行任务。 + +tags 中的 arm 指的是这个任务build_docker_arm必须由带有 arm 标签的 Runner 执行。这通常表示这个 Runner 是能够构建 ARM 架构 Docker 镜像的环境。如果没有带 arm 标签的 Runner，该任务会排队等待，直到有合适的 Runner 可用。所以这个 tags 配置是用来选择 Runner，而不是在 build 镜像时指定基础镜像。 + + + + + + + + + + + + + + + + + diff --git a/docs/article/web/js/vue3.md b/docs/article/web/js/vue3.md index 02e223f..f23dc5e 100644 --- a/docs/article/web/js/vue3.md +++ b/docs/article/web/js/vue3.md @@ -231,7 +231,7 @@ Vue3中生命周期API（选项式 VS 组合式） ```html