不要总觉得大型互联网公司的数据存储结构会有多复杂。实际上简单得很，大部分都比你在大学 SQL 课上创建的数据库还要简单。越核心的数据，其存储结构越简单。简单的才可靠。
一、QQ这种大型数据库是怎么实现数据瞬间查询的
不要总觉得大型互联网公司的数据存储结构会有多复杂。实际上简单得很，大部分都比你在大学 SQL 课上创建的数据库还要简单。越核心的数据，其存储结构越简单。简单的才可靠。
像 QQ 这种，最核心的数据，一是用户信息，二是好友关系。我可以打包票，它们的存储结构只会是最简单的 key-value 格式，不会有第二种选择。
至于 key-value 怎么保存在内存或者硬盘上，倒是可以有多种选择，哈希表或者树状结构或者你想搞 LSM tree 什么的都可以，但是都不会超过大二的知识点。
举个例子，根据 QQ 号查用户信息。Key 是 QQ 号、value 是用户信息，就完了。
什么，你说还要按昵称查询、按邮箱查询？简单，每种查询条件再来一个 key，用 key-value 格式再保存一个 “昵称–>QQ号” “邮箱–>QQ号”的映射。这些核心数据都是读量远大于写量，所以不会在乎写的时候多写几个 key，要的是读快。
再比如说，好友关系。这也好说，每个用户一个 key，value 就是他的好友 ID 列表（排好序）。查好友的时候直接按用户拉出他的好友列表。查共同好友？把两个用户的好友列表都拉出来做交集，都是排好序的，取交集也就是 O(n) 的复杂度。
加好友的时候怎么办？往两边用户的 key 都写啊。读量远大于写量，写不怕麻烦，只要读快就行。
（公众号、微博这种带有 B2C 特性的关系链会复杂一点，因为关注者数量无上限。）
好了，存储格式定下来了，再说怎么查。
毕竟查询量巨大，一台机器扛不住，那就分多台。把 key 分一下段、或者哈希一下，分散到多台机器上，每台机器只保存全量数据的一部分。
基本原理就是这样，没有什么特别玄乎的东西。
实际工程上的努力，基本都在保证可用性和一致性上面。
可用性：机器多了，总有机器会死机，有硬盘会坏，有机房会掉电，有光缆会被挖断。怎么办？每份数据都存多份，放到多台机器上。保存相同数据的机器分布到多个机房甚至多个城市，不可能大家一起坏。当然， 这样写的时候会麻烦点，别忘了，大多数数据都是读多写少的，写不怕麻烦。
一致性：同一份数据在多机保存了多份以后，就得保证不能出现不一致的数据。这个才是最难的。
在互联网公司里，要想见到复杂的表结构、复杂的 JOIN、FOREIGN KEY 等，最可能的是在内部系统里面。内部系统的开发，在互联网的工程师里面是处于鄙视链比较低端的……
延伸阅读：
二、数据库的查询功能实现原理
数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化。最基本的查询算法当然是顺序查找（linear search），这种复杂度为O(n)的算法在数据量很大时显然是糟糕的，好在计算机科学的发展提供了很多更优异的查找算法，例如二分查找（binary search）、二叉树查找（binary tree search）等。如果稍微分析一下会发现，每种查找算法都只能应用于特定的数据结构之上，例如二分查找要求被检索数据有序，而二叉树查找只能应用于二叉查找树上，但是数据本身的组织结构不可能完全满足各种数据结构（例如，理论上不可能同时将两列都按顺序进行组织），所以，在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。
