信用中心数据库选型和实践

我们公司要建立一个个人信用中心，用来记录移动运营商，淘宝，京东，学信，征信，以及我们各个系统的数据，并将以上数据分析得出个人的信用报告。

首先选择数据库，考虑到个人征信来源比较多，每个来源的信息格式比较多，如果采用mysql数据库，必然是一个庞大的表结构，因此考虑用mongodb。每个人一条数据，记录一个人的所有信用数据，16M的空间因该是足够了，由于每个人只是建一条数据，操作的时候自然是原子操作。整个数据库中只有2张表，一张个人信用表，记录个人信用信息。一张索引表，记录递增的索引。

写入数据的流程是这样的，信用中心自带前端，当其他业务系统需要写入个人信用的时候，跳转到信用中心的前端，只需要传递各个系统自己的token就好了，前台用token调用后台，后台用传入的token去redis中查询，得到这个人在该系统中的id，然后查询个人信用表的业务系统列表，看数据库中有没有这个系统id对应的人，如果没有查询到，则跳转到绑银行卡的页面，需要用户首先绑卡，确定这个人的身份后才建立这个人的信用信息，然后再录入其他信息。当其他的业务系统也想查询或是写入同样一个人的信息的时候，也是需要首先绑卡，确定“我是我”之后，才将id写入个人信用的业务系统列表中。这样以后查询或是写入信息的时候，在我们公司内部，个人信用中心的数据是共享的，同时也将绑卡信用征集等一系列的功能剥离出业务系统。

实际操作的过程中，比如调用第三方公司来获取运营商数据，淘宝数据等的时候，由于解析数据有可能会出错，因此将全流程拆成了两部，第一步，获取数据后首先以字符串形式将获取的数据写入到表中，然后解析数据。第二步，将解析后的数据写到表中，同时将之前写入的原始数据删除掉。

实际使用下来看，每个人的数据都有1M，查询的时候需要过滤一下返回的数据。整个数据库看起来比较清爽，只有两张表。只要合理组织数据，整个数据也比较好理解。