没记错的话，这数据库连内存表都没支持到位，作者在解释这个问题时还找了借口。

目前传统数据库，功能最齐全的，应该就是 Oracle，可惜贵了点。

科学的方式，是把整个业务进行过程式细化，然后接口设计为异步，并且提供过程状态查询接口。

比如：
用户通过 http 请求发送到指令到后台后，就不需等待，只需要调用过程状态查询接口，来查询目前后台处理状态。处理状态有且不限于：

1.查询不到请求。也就是用户 http 请求可能根本没发送到后台。

2.后台已经收到请求，后台正在向设备端下发指令。

3.后台在向设备端下发指令时出错，错误信息是：.....

4.设备端已经收到指令，等待设备端处理。

5.设备端处理超时。

6.设备端处理时发生错误，错误信息是：......

7.设备端已经处理完毕，目前设备端的状态是：......

这种设计，缺点是工作量比较大，优点是科学、严谨、用户体验好。

现在全麻中，有一部分常用的，连原理都没搞清楚。出现后遗症太正常了。

不过，虽然没弄清原理，但至少也是经过严格实验，保证了一定的安全性。在需要救命的手术时，两全其害取其轻。

zipfile 是 Python 实现的，不是 C 库，这是性能差的关键。

如果需要压缩的文件数量很多，建议用命令行或 cpp 来进行压缩或解压缩。

本质还是劳务市场的供求关系问题，僧多粥少。

多少人抢一个岗位，你不喜欢 996，负气离职，立马会有人接替你。

如果改不了这个本质，其他方面再怎么改良也没用。

职业选择，有 4 大因素要考虑：兴趣爱好、稳定性、收入、职业发展、休息时间。

不缺钱的，进体制内的清闲单位是最好不过了。

缺钱的话，不建议进体制内，收入太少。

现在 QQ 、微信、贴吧、豆瓣、知乎、斗鱼、虎牙、抖音、快手、各大相亲平台等等，这么多渠道，这都找不到女朋友，那已经是思路问题了。我不觉得再增加一个微弱的流量入口，就能解决问题。

婚恋是一门非常复杂的学问，但万变也离不开一些基本定律。

我建议还是先把婚恋知识好好学学，再去相亲吧。不然渠道再多，也挡不住你一顿瞎操作：
正常男性：我想认识你。
直男：看看逼。

看书太少 + 双标综合征。

1.如果你的知识面再广一些，你就能知道：人类每天食用的动物数量，等于整个一战二战人类牺牲数量总和；且普通男性一次射精，精液里的精子数量为 4000 万到 1.2 亿个。什么意思？意思是，你能幸运地投胎为人，每天活着就已经是最大的开心。

2.婚恋本来就是一门非常非常复杂的系统工程，难度不低于创业。你自己是个贪图享乐的自私人，接着在婚恋里贪图了对方的颜值或财力等某些东西，成为了舔狗；再接着你在完全没做好准备的情况下，贪图无套内射的快感，有了孩子。现在孩子成了你家庭生活、地位、时间与经济等的巨大负担。

3.你要想改变目前的生活，你总得损失些什么。

几个策略，如果你不想努力，针对你自私且愚昧的个性，你完全可以假装出轨，来逼迫对方离婚，然后想办法把孩子甩给对方，这样你就自由了。这条路子不需要怎么努力，简单，只是失去的东西会比较多。

或者，你可以更加努力，让你在经济与社会影响力方面，真正配得上女方，这样女方就不会整天找你事以及找你长辈的事，孩子也可以请人来带。但我不觉得你能努力的起来。

或者，你什么都不用做，保持现状。因为，作为一个人，已经是地球上所有物种中，最快乐的了。

@nevin47

1.没必要觉得被冒犯，VMware 公司的产品，功能与稳定性，目前太阳系第一。有时间建议了解一下这公司的发家史。

2.我没说它们完全是一回事，我只是建议用 ESXi 作为参照基准。

@BeautifulSoap
如果一定要掰字眼的话：
1.
Operating-system-level virtualization, also known as containerization, refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances. Such instances, called containers,

Hogg, Scott (2014-05-26). "Software Containers: Used More Frequently than Most Realize". Network World. Network World, Inc. Retrieved 2015-07-09.

2.
To do this, containers take advantage of a form of operating system (OS) virtualization in which features of the OS

IBM Cloud Education (12 August 2019 ), "What are containers".

又要复杂，又要方便输入，这种需求，我觉得生物识别或便携式加密设备更适合。

@LeeReamond 我回帖前，一般会翻翻发帖人的发帖、回帖记录，来综合分析发帖人到底遇到过什么问题，以及他们的水平、偏好、思路、习惯等等，这对于猜测发帖人的真实需求很有帮助。

你的问题我基本上已经回答了，但对你没太大帮助，因为关键决策性的东西，你已经做了一两个月了，现在来更换很不现实。而且在本帖中，你需要的回答，是需要长期进行积累与试错的经验性的东西，这些东西别人没办法一步到位帮到你。不过这事的本质还是你使用了高风险高回报的激进策略。选择什么策略没有好坏，只是你要考虑能否接受策略失败后的风险。

虚拟化由于其兼容问题的复杂度过高，永远都没办法 100%稳定。

玩虚拟化，最好是找台同配置电脑或服务器，装 ESXi，拿来做参照基准，这样找问题会比较容易。

找问题时，多用快照甚至克隆。每当你对虚机做了一小个更改，立马保存一个版本。通过不断对比版本，你就能发现，哪次在什么地方，做了什么更改，导致系统突然变得不稳定，或者系统的 CPU 使用率突然增高。找到问题出处后，再去分析，才容易得到结论。

1.不建议选择 Oracle，这玩意是个烂心大苹果，不仅难用，麻烦，而且 D 版 bug 多，正版死贵用不起。现阶段建议使用微软的 MSSQL，基本上高端数据库该有的功能，它都有。

2.大内存服务器，你别只看着一线品牌全新款，那肯定死贵。洋垃圾 E7 + 国产 2 线主板 + 插满 128G 内存，也就 3 千不到，只是新手去买容易踩雷。

3.Python 属于胶水语言，你找模块，找组件，完全没必要只在 Python 框架下找组件。你可以直接去找 top 3，然后看看它支持什么语言，接着用 Python 甚至 DB 做中转。

复杂系统一般都是这样拆分的，比如 java 写业务，python 写爬虫，C++处理高性能数据计算，MSSQL 处理核心数据，redis 做热数据缓存，mongodb 做龟速大批量计算，然后利用 http 或 pb 或 db 做数据中转与传输等等。

1.开发的本质，是解决需求。只要需求被解决了，就是好产品。

2.如果公司只是经常做短平快的小型开发，不建议你过多去了解其他内容，容易跑偏。这种情况下，集中精力去解决需求会更好。

3.不过，一旦公司要开始做大中型系统，需求规模变大后，那么，解决需求的效率，以及产品自身的管理，会逐渐成为问题，这会牵扯出一堆管理问题。

软件工程就是这些管理问题的总结与经验，如果你是属于这种情况，建议找几本软件工程的教材好好看看，这些内容比较多，帖子里写不下。

还有 std::clock()在虚拟化系统里经常出问题。

这两个问题的本质是，现在高阶 c++，时间处理方面，大多数转用 chrono 了，就算 chrono 有问题，因为用的人多，处理快，解决方案多。

而 time()、std::clock()这种，正好相反，现在基本上很少有人用了，更新后遗留 bug 或出问题，没人解决，也就很正常了。

IT 界这种问题很多，比如安卓，这系统一开始很烂，很多基本组件与功能都缺失。但是架不住用户多，各种缺失组件与功能，居然陆陆续续地被非官方开发者，解决地差不多了...