使用 MongoDB 持久化文档数据
有一些数据的最佳表现形式是文档(document)。也就是说,不要把这些数据分散到多个表、节点或实体中,将这些信息收集到一个非规范化(也就是文档)的结构中会更有意义。尽管两个或两个以上的文档有可能会彼此产生关联,但是通常来讲,文档是独立的实体。能够按照这种方式优化并处理文档的数据库,我们称之为文档数据库。
例如,假设我们要编写一个应用程序来获取大学生的成绩单,可能需要根据学生的名字来查询其成绩单,或者根据一些通用的属性来查询成绩单。但是,每个学生是相互独立的,任意的两个成绩单之间没有必要相互关联。尽管我们能够使用关系型数据库模式来获取成绩单数据(也许你曾经这样做过),但文档型数据库可能才是更好的方案。
文档数据库不适用的场景
文档数据库不是通用的数据库,它们所擅长解决的是一个很小的问题集。
有些数据具有明显的关联关系,文档型数据库并没有针对存储这样的数据进行优化。例如,社交网络表现了应用中不同的用户之间是如何建立关联的,这种情况就不适合放到文档型数据库中。
使用 Neo4j 操作图数据
文档型数据库会将数据存储到粗粒度的文档中,而图数据库会将数据存储到多个细粒度的节点中,这些节点之间通过关系建立关联。因为数据的结构是图,所以可以遍历关联关系以查找数据中你所关心的内容,这在其他数据库中是很难甚至无法实现的。
例如,社交网络图谱,在社交网络中,公司、员工、技能的信息,这些都是节点,它们之间的关系和朋友之间的关系都是边,在这里面图数据库可以做一些非常复杂的公司之间关系的查询。比如说公司到员工、员工到其他公司,从中找类似的公司、相似的公司,都可以在这个系统内完成。
使用 Redis 操作 key-value 数据
Redis 是一种特殊类型的数据库,它被称之为 key-value 存储。顾名思义,key-value 存储保存的是键值对。实际上,key-value 存储与哈希 Map 有很大的相似性。可以不太夸张地说,它们就是持久化的哈希 Map。
当你思考这一点的时候,可能会意识到,对于哈希 Map 或者 key-value 存储来说,其实并没有太多的操作。我们可以将某个 value 存储到特定的 key 上,并且能够根据特定 key,获取 value。差不多也就是这样了。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。