【Database】聚集索引（Clustered Index）与非聚集索引（Non-clustered Index）

DB 索引数据的存储方式 - 聚集索引（Clustered Index）与非聚集索引（Non-clustered Index）

索引数据的存储方式 - 聚集索引（聚簇索引，Clustered Index）

聚集索引（clustered index），也称为聚簇索引。

聚簇索引并不是一种单独的索引类型，而是一种索引数据的存储方式。

当表有聚簇索引时，它的行数据实际上存储在索引的叶子页（leaf page）中。因为无法同时把数据行存放在两个不同的地方，所以一张表只能有一个聚簇索引。

more >>

Show More >>

【Django】通过 ORM 访问 MySQL，插入 Emoji 报错

Problem

1
2
3
4
5
6
7
8
>>> paras = {u'name': u'\U0001f600'}
>>> from core import models
>>> models.Channel.objects.create(**paras)
Traceback (most recent call last):
    ...
  File "/Library/Python/2.7/site-packages/pymysql/err.py", line 109, in raise_mysql_exception
    raise errorclass(errno, errval)
InternalError: (1366, u"Incorrect string value: '\\xF0\\x9F\\x98\\x80' for column 'name' at row 1")

通过 ORM 插入一条数据，在其中的一个类型为 varchar 的字段中插入一个 Emoji 表情，我插的是😀（对应的字符串为 u'\U0001f600'），插入后：提示以下错误：

1
{InternalError}(1366, u"Incorrect string value: '\\xF0\\x9F\\x98\\x80' for column 'name' at row 1")
more >>

Show More >>

【MySQL】MySQL 的存储引擎（Storage Engines）- MyISAM 与 InnoDB

MySQL 有两种存储引擎（Storage Engines）：

  • InnoDB’s
  • MyISAM

MyISAM

MyISAM 不支持聚簇索引，因此，MyISAM 中的主键索引（Primary Index） 和辅助索引（Secondary Index），都是非聚集索引（Non-clustered Index）。

在 MyISAM 的 B+Tree 的叶子节点上的 data 域中，并不是保存数据本身，而是保存数据存放在磁盘中的地址。

more >>

Show More >>

【Django】Django 项目部署到 uWSGI + Nginx 作为生产环境

Workflow

当客户端发出一个 HTTP 请求后，是如何转到我们的应用程序处理并返回的呢？

我根据其架构组成的不同将这个过程的实现分为两种情况：

image-20191028215442798

两级结构

在两级结构中：

  • uWSGI 可以作为 WSGI Server（WSGI 服务器），它基于了 HTTP 协议、 WSGI 协议和 usgi 协议；
  • Flask 应用可以作为 WSGI Application，基于 WSGI 协议实现。

当有客户端发来请求，uWSGI 接受请求，调用 WSGI Application （或者说 Flask 应用）。当 WSGI Application 处理完成后，将结果返回给 uWSGI，uWSGI 构造相应的 HTTP Response，最终将结果返回给客户端。

通常来说，Flask 等 Web 框架会自己附带一个 WSGI 服务器 (这就是 Flask 应用可以直接启动的原因)，但是这只是在开发阶段被用到而言。在生产环境中，仍然需要将 Flask 部署到一个高性能的 WSGI Server 中，比如 uWSGI。

三级结构

在三级结构中：

  • uWSGI Server 作为中间件，它基于 WSGI 协议与 Nginx 通信，同时与实现了 WSGI 协议的 WSGI Application（比如一个 Flask Application）进行通信

当有客户端发来请求，Nginx 先做处理静态资源（静态资源是 Nginx 的强项），无法处理的动态请求以 WSGI 协议的格式转发给 WSGI Application（比如一个 Flask Application）。

这里，我们多了一层反向代理有什么好处？

  • 提高 Web server 性能（uWSGI 处理静态资源不如 nginx）nginx 会在收到一个完整的 http 请求后再转发给 wWSGI)
  • Nginx 可以做负载均衡（客户端是和 Nginx 交互而不是 uWSGI），以提升高可用
more >>

Show More >>

【HTTP】Web Server（Web 服务器）、Web Application Server（Web 应用服务器）和 CGI（Common Gateway Interface）的故事

Web Server（Web 服务器）

在网络刚刚盛行的年代（Web 1.0），绝大部分的 Web 资源都是静态的。这意味着，你访问 www.example.com/a.html，你就可以访问 a 页面，而如果访问 www.example.com/b.html，你就可以访问 b 页面。显然，信息量是单向的，即网站上有什么，你就只能看什么，而不能修改网站的内容。我们通常把它称为静态网站。

狭义的 Web Server（Web 服务器）概念中，Web Server 只能处理静态页面。

典型的 Web Server 的例子，就是 Apache HTTP Server，Nginx 还有 LightHttpd。

随着互联网的发展，我们更希望访问一个动态网站（Web 1.5），即可以根据用户传入的信息，动态地生成网页的内容。

这时候，我们就需要一个程序来帮忙处理动态请求（如返回特定用户的信息、获取当前时间等），而静态资源的请求，依然由 Web Server 来负责。

Web 服务器程序会将动态请求转发给帮助程序（helper application），帮助程序处理后，返回处理后的静态结果给 Web 服务器程序。这样，就避免了 Web 服务器程序需要处理动态页面的问题，如下图：

image-20191028175219296

more >>

Show More >>

【Python】WSGI（Web Server Gateway Interface）、uWSGI Server、uwsgi、WSGI Application 的故事

关于 Web Server（Web 服务器）、Web Application Server（Web 应用服务器）和 CGI（Common Gateway Interface）的区别，可以访问【HTTP】Web Server（Web 服务器）、Web Application Server（Web 应用服务器）和 CGI（Common Gateway Interface）的故事 。

WSGI（Web Server Gateway Interface）

WSGI 是 Web Server Gateway Interface 的缩写。

它不是服务器、Python 模块、框架、API 或者任何软件，而是一种描述 Web 服务器（如 nginx，uWSGI 等服务器）如何与 Web application（Web 应用程序，如用 Django、Flask 框架编写的程序）通信的规范。

因此，WSGI 是一种规范，或者说一种接口，或者说一种协议。

WSGI 是在 PEP 333 提出的，并在 PEP 3333 进行补充（主要是为了支持 Python3.x）。

这个协议旨在解决众多 Python Web 框架和 Web server 软件的兼容问题。有了 WSGI，你不用再因为你使用特定的 Web 应用框架而不得不选择特定的 Web server 软件。

只要遵照了 WSGI 协议的的 Web 应用（Web application，我们称之为 WSGI 应用），都可以在任何遵照了 WSGI 协议的 Web server 软件（我们称之为 WSGI server，比如 uWSGI）上运行。

常用的 WSGI server（WSGI 服务器）软件：wsgiref，uWSGI，Gunicorn 等

而对于 WSGI 应用（WSGI Application），我们理论上可以完全自己从头编写一个 WSGI 应用，但是，我们通常会使用 WSGI 应用框架（WSGI Application Framework），或者称为 WSGI MiddleWare，比如 Django，Flask 等，因为框架已经帮我们封装了大量的底层逻辑，而让我们可以更好的专注于业务逻辑上。

为了更好的理解 WSGI 应用（WSGI Application），我们接下来会写一个非常原始的 WSGI 应用。

more >>

Show More >>

【Python】Error Handling

Error Return

If service can not handle request for internal error or upstream error, it should response proper error information to client.

Service should write log for every error return.

The error response structure should be consistent for all APIs in one service.

  • The error code should be either a short string code or an integer, defined by service. This is to help client understand the situation and choose different ways to handle the error.
  • The detailed error message is optional. This is to help client debug the issue.
  • The error code need to be categorized to 2 types, and allow client side easily identify the type of error.
    • Occasional error, such as upstream down, internal error, etc. This kind of errors means client can safely retry the request.
    • Logic error, such as invalid argument. Client can cached the result and should not directly retry the request.
more >>

Show More >>