Django 实现分库

首先创建一个 logstat 的项目，然后一个创建 report 的 app。

>>> django-admin startproject logstat
>>> cd logstat
>>> django-startapp report

配置 setting 中配置 default DATABASES：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'logstat',
        'USER': 'logstat_user',
        'PASSWORD': 'logstat_password',
        'HOST': 'localhost',
        'PORT': '3306',
        'CHARSET': 'utf8',
    },
}

接下来配置分库日志的数据库，为了 demo 写起来方便，改成 2 个库：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'logstat',
        'USER': 'logstat_user',
        'PASSWORD': 'logstat_password',
        'HOST': 'localhost',
        'PORT': '3306',
        'CHARSET': 'utf8',
    },
    'logsharding0': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'logsharding0',
        'USER': 'logstat_user',
        'PASSWORD': 'logstat_password',
        'HOST': 'localhost',
        'PORT': '3306',
        'CHARSET': 'utf8',
    },
    'logsharding1': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'logsharding1',
        'USER': 'logstat_user',
        'PASSWORD': 'logstat_password',
        'HOST': 'localhost',
        'PORT': '3306',
        'CHARSET': 'utf8',
    },
}

create database logstat charset='utf8';
grant all on logstat.* to 'logstat_user'@localhost identified by 'logstat_password';
create database logsharding0 charset='utf8';
grant all on logsharding0.* to 'logstat_user'@localhost identified by 'logstat_password';
create database logsharding1 charset='utf8';
grant all on logsharding1.* to 'logstat_user'@localhost identified by 'logstat_password';

在 logstat/report/models.py 中添加我们要存储的日志格式：

class Log(models.Model):
    serverid = models.IntegerField('服务器ID')
    logid = models.IntegerField('日志类型')
    desc = models.TextField('日志内容', blank=True)
    report_dt = models.DateTimeField('上报时间')

然后将 app 添加到 INSTALLED_APPS 中。 ./manage.py makemigrations 产生 migrations 文件。

同步数据库：

./manage.py migrate
./manage.py migrate --database=logsharding0
./manage.py migrate --database=logsharding1

这时候我们发现，所有的 migrations 都在 default, logsharding0, logsharding1 分别创建了表。这显然不是我们想要的。 我们想要的效果是 report app 中的模型不在 default 中创建，只在 logshardingx 中创建，而 default 中的模型， 也不希望在 logshardingx 中创建。

此时我们需要添加数据库路由器。

在 logstat/report 中创建 log_router.py 文件，添加路由规则：

class LogRouter(object):
    def allow_migrate(self, db, app_label, model_name=None, **hints):
        if app_label == 'report':
            return db == 'logsharding0' or db == 'logsharding1'
        return None

意思是，在 migrate 时，如果是 report App，并且 database 是 logshardingx 是可以创建的，否则不创建。

在 setting.py 中添加数据库路由器，使之生效：

DATABASE_ROUTERS = ['report.log_router.LogRouter',]

同步数据库：

./manage.py migrate
./manage.py migrate --database=logsharding0
./manage.py migrate --database=logsharding1

这时，我们发现 report_log 表已经不再 log_stat 库中，而只出现在 logshardingx 中。但是在 logshardingx 还是会有 auth_group=，=auth_group_permissions … 这些 Django 组件的表。到现在，我们已经实现了分库的效果，这些额外的表我们不用关心， 但是总觉得不优雅，还是去比较好。

这些额外的 App 分别是 admin, auth=，=contenttypes, sessions, messages, staticfiles ，同样我们需要为他们设置路由规则， 在 logstat 下创建 default_router.py 添加路由规则，使得其余的 App 自动只选择 default ：

class DefaultRouter(object):
    def allow_migrate(self, db, app_label, model_name=None, **hints):
        if app_label == 'admin' \
           or app_label == 'auth' \
           or app_label == 'staticfiles' \
           or app_label == 'sessions' \
           or app_label == 'messages' \
           or app_label == 'contenttypes':
            return db == 'default'
        return None

同样添加到 DATABASE_ROUTERS 中，

DATABASE_ROUTERS = [
    'logstat.default_router.DefaultRouter',
    'report.log_router.LogRouter',
]

再执行 migrate --database=xxx 时，只创建了两个表， django_migrations 和 report_log ，这就是我们想要的效果。

备注: django_migrations 这个表是必须存在的，它是数据库 migrate 记录，以保证再次 migrate 时， migrations 文件不被重复执行。

Django 在多数据库文档中提供了指定数据库的用法，但是我个人倾向于一个简单的规则：「同时只操作一个库」。 从那个库中查询的数据，无论是修改、保存还是删除，都只操作同一个库。像：

>>> user_obj.save(using='new_users')
>>> user_obj.delete(using='legacy_users')

这种用户从一个表迁移到另外一个表，应该写的更明确一些，应在业务上迁移而不是利用 using 关键字和 Django 的设计取巧。 尽管这非常方便，但是对于维护代码的人简直就是灾难！所谓业务上的迁移是，首先创建一个新的用户(User.objects.using('new_users').create())， 待新用户创建以后，再删除旧用户(User.objects.using('legacy_users').filter().delete())，逻辑清晰。

自此，一个分库的例子就讲完了，也比较简单。聊几句个人想法，选择框架和选择技术，因为业务场景不同，很难有一个完美的解决方案，总是要做一些取舍。

比如说，自己写一个直接独立于 Django 的分库分表策略并不难，但是脱离了 Django 这一套东西，常用的 API 用不了(create, filter, delete etc)， 为每一个操作封装一个 SQL 操作，测试起来比较麻烦，灵活性太强，扩展性差，重要的是还要防止 SQL 注入。

如果用 Django 的多 DB 实现策略，也有问题。首先是路由，新的 app 如果忘了设置路由规则，很容易把表生成到不想生成的地方，而且 Django 官方文档也说了，并 不会检查非 default 迁移的一致性(1.10之后版本可能支持)。其次是外键，使用了分库之后外键约束自然就没有了，这也不算一个问题。 还有在使用上，每次访问数据库都必须要用 using 显式的选择一个数据库。忘了如果路由规则设置没问题会直接报错这倒还好，如果选择错了， 就蛋疼了，因为他们每个库的结构都是一样的，很难查出问题。这将为写代码增加复杂性。

我的建议是，既然没有一个完美的方案，就应该尽量的保证逻辑简单、清晰，不要过分的依赖框架，少使用 hack 技巧。像上面那种

>>> user_obj.save(using='new_users')
>>> user_obj.delete(using='legacy_users')

尽管可行，但个人认为这是非常不可取的。