混合数据库环境下日志存储方案及OrientDB实践咨询

一、OrientDB里存日志的几种方案优劣 #

• 把日志做成顶点：绝对别这么干。顶点是用来表达实体间关联的，日志是时序性的流水数据，几乎不需要和其他节点做关联查询。强行用顶点存，不仅浪费图数据库的存储资源，查日志时还要走图遍历逻辑，慢得离谱，后期维护也会一堆麻烦。
• 每条日志建独立节点：和上面的思路本质一样，换汤不换药。日志之间没什么关联，这种设计完全发挥不出图数据库的优势，反而把简单的事情搞复杂了。
• 用OrientDB的文档类存日志：这是最适合的方案。OrientDB本身支持多模型，你可以创建一个SystemLog类，把日志当作普通文档（非顶点）来存。这样既不用换数据库，写入和按时间/用户ID查询日志的效率也足够，完美适配日志这种结构化时序数据的需求。

二、双数据库架构是否更常规？ #

要看你的日志规模和查询需求：

• 如果日志量很大（比如每天几十万条以上），或者需要经常做复杂的统计分析（比如多维度聚合、实时监控），那双数据库甚至多数据库架构是行业常规操作：SQL库存用户表这类需要强事务的核心数据，图数据库存社交关系，日志单独用时序库（比如InfluxDB）或者ELK栈来存，这类系统对日志的写入、查询、归档优化得更到位。
• 如果日志量不大，查询只是简单的按时间/用户检索，那用OrientDB的文档类存就行，没必要额外加数据库增加运维负担。

三、要不要转文档式统一存储？ #

没必要强行统一。你的系统里两类数据的特性完全不同：

• 社交关系必须用图数据库才能高效处理关联查询（比如找用户的二度好友、关系路径），文档库做这类查询性能差到没法用；
• 用户表、日志是结构化强的数据，SQL的事务性和结构化查询能力比文档库更适合用户表，日志用文档或SQL都能处理，但没必要为了统一牺牲性能和便利性。
  所以混合架构才是最务实的选择——让每种数据用最擅长处理它的数据库，发挥各自的优势。

内容的提问来源于stack exchange，提问作者Antony