Python 全栈系列159 几种数据库的简单总结_全栈开发需要了解什么类型的数据库

说明

用的数据库稍微有点多，整理一下。

内容

数据库提供了一种可靠的，便于迁移的方式。

把最最规整，最最规范的任务留给他。

1 mysql

传统老项目

• 1 mysql: 用于列相对固定，量比较小的数据表
  • 用途：
    • 1 配置文件。每个表格的配置相对是固定的，使用mysql + web(datatables)可以更方便的锁定位置并进行编辑。
    • 2 报表类。报表的列都是相对固定的，mysql最怕的就是列的调整。
  • 约束：
    • 1 单表上限1000万数据。通常来说，mysql可以分为若干主题（据说可以有超10亿的表容量），但是每个主题不应过大。配置文件不必提，每个流程有个100行了不起了。而报表类大部分是汇总的，也不会大。比较特殊的是交易类表格，不过按照分钟级进行观察/决策，哪怕同时追踪1000只标的，一天最多也就产生1百万行数据，分散在若干标的下面，也就是几千行。
    • 2 数据格式。以数值为主，辅以少量短文本。尽量控制在40个字符内(sha1的长度）。短文本的任务是进行编号，简要提示以及哈希码外链。
  • 结论：
    • 1 mysql是一个在大数据下能力稍弱的数据库，这个和其本身的机制有关（ACID)
    • 2 mysql适合存储较为固定的，数字为主的表格
    • 3 在分页方面，mysql还算是比较方便。

2 mongo

可以装新酒的老瓶子

可json的数据在简洁和表达丰富上达到了极致。

• 2 mongo: 提供灵活的，更大量的存储
  • 1 用途：
    • 1 日志文件。例如每分钟获得的所有数据。
    • 2 空间数据。在进行复杂数据处理时，可以较为自由的传入、修改更多数据
    • 3 元数据文件。更丰富的，复杂的描述通过mongo保存。只要是可json的都可以存储。
  • 2 约束：
    • 1 单集合上限1000万。通过三级编码可以很清晰的将不同的任务区分开。虽然mongo的效率更好，但是在更大的集合上搜索并没有很大的意义。拆分成若干小集合，可以更快，甚至可以分布式的协同
    • 2 不要存放大文件。例如音频，视频，图片类的不要存放在记录里。某种程度上，mongo仍然存储的是元数据。而不是原始数据。
  • 3 结论：
    • 1 mongo的效率更高，但是也要准备好更大的内存
    • 2 mongo的数据记录格式更灵活，但这也要求使用者更好的进行规划

3 neo4j

暂时还是新事物

基于图库的一些简单的应用已经有很多，例如股权穿透。但这远远不是图的核心和极限，特别是很多知识推断/发现类的算法应该是基于图才对。

• 3 neo4j: 提供关系的记录和检索

  • 1 用途：

    • 1 依赖关系。既有数据的依赖关系，也有函数上的依赖关系。
    • 2 权限控制。基于图可以更灵活和精准的进行控制。
    • 3 推断类算法。知识类的推断算法需要基于图库。

  • 2 约束：

    • 1 单库上限1亿节点，十亿条关系。这个数量其实相对来说不小了,neo4j的免费版也比较良心，可以存。
    • 2 不要存大文件。和mongo类似，大文件应该交给文件系统，而不是放在数据库里。

  • 3 结论：

    • 1 neo4j在搜索关系方面更灵活，效率更高。

4 redis

比较单纯，就是尽量访问内存，而不是硬盘。尽量把一些常用的统计量准备好，而不是临时去算。

• 4 redis: 利用内存，降低数据库压力。

  • 1 用途：

    • 1 缓存计数。例如页面的访问量。
    • 2 需要即时处理的的数据。例如一些状态数据，像用户的授权哈希码之类的，避免过多的访问准静态数据库（mysql,mongo, neo4j等）
    • 3 构造简单队列。我还是比较喜欢用数据库队列。

  • 2 约束：

    • 1 存扁平化数据。通过三级编码，把一些特定的缓存以kv的形式存储。

  • 3 结论：

    • 1 用于存储一些缓存变量，降低准静态数据库的访问压力。

5 es

面对信息爆炸，除了搜索和推荐，我们还能怎么办？

• 5 es: 搜索
  • 这个就不多提了，和mongo比较类似，但是做了查询类的特殊优化。用在文档的管理方面比较方便。