《云数据中心网络与SDN：技术架构与实现》——2.5.4　数据库

2.5.4　数据库

网络实际上是一个巨大的数据库。传统的设备通过交互路由协议来维护邻居表、拓扑表以及路由表等。转发设备中磁盘/硬盘这类资源极少，闪存一般也只用来存储设备的操作系统，像邻居表、拓扑表、路由表以及一些配置参数通常都是存在RAM里面的。RAM的好处是比磁盘/硬盘的读写性能要高很多，对路由协议的性能起到了很好的帮助。RAM的坏处就是设备掉电后这些表就都没有了，路由还要重新开始收敛，只有一些关键的配置才会被存到硬盘里做持久化。另外，转发设备中的RAM本身也不多，这要求做路由协议的开发人员对相关的数据结构要进行非常巧妙的设计。

SDN出现之后，控制器需要维护全局的视图，控制器中数据的存储与维护对于网络的稳定运行至关重要，因此数据库的设计对于控制器可以说是最为关键的。控制器相比于传统的网络设备，在数据库方面的考虑有如下不同。

首先，SDN控制器通常都部署在服务器中，各种存储资源非常丰富，可以摆脱开在设备上进行嵌入式开发的约束。存储资源的丰富，意味着数据库的选择就变多了。如果特别在乎速度，那么还是需要使用内存数据库，另外再进行持久化的设计。如果更在意容量和持久化，控制器则可以选择磁盘式数据库。如果要面对海量数据，甚至还可以考虑使用NAS、SAN等专用的数据存储解决方案。

其次，SDN控制器的实现机制是自己决定的，数据类型可以做得更灵活，数据操作的逻辑也可以做得更加自由了。传统网络设备里面，一条表项都会包含有很多的属性字段，为了完成转发可能需要多张表进行迭代查找，因此数据库的设计多为关系型的。对于SDN控制器来说，要存的数据增加了很多种类，数据格式会变得五花八门，而且在有了全局的视图后，一些传统的协议必须用到的参数很可能在控制器上就被简化掉了。大多数的数据关系按照键–值对（Key-Value）来存可能就足够了，因此非关系型数据库更适合SDN控制器。不过，具体的选型还是要看控制器上数据层面的具体实现，对于数据关系比较固定的，或者对于事务性要求较高的，那么关系型数据库可能仍然是首选。

再次，考虑到不同的应用场景，有可能需要为控制器集成特定的功能型数据库，因此一个控制器中可能会同时存在多种类型的数据库。比如，如果要求在控制器上做Telemetry数据的趋势分析或者实时反馈，可能就会需要将相关的数据存入时间序列数据库。如果要求在控制器上做网络资源的深度关联，可能就会需要将相关的数据存入图数据库中，等等。

控制器上的数据体量变大后，数据库的性能优化也是一个重大的问题。这个问题对于数据库领域而言可以说是老生常谈了，分区、分表、读库写库分离等思路都是SDN控制器可以在工程中借鉴的。