
130
|
第
13
章
为数据库的高性能和高伸缩性做规划和调优是一个既庞大又复杂的专题,超出了本书讨论
的范畴。如果你的应用要求极高的数据库性能,建议从《
MongoDB
权
威指南(第
3
版 )》
1
入手。
13.3.2
数据库层抽象
本书将演示使用两个数据库来实现同样的功能(不仅是两个名字不同的数据库,还是两种
根本不同的数据库架构)。尽管目的是讨论两种主流的数据库架构选择,但也是真实的场
景:在
We
b
应用开发过程中切换某个主要组件。这样做的原因有很多种,不过通常可以归
结为:在开发过程中发现另一项技术成本收益更大,或可以更快速地实现必要的特性。
尽可能把各种技术抽象出来是很有价值的。在这里把技术抽象出来指的是写某种类型的
API
层
,以实现各种底层技术一般化。如果做得好,就可以大幅降低更换有问题的组件的
成本。不过,它也是有成本的,因为这个抽象层本身要写出来并维护。
好在我们的抽象层很小,因为从本书的目的出发,只需要支持有限几个特性。目前而言,
支持的特性如下。
•
从数据库返回已上线的度假产品的列表。
•
存储用户的电子邮件地址,这些用户希望在产品上市时得到通知。
虽然看起来简单,但还是有很多细节的。一款度假产品看起来是什么样的?我们是每次都
从数据库获取全部的度假产品,还是希望能够对它们进行筛选或分页?该如何唯一标识一
款度假产品呢?诸如此类。
从本书的目的出发,我们需要让这个抽象层尽可能地简单。把抽象层放进名为
db.js
的文
件中,并导出两种方法。对这两种方法先提供模拟实现:
module.exports = {