数据库
数据库上托应用，下连基础设施，是整个 IT 系统中，承上启下最为关键的一环
Postgresql
PG以C语言写成，
因此其内部公开的接口（无论是FDW的回调函数接口还是供FDW使用的内部接口）都是面向C语言设计的，
时空地理分布式，时序文档超融合
PostgreSQL把锁分为三类,
table-level, row-level and advisory locks
.Table和Row级锁可以是显式或隐式锁,
advisory locks通常是显式锁.显式锁在显式用户请求时获得,而隐式锁则通过标准SQL命令获得
Row-level locks,分别是:更新操作的时候，必须对该行数据加锁
两个是排他锁，只能被一个事务使用。
另外两个是共享锁，可以被多个事务同时使用
1.FOR UPDATE 2.FOR NO KEY UPDATE 3.FOR SHARE 4.FOR KEY SHARE
PG作为队列
一般我们都是用 Redis/RabbitMQ等等 来做MQ
并将RabbitMQ替换为构建Postgres 数据库之上并用 SQL 编写的队列。
为什么首先需要一个队列？
一个 ORDER BY 子句来维护队列排序
通过简单的读/写行级锁保证作业不会被超过一个worker读取
1.设计存储表-来存储消息 pg_queue
队列名称和内容 queue_name queue_payload
时间- created_at updated_at executed_at
状态- status 取值有(pending, processing, done, failed,ack)
2.联合索引 -- add index
create index pg_queue_queue_name_status_idx on pg_queue (queue_name, status, executed_at);
3.任务 生产-消费
生产任务 -- add task to queue
INSERT INTO pg_queue (queue_name, payload) VALUES ('test', '1');
消费任务
取消任务
任务重试
清理过期任务
基于FDW的Sharding方案作为PG源生的分布式实现方案
PG的表继承 + postgres_fdw
FDW的核心就在于使用外部表（FOREIGN TABLE）
一个FDW实现的核心就是实现一组回调函数。有了这些回调函数的帮助，
在查询外部表对象的执行过程中就可以将运行逻辑切换至自定义的扩展代码中，进而遵照PG的内部机制实现对外部数据源的访问
PG 生态里向量数据库扩展
至少六款向量数据库扩展（ pgvector，pgvector.rs，pg_embedding，latern，pase，pgvectorscale）
pgvector 在以 AWS 为代表的厂商大力投入加持之下
PG 生态OLAP 生态-DuckDB扩展
有五个玩家下场赛马了，
包括 ParadeDB 的 pg_lakehouse，基于 DuckDB 打造 pg_lakehouse 扩展。
国内个人开发者李红艳编写的 duckdb_fdw，
CrunchyData 的 crunchy_bridge，
Hydra 出品的 pg_quack；
MotherDuck 原厂也跑过来做 PG 扩展了 —— pg_duckdb
使用 DuckDB 引擎进行计算，并且可以直接从文件系统/S3 上读取 Parquet / IceBerg 格式的文件
直接利用 PG的存储引擎接口，
直接用外部数据源包装器（FDW）的基础设施-FDW技术的初衷是为了统一异构数据源的访问方式
FDW（Foreign Data Wrapper），得用户可以通过SQL访问存储在PG之外的数据
远端数据如果本身要能够具备这些被下推的能力（JOIN、 聚合、数据更新等等）
助FDW已经可以实现将更多地运算（如JOIN，聚合等）下推至远端数据源，并能够对远端数据源的数据进行更新
语言和C语言
Go语言与C语言之间相对友好的交互机制（比起Java的JNI机制要友好很多）
duckdb
练习学习sql的新选择-用duckdb代替mysql个人最佳分析数据库
01.duckdb和依赖的parquet、httpfs插件
02.测试duckdb是否能正常使用OSS,
03.在postgresql中使用duckdb_fdw访问oss内的parquet文件
参考
https://github.com/alitrack/duckdb_fdw
为什么我们放弃 RabbitMQ 并用 Postgres 队列取而代之？ https://www.jdon.com/66350.html
PostgreSQL 当MQ来使用 https://jiajunhuang.com/articles/2024_03_09-postgresql_as_mq.md.html
