信息存储

SqlServer索引的原理与应用 索引的概念 索引的用途：我们对数据查询及处理速度已成为衡量应用系统成败的标准，而采用索引来加快数据处理速度通常是最普遍采用的优化方法。 索引是什么：数据库中的索引类似于一本书的目录，在一本书中使用目录可以快速找到你想要的信息，而不需要读完全书。在数据库中，数据库程序使用索 引可以重啊到表中的数据，而不必扫描整个表。书中的目录是一个字词以及各字词所在的页码列表，数据库中的索引是表中的值以及各值存储位置的列表。 索引的利弊：查询执行的大部分开销是I/O，使用索引提高性能的一个主要目标是避免全表扫描，因为全表扫描需要从磁盘上读取表的每一个数据页，如果有 索引指向数据值，则查询只需要读少数次的磁盘就行啦。所以合理的使用索引能加速数据的查询。但是索引并不总是提高系统的性能，带索引的表需要在数 据库中占用更多的存储空间，同样用来增删数据的命令运行时间以及维护索引所需的处理时间会更长。所以我们要合理使用索引，及时更新去除次优索引。 数据表的基本结构 一个新表被创建之时，系统将在磁盘中分配一段以8K为单位的连续空间，当字段的值从内存写入磁盘时，就在这一既定空间随机保存，当一个 8K用完的时候，数据库指针会自动分配一个8K的空间。这里，每个8K空间被称为一个数据页（Page），又名页面或数据页面，并分配从0-7的页号, 每个文件的第0页记录引导信息，叫文件头

目录 引言 HDFS 数据块的设计 数据块应该设置成多大？ 抽象成数据块有哪些好处？ 操作块信息的命令 HDFS 中节点的设计 有几种节点类型？ 用户如何访问 HDFS？ 如何对 namenode 容错？ 如何更快的访问 datanode 中访问频繁的块？ 如何扩展 namenode 以存储更多的文件？ HDFS 中的高可用性设计 如何处理 namenode 单点失效问题？ namenode 间如何共享编辑日志？ namenode 如何能快速故障切换？ 如何规避非平稳故障转移？ 小结 参考文档 珍惜时间，时间要花在做有用的事情上，力戒无意义的举动 ——富兰克林 引言 当数据的大小大于一台独立的电脑的存储能力时，就有必要对它进行分区并且存储在多台单独的电脑上。要将非常大的数据集合存储在多台电脑上，就会涉及到多台电脑共享的文件系统，也就是分布式文件系统。 分布式文件系统(distributed file system) 是指管理网络中跨多台计算机存储的文件系统。 分布式文件系统既然跨多台电脑，通过网络将它们互联起来，就可能会出现其中的一个电脑节点连接中断或者宕机的情况，也就是节点故障。在这种情况下也不能出现丢失整个文件系统任何数据的情况，怎么来做到呢？先让我们用发散思维的方式来思考一下。 将文件系统的每份数据备份，并且备份不能在同一台物理计算器上，这样能保证即使其中一台计算机宕机

1. MySQL 优化 - 查看执行记录 MySQL 提供了一个 EXPLAIN 命令 , 它可以 对 SELECT 语句进行分析 , 并输出 SELECT 执行的详细信息 , 以供开发人员针对性优化。 使用 explain 这个命令来查看一个这些 SQL 语句的执行计划，查看该 SQL 语句有没有使用上了索引，有没有做全表扫描，这都可以通过 explain 命令来查看。 EXPLAIN 命令用法十分简单 , 在 SELECT 语句前加上 explain 就可以了 , 例如 : 1.1 SQL 语句优化 -explain 分析问题 expain 出来的信息有 10 列，分别是 id 、 select_type 、 table 、 type 、 possible_keys 、 key 、 key_len 、 ref 、 rows 、 Extra , 下面对这些字段进行解释： id: select 查询的标识符 . 每个 select 都会自动分配一个唯一的标识符 . select_type: 表示查询的类型。 table: 输出结果集的表 type: 表示表的连接类型 possible_keys: 表示查询时，可能使用的索引 key: 表示实际使用的索引 key_len: 索引字段的长度 ref: 哪个字段或常数与 key 一起被使用 rows: 扫描出的行数 ( 估算的行数 )

一 字符串类型 字符串数据类型还可以依据存储空间分为固定长度类型（CHAR/NCHAR) 和可变长度类型（VARCHAR2/NVARCHAR2)两种. 所谓固定长度：是指虽然输入的字段值小于该字段的限制长度，但是实际存储数据时，会先自动向右补足空格后，才将字段值的内容存储到数据块中。这种方式虽然比较浪费空间，但是存储效率较可变长度类型要好。同时还能减少数据行迁移情况发生。 所谓可变长度：是指当输入的字段值小于该字段的限制长度时，直接将字段值的内容存储到数据块中，而不会补上空白，这样可以节省数据块空间。 1.1：CHAR类型 CHAR(size [BYTE | CHAR]) CHAR类型，定长字符串，会用空格填充来达到其最大长度。非NULL的CHAR（12）总是包含12字节信息。CHAR字段最多可以存储2,000字节的信息。如果创建表时，不指定CHAR长度，则默认为1。另外你可以指定它存储字节或字符，例如 CHAR(12 BYTYE) CHAR(12 CHAR).一般来说默认是存储字节，你可以查看数据库参数 NLS_LENGTH_SEMANTICS的值。 SQL Code SQL> show parameter nls_length_semantics; NAME TYPE VALUE ------------------ ----------- -----------------

前言 随着Web应用程序出现以来，人们对与能够直接在客户端上存储信息能力的要求始终没有停止过。应用开发人员在找各种方式将数据存储在客户端上。从刚开始的Cookie存储方案，到现在的Web Storage和indexedDB，本文将主要介绍这三种浏览器存储方式优缺点。 Cookie 1、Cookie是什么？ HTTP Cookie ，通常直接叫做 cookie ，起初是在客户端用于存储会话信息的。该标准要求服务器对 任意 HTTP 请求发送 Set-Cookie 而 HTTP 头作为响应的一部分，其中包含会话信息。例如，这种服务器响 应的头可能如下： HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value Other-header: other-header-value 这个 HTTP 响应设置以 name 为名称、以 value 为值的一个 cookie ，名称和值在传送时都必须是 URL 编码的。浏览器会存储这样的会话信息，并在这之后，通过为每个请求添加 Cookie , HTTP 头将信 息发送回服务器，如下所示： GET /index.html HTTP/1.1 Cookie: name=value Other-header: other-header-value

HDFS体系结构简介及优缺点 1.1体系结构简介 HDFS是一个主/从（Mater/Slave）体系结构，从最终用户的角度来看，它就像传统的文件系统一样，可以通过目录路径对文件执行CRUD（Create、Read、Update和Delete）操作。但由于分布式存储的性质，HDFS集群拥有一个NameNode和一些DataNode。NameNode管理文件系统的元数据，DataNode存储实际的数据。客户端通过同NameNode和DataNodes的交互访问文件系统。客户端联系NameNode以获取文件的元数据，而真正的文件I/O操作是直接和DataNode进行交互的。 下图为HDFS总体结构示意图 1.1.1 NameNode NameNode可以看作是分布式文件系统中的管理者，主要负责管理文件系统的命名空间、集群配置信息和存储块的复制等。NameNode会将文件系统的Meta-data存储在内存中，这些信息主要包括了文件信息、每一个文件对应的文件块的信息和每一个文件块在DataNode的信息等。l Masterl 管理HDFS的名称空间l 管理数据块映射信息l 配置副本策略l 处理客户端读写请求 1.1.2 Secondary namenode 并非NameNode的热备； 辅助NameNode，分担其工作量； 定期合并fsimage和fsedits，推送给NameNode；

1. MySQL 架构 1.1 逻辑架构图 1.1.1 Connection Pool: 连接池 * 管理缓冲 用户连接 ， 线程处理 等需要缓存的需求。 * 负责监听对 MySQL Server 的各种请求，接收连接请求，转发所有连接请求到 线程管理模块 。每一个连接上 MySQL Server 的客户端请求都会被分配（或创建）一个连接线程为其单独服务。 * 而 连接线程 的主要工作就是负责 MySQL Server 与客户端的通信，接受客户端的命令请求，传递 Server 端的结果信息等。线程管理模块则负责管理维护这些连接线程。包括线程的创建，线程的 cache 等。 1.1.2 Parser: 解析器 * SQL 命令传递到解析器的时候会被解析器 验证和解析 。 主要功能： a . 将 SQL 语句进行 语义和语法的分析，分解成数据结构 ，然后按照 不同的操作类型进行分类， 然后做出针对性的转发到后续步骤，以后 SQL 语句的传递和处理就是基于这个结构的。 b. 如果在分解构成中遇到错误，那么就说明这个 sql 语句是不合理的 1.1.3 Optimizer: 查询优化器 * SQL 语句在查询之前会 使用查询优化器对查询进行优化 。 * 它使用的是“ 选取 - 投影 - 联接 ”策略进行查询。 用一个例子就可以理解： select uid,name from user

一、什么是session？ 　　最近在学习node.js 的express框架，接触到了关于session方面的内容。翻阅了一些的博客，学到了不少东西，发现一篇博文讲的很好，概念内容摘抄如下： Session是什么 Session一般译作会话，牛津词典对其的解释是进行某活动连续的一段时间。从不同的层面看待session，它有着类似但不全然相同的含义。比如，在web应用的用户看来，他打开浏览器访问一个电子商务网站，登录、并完成购物直到关闭浏览器，这是一个会话。而在web应用的开发者开来，用户登录时我需要创建一个数据结构以存储用户的登录信息，这个结构也叫做session。因此在谈论session的时候要注意上下文环境。而本文谈论的是一种基于HTTP协议的用以增强web应用能力的机制或者说一种方案，它不是单指某种特定的动态页面技术，而这种能力就是保持状态，也可以称作保持会话。 为什么需要session 谈及session一般是在web应用的背景之下，我们知道web应用是基于HTTP协议的，而HTTP协议恰恰是一种无状态协议。也就是说，用户从A页面跳转到B页面会重新发送一次HTTP请求，而服务端在返回响应的时候是无法获知该用户在请求B页面之前做了什么的。 对于HTTP的无状态性的原因，相关RFC里并没有解释，但联系到HTTP的历史以及应用场景，我们可以推测出一些理由： 1.

本文源码： GitHub·点这里 || GitEE·点这里 一、数据场景 1、表结构简介 任何工具类的东西都是为了解决某个场景下的问题，比如Redis缓存系统热点数据，ClickHouse解决海量数据的实时分析，MySQL关系型数据库存储结构化数据。数据的存储则需要设计对应的表结构，清楚的表结构，有助于快速开发业务，和理解系统。表结构的设计通常从下面几个方面考虑：业务场景、设计规范、表结构、字段属性、数据管理。 2、用户场景 例如存储用户基础信息数据，通常都会下面几个相关表结构：用户信息表、单点登录表、状态管理表、支付账户表等。 用户信息表 存储用户三要素相关信息：姓名，手机号，身份证，登录密码，邮箱等。 CREATE TABLE `ms_user_center` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户ID', `user_name` varchar(20) NOT NULL COMMENT '用户名', `real_name` varchar(20) DEFAULT NULL COMMENT '真实姓名', `pass_word` varchar(32) NOT NULL COMMENT '密码', `phone` varchar(20) NOT NULL COMMENT '手机号', `email` varchar

第一章、部署dashboard 作为Kubernetes的Web用户界面，用户可以通过Dashboard在Kubernetes集群中部署容器化的应用，对应用进行问题处理和管理，并对集群本身进行管理。通过Dashboard，用户可以查看集群中应用的运行情况，同时也能够基于Dashboard创建或修改部署、任务、服务等Kubernetes的资源。通过部署向导，用户能够对部署进行扩缩容，进行滚动更新、重启Pod和部署新应用。 项目地址： https://github.com/kubernetes/dashboard ，根据项目中的介绍，我们自己在线安装即可，但是实际上我们国内用户无法自己安装，需要下载后修改文件才能使用 下载yaml文件 [root@k8s-master01 manifests]# mkdir dashboard^C [root@k8s-master01 manifests]# cd dashboard/ [root@k8s-master01 dashboard]# wget https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml 修改yaml文件中镜像的地址及service的类型 修改完成后