3.15 数据库吐槽大会

大家好,我是一名狂热的数据库程序员,趁着 3.15 的良辰吉日,鼓起勇气站上了数据库吐槽大会舞台,以下故事纯属虚构,如有雷同,请对号入座。

名不副实的数据库类型

先说说最近的事,我们业务有很多图片要管理,老板说让我选个专业的图数据库,还给我推荐了 Neo4j、Nebula、TigerGraph 一堆,让我好好对比下图片管理的能力。乍一试,结果没一个是可以存图片的,都说他们是用来存对象关系图,比如粉丝关系、情侣关系、债主关系啊等等。你这不是坑爹嘛?取名字也不带这样糊弄老板的。

3.15 数据库吐槽大会_第1张图片

说到对象关系就恼火,那些号称发展了几十年的关系型数据库的,真是表里不一。有个项目我建了很多表的外键关联,并且还写了不少关联多个表的复杂 SQL,想秀秀技能,结果被 DBA 各种 diss,说这种外键和关联查询不适合用关系数据库,性能可能会很差,要打回去整改,感觉项目又要延期了。

我们那 mysql 关系型数据库里一张表已经快有1亿条记录,老板看到专家建议 mysql 最多放2000万条记录,但我现在也没遇到啥问题,到底是我错了还是专家说错了?如果按这建议我得搞几十张表,业务改造巨大,谁能救救我,我想怎么把专家先干了?同事说要不上文档数据库 MongoDB?

说起那个叫 MongoDB 的文档数据库就郁闷,你出来走两步,就一存 json 数据的,凭啥是文档数据库,也没看到你哪里适合存放 word、PDF 文档啊。你那【芒果数据库】的外号,难道你老板家种了很多 mango,再搞了专门放芒果的仓库。

3.15 数据库吐槽大会_第2张图片

还有,我们老板已经嚷了很久,说赶紧上大数据平台,不然怎么能把公司几百 GB的数据管理好。做好了大数据平台,我们未来就可能成为下一个 Google、微信,甚至是 ChatGPT。老板,你说的都对,高瞻远瞩,我想想怎么多搞些数据,不然咱们那台 PC 服务器可能闲得会罢工。

3.15 数据库吐槽大会_第3张图片

关系型数据库、图数据库、文档数据库,从这名字和实际功能看感觉都是个骗子。数据库不想再吐槽了,再吐槽下那些数据安全的囧事吧。

数据安全,不可小视

最近我那 Navicat 的开发工具又提示过期了,下了个破解版,最后发现藏了病毒,我慌得不敢说啊,找个好用的数据库开发工具就这么难吗?工欲善其事,必先利其器,老板能不能花点钱,咱们也支持下同行的正版计划,你看,人们都在知乎上要证明清白了。(能插个广告吗?数据库开发工具,就用ninedata,安全易用)

3.15 数据库吐槽大会_第4张图片

我们那数据库密码,已经用了3年,没变过,大家还经常使用,估计保洁阿姨和快递小哥都知道了,我也为公司慌啊,感觉那 DBA 兄弟的饭碗迟早会保不住。

最后是我们保命的数据库备份,每次要恢复的时候不是备份失败,就是恢复出错,要不就是恢复时间太长,业务接受不了,我都感觉这备份的投资是打水漂了,主要是用来应付领导的。

3.15 数据库吐槽大会_第5张图片

老板,还有 DBA 兄弟,我先吐这么多啊,我绝对不会删库跑路的,其他人就不敢保证了,你们保重啊!

总结

  • 图数据库不是用来管理图片,是用来管理对象关联关系,在社交、风控等领域用得上;
  • 关系型数据库的外键很多坑,在多表关联也很吃力,尤其是执行计划用不上合理的索引时;
  • MySQL 的2000w记录上限说法已经过时了,尤其是那个按B树高度的解释,关键还是看数据结构、SQL 语句和硬件性能,同时定期清理或归档历史数据;
  • 文档数据库不是用来存文档的,是用来存放 JSON 格式的数据,适合比较灵活的 schema 设计;
  • 几百 GB 数据就不要折腾大数据了,一般数据库或者数据仓库就挺合适的;
  • 数据库备份别忘了恢复演练,否则就是形同虚设;
  • 盗版数据库客户端工具别用,迟早被黑;
  • 数据库密码要保管好,经常变变。

关于作者

作者是来自 NineData 的数据库开发工程师,也是10年老 DBA。NineData 的官网地址:www.ninedata.cloud,提供企业级数据库 SQL 开发工具,数据复制、对比、备份等产品,免费使用,无需下载。

欢迎大家转发,或者在留言区一起来吐槽数据库的问题。

你可能感兴趣的:(3.15 数据库吐槽大会)