@nothingistrue 有点搞笑，那么多人都说了， 你怎么还这么头铁。tidb 是 newsql ， 其设计是在 google spanner F1 论文的实现 来对关系事务做支持。
tidb mysql 兼容的 mysql 传输的协议 和 sql 语法，而不是什么二开。
另外 tidb 设计理念就和 mysql 没有关系，
存储引擎层用 rust 写的 tikv, TiKV 的 KV 存储模型和 SQL 中的 Table 无关
查询层则是用 golang 写的。

你们的业务是 OLTP 为主， 仅仅是数据量的话，这些方案都不需要，直接建 mysql 分区表，数据量和并发、吞吐量不是一回事。
如果是面向用户的较高并发简单点就是 Sharding-JDBC ，不过依然会存在各种不兼容要修改代码的问题，分库分表的限制也是不少的。
分布式数据库也有很多种选择， 一般分为两类，一类是 NewSQL, 另一类是 PG-XC ，NewSQL 包含 oceanbase, tidb.

可以考虑一些 PG-XC 的数据库，是在传统关系型数据库，增加了切片集群，增加了协调节点，增加了全局时钟,性能比较稳定，也比较接近分库分表。
一般有如下几个
腾讯的 TBase
华为的 GuassDB 300

无论是深入了解原理还是深度二次开发都必然是 Go

zeromq 没怎么用过特殊模式，你把 zeromq 看成一个可以实现内存消息队列的设计精巧的网络库就好。

zeromq 低延迟和内存低占用 不是其他通信方式可以比的， 不少人是自己在 zeromq 的 源码和 业务代码上添加一些额外功能比如持久化。

zeroq 支持三种通信方式 inproc 、ipc 、tcp

我用的是 inproc 和 ipc , inproc 对共享内存做了封装, ipc 则是 unix domain socket, 其 ipc 封装实现很不错了

如果单机内部不同进程之间通信而不是不同主机之间通信，可以考虑 zeromq, 像嵌入式设备或边缘设备上用这个也不错。

我是用在 视频处理和分析中， 将 c++ 读取监控摄像头的视频帧分发给不同的 GPU 上跑的 python 程序，完成并行不同功能的 AI 处理。

一些参考的例子

https://github.com/jeffbass/imagezmq
https://pyimagesearch.com/2019/04/15/live-video-streaming-over-network-with-opencv-and-imagezmq/

大公司自建云基础设施，
如果项目可以结合一些弹性混部，在线离线混部的建议 比较好。

java 用 opencv 的 bindings 就行， 其他的处理都比较麻烦，rtsp 流协议 存的也不是每帧图像全部像素，涉及到很多视频处理。

@bthulu 先学会点礼貌先，没一点礼貌，我也不想回复你的任何问题

@bthulu 你自己不去看看 java 的新题案和 解决策略比如 graalvm ， 你机器上没有 jvm 可以跑 java ， 是吧。
jvm 设计之初就是为了充分利用服务器内存，甚至是多占用一些内存 来做 gc 。

要对比 docker 那也是对比虚拟机像 kvm 、vmware 的方案。
你什么都不懂就开始胡乱 at 人吧。

微服务不等于云原生， 微服务本身拆分和规划本身就不只是技术，还是团队管理问题。国内不少公司还停留在管理不善的问题阶段。

多数人对 devops 并不理解吧，k8s 就是单体部署也没有什么问题。 国内和国外所了解的都不是一回事

国外是谷歌新出的论文"towards modern development of cloud application"和 service weaver 对 微服务 发出新的构想。

文章认为，微服务将逻辑边界（如何编写代码）与 物理边界（如何部署代码）混为一谈。提出的方案是将应用程序构建为逻辑整体， 但将其交给自动化运行时， 后者根据应用程序所需内容和可用内容来决定在哪里运行工作负载。

bitvise ssh

python 本身优化就是挺垃圾的， 才会导致不同的写法性能差距比较大。

真正研究 python 都是研究 python 源码 和 如何写出不错的代码，这个基本没有提，语法糖再多也不是原理。

比如 python c 代码的 PyObject 数据结构，cython 以及 pypy

那要看业务是否复杂了， 大多数互联网涉及到的数据库操作并不复杂。y 银行到目前为止还有大量存储过程，不过银行用的是 oracle, 完全碾压 mysql, mysql 说实话性能垃圾， 支持的功能也少，像 oracle rac 这类，mysql 就更差了,花钱买的和免费不在一个水平， 不同的业务考虑是不同的，如果看重吞吐量和并发量，那么的确不要使用这些。
大厂都没有多少复杂的金钱结算一致性非常强的业务， 有这个的都去搞自研数据库了

@IbukiSuika 考虑 mysql 逐渐商业化，mysql 社区版和商业版服务差距变大，稳定性等因素。
另外就是国产数据库厂商和国内评审专家的意见。

不要关注 mysql, 多关注 pg 一下。
第一、互联网用不到多少复杂的 mysql, 在银行、保险等企业才会有大量 sql 以及存储过程这类
第二、互联网已经退潮了， 多关注一下 IT 除互联网外的行业使用得数据库行情。
第三、pg 国企还有一些国产数据库开发是比较多的，mysql 屎山太多， 做的扩展和插件远不如 pg, pg 现在通过插件都可以搞向量数据库。
第四、国家内部国企央企钦定不使用 mysql 5.7 以上的，mysql 现在被 oracle 搞得很不明朗，pg 才算是真正开源

这个问题不需要大模型，大模型也不是用来解决这类计算机视觉的问题。
ocr 一般是正面拍照的纸张上文字，在一些复杂环境下无法使用，这种其实是 scene text recognition,
传统的 OCR 很多是机器学习的算法，在弱光、混合光线下非平整表面一些识别率不高，
深度学习一些模型还可以。
你发一个图片才能知道是什么样的场景。

和邓明的 go 实战训练营 的第一部分一样

总结得不错

不清楚你的编程水平如何，如果不太好，
要么直接 方案设计 1

要么使用 access 数据库， 毕竟用 access 打开 accdb 文件就可以提供清晰的 UI ，也是所有开发成本中最低的。（写点 VBA 宏或 python 再配合 access 多种查询界面和表单足以满足权限和安全要求）

看了看 ShadowPower 发的，其实个人玩玩还是可以的，
这类模型微调很多， 其实就是用语料训练一个 chatbot
半年前那个 AI 孙艳姿 唱歌 还火过，也是这类， 自己玩玩可以， 商业上谈不上。
另外，国内任何 AI 应用上线 还要接受《生成式人工智能服务管理办法》制约，敏感词是要过滤的。

国内外 AI 团队已经不再是简单的微调了，都已经上升到 AI 对齐了。