我见过用es存日志的，毕竟ELK就是做这个的。我也见过用mongo存日志的。毕竟也合适。但是我还听过用TiDB来存日志的，这个就有点大材小用了。当然MySQL和Oracle用来存日志的也不少见，以前听过一个故事，有人使用Redis来存日志。用关系型数据库存日志我勉强能理解为了查起来方便。但是用Redis存日志图什么？以上其实都是一般开发自己定的，完全是自己喜好。我记得5年前有个外包过来找我说他要一个redis集群，我当然要问问这是要干什么?他说要处理高并发场景，我说我们这里有redis，主从的。当然集群也有，在实验环境。我们场景就是没有redis也能支持，你还要集群吗？他回答不上来，我知道，他可能是培训机构速成的。这种其实在很多公司也常见，数据库十几种，消息队列五六种。基本就是微缩版的大厂架构，可能除了大厂自研的全上了。
但是实际上每种数据库有没有物尽其用？比如ABCDE几个系统都用了mongo，用来干什么？仅仅是存日志。如果仅仅存日志的话，其实MySQL的JSON也有这个功能，那么我可以减少一种技术栈。但是如果要深度使用一下的话，那么使用mongo才有意义。我的意思是每种技术要深度应用。看下面这图，mongo从4开始支持事务。说实在的我并没有好好在这方面使用，这个要反思。 这个案例就是多个步骤一句话完成。
我们平时不能只说有个功能，一旦这样说出去了开发就随意使用了。一定要做好demo，告诉应该怎么做不能怎么做。比如我说Oracle MySQL中的JSON类型是辅助的，别where条件后面就一个json的键值，因为通常没索引。当然也可以建立，但是这不是最佳实践。但是我依然日常能看到SQL依然我行我素的有且仅有JSON条件，当然并没有索引。最后有问题的话，还说这个不是支持嘛？要不我们用es吧？
用到es的时候，如果不用es的分词，那等于没用。完全就是靠硬件的全表（es的表叫索引）来抗。等于又没用好。
一个单机的MySQL PG每秒写入一万条数据不是难事。而且99%的系统根本达不到这种场景，但是可能在各种原因上比如SQL实现方式上有问题，这个时候如果找到问题就解决了。但是深度去了解技术栈，那么就会来个消息队列吧，削峰填谷。但是由于又未能对技术深入，不了解我们一般消息队列对于硬件的要求，给了他一个很差的IO环境。（话说如果这种情况消息队列还能正常，真的说明不用它也行）。然后能又怕消息队列丢数据或者为了确认消息的收发正常。那么异步（注意，一旦异构感觉就高大上了吧。解耦了。）再去把消息放到数据库中。
数据库技术栈本身就很卷，各种数据库多模，如何选型是一个课题，如何使用这个话题就更长了。今天不展开了。
