空间数据

在多任务操作系统中的每一个进程都运行在一个属于它自己的内存沙盘中。这个沙盘就是虚拟地址空间（virtual address space）。 1 32位虚拟内存布局 在32位模式下虚拟地址空间总是一个4GB的内存地址块。这些虚拟地址通过页表（page table）映射到物理内存，页表由操作系统维护并被处理器引用。每一个进程拥有一套属于它自己的页表，但是还有一个隐情。只要虚拟地址被使用，那么它就会作用于这台机器上运行的所有软件，包括内核本身。因此一部分虚拟地址必须保留给内核使用： 图 1 这并不意味着内核使用了那么多的物理内存，仅表示它可支配这么大的地址空间，可根据内核需要，将其映射到物理内存。内核空间在页表中拥有较高的 特权级 （ring 2或以下），因此只要用户态的程序试图访问这些页，就会导致一个页错误（page fault），用户程序不可访问内核页。在Linux中，内核空间是持续存在的，并且在所有进程中都映射到同样的物理内存。内核代码和数据总是可寻址的，随时准备处理中断和系统调用。与此相反，用户模式地址空间的映射随进程切换的发生而不断变化： 图 2 图2中，蓝色区域表示映射到物理内存的虚拟地址，而白色区域表示未映射的部分。在上面的例子中，Firefox使用了相当多的虚拟地址空间，因为它是传说中的吃内存大户。地址空间中的各个条带对应于不同的内存段（memory segment），如

OC: struct Class 不同点 值类型 Value Type 引用类型 reference type 结构体只能封装数据 而类可以封装数据，还可以封装行为（实现函数） 结构体变量分配在栈空间 而对象分配在堆空间 赋值为拷贝 类是指向地址 没有继承 有继承 相同点 都可以将多个数据封装为1个整体 都可以将多个数据封装为1个整体 struct dataStruct{ NSInteger age; NSInteger year; __unsafe_unretained NSString *name;//1.在`ARC`环境下，在结构体中使用`objc`对象，必须使用 `__unsafe_unretained`，这个是苹果的规定。否则会报错：ARC forbids Objective-C objects in struct // NSDictionary *data;// 2.或者指定单独 }; [@interface](https://my.oschina.net/u/996807) ClassAndStruct() { NSInteger age; NSInteger year; NSString *name; NSDictionary *data; } [@end](https://my.oschina.net/u/567204) swift struct Class

1. 常见概念 在合理应用缓存前，需要了解缓存领域里相关的几个常用术语： 　1）缓存命中：表示数据能够从缓存中获取，不需要回源； 　2）Cache miss：表示没有命中缓存，如果缓存内存中还有内存空间的话，会将数据加入到缓存中； 　3）存储成本：当没有命中缓存时，回源获取后会将数据放置到存储中，整个将数据放置到存储空间所需要的时间以及空间称之为存储成本； 　4）缓存失效：当源数据发生变更后，意味着缓存中的数据失效； 　5）缓存污染：将不经常访问的数据放置到缓存存储空间中，以至于高频访问的数据无法放置到缓存中； 　6）替代策略：当数据放置到缓存空间时，由于空间不足时，就需要从缓存空间中去除已有的数据，选择去除哪些数据就是由替代策略决定的。常见的替代策略有如下这些： Least-Recently-Used（LRU） Least-Frequently-Used（LFU） SIZE First in First Out（FIFO） 　　由于存储空间有限，替代策略要解决的核心问题是尽量保留高频访问的缓存数据，降低缓存污染以提升缓存命中率和整体的缓存效率，难点在于，需要基于数据历史访问情况，以一种合适的对未来访问情况的预估才能找到更佳的策略。 2. 访问缓存场景 分析 　　使用缓存通常的操作是，请求先访问缓存数据，如果缓存中不存在的话，就会回源到数据库中然后将数据写入到缓存中

面对千亿量级的小文件，存储系统压力山大 所谓小文件，指的是存储占用空间相对较小的文件，一般来说低于64MB的文件就可以被认定为小文件，而大量的小文件大小则在几KB到几十KB之间。在云计算、大数据业务中，文本、图片、音乐等是典型的小文件应用场景。 随着数字化创新的加速，组织内部的数据呈现出指数级增长的趋势，特别是小文件更是随着业务增长到一个巨大的量级。与大文件的存储不同的是，大量磁盘在小文件存储场景中的性能极低，单块企业级SATA磁盘如果全部存储4KB左右的小文件，带宽只有520KB/s，远远小于应有的120MB/s的带宽标准值，很容易因为存储系统的性能不足造成上层应用“卡顿”。把磁盘全部换成固态盘固然可以解决问题，但是，固态盘的价格数倍于SATA磁盘，对于很多用户来说，全面的应用固态盘在成本上仍然不现实。 百亿~万亿量级的小文件对存储性能提出 而且，每个应用场景对于存储系统的性能往往有着不同的要求。例如，某领先电商平台已经存储了数量以百亿计算的图片文件，这些图片平均大小在15KB左右，用户对于这些图片文件的读取完全是随机读取，一旦大量用户同时在线访问网址或者搜索商品，往往就会给存储系统的随机读写能力带来巨大的挑战；在交警系统中，路口的抓拍摄像头会将违章图片传送至区中心的计算服务器，不仅摄像头数量多，而且每台摄像头每天都可能生成数千乃至上万张照片，某市每天相关图片写入甚至超过一亿张

面对千亿量级的小文件，存储系统压力山大 所谓小文件，指的是存储占用空间相对较小的文件，一般来说低于64MB的文件就可以被认定为小文件，而大量的小文件大小则在几KB到几十KB之间。在云计算、大数据业务中，文本、图片、音乐等是典型的小文件应用场景。 随着数字化创新的加速，组织内部的数据呈现出指数级增长的趋势，特别是小文件更是随着业务增长到一个巨大的量级。与大文件的存储不同的是，大量磁盘在小文件存储场景中的性能极低，单块企业级SATA磁盘如果全部存储4KB左右的小文件，带宽只有520KB/s，远远小于应有的120MB/s的带宽标准值，很容易因为存储系统的性能不足造成上层应用“卡顿”。把磁盘全部换成固态盘固然可以解决问题，但是，固态盘的价格数倍于SATA磁盘，对于很多用户来说，全面的应用固态盘在成本上仍然不现实。 百亿~万亿量级的小文件对存储性能提出 而且，每个应用场景对于存储系统的性能往往有着不同的要求。例如，某领先电商平台已经存储了数量以百亿计算的图片文件，这些图片平均大小在15KB左右，用户对于这些图片文件的读取完全是随机读取，一旦大量用户同时在线访问网址或者搜索商品，往往就会给存储系统的随机读写能力带来巨大的挑战；在交警系统中，路口的抓拍摄像头会将违章图片传送至区中心的计算服务器，不仅摄像头数量多，而且每台摄像头每天都可能生成数千乃至上万张照片，某市每天相关图片写入甚至超过一亿张

面对千亿量级的小文件，存储系统压力山大 所谓小文件，指的是存储占用空间相对较小的文件，一般来说低于64MB的文件就可以被认定为小文件，而大量的小文件大小则在几KB到几十KB之间。在云计算、大数据业务中，文本、图片、音乐等是典型的小文件应用场景。 随着数字化创新的加速，组织内部的数据呈现出指数级增长的趋势，特别是小文件更是随着业务增长到一个巨大的量级。与大文件的存储不同的是，大量磁盘在小文件存储场景中的性能极低，单块企业级SATA磁盘如果全部存储4KB左右的小文件，带宽只有520KB/s，远远小于应有的120MB/s的带宽标准值，很容易因为存储系统的性能不足造成上层应用“卡顿”。把磁盘全部换成固态盘固然可以解决问题，但是，固态盘的价格数倍于SATA磁盘，对于很多用户来说，全面的应用固态盘在成本上仍然不现实。 百亿~万亿量级的小文件对存储性能提出 而且，每个应用场景对于存储系统的性能往往有着不同的要求。例如，某领先电商平台已经存储了数量以百亿计算的图片文件，这些图片平均大小在15KB左右，用户对于这些图片文件的读取完全是随机读取，一旦大量用户同时在线访问网址或者搜索商品，往往就会给存储系统的随机读写能力带来巨大的挑战；在交警系统中，路口的抓拍摄像头会将违章图片传送至区中心的计算服务器，不仅摄像头数量多，而且每台摄像头每天都可能生成数千乃至上万张照片，某市每天相关图片写入甚至超过一亿张

修改一个字段类型时，报的这个错。 此时需要增加次要数据文件 次要数据文件 次要数据文件包含除主要数据文件外的所有数据文件。有些数据库可能没有次要数据文件，而有些数据库则有多个次要数据文件。次要数据文件的推荐文件扩展名是 .ndf。 以下解决方法来自网上，稍加整理和修改。 解决办法： 1.检查磁盘剩余空间是否足够,如果没有磁盘剩余空间,则清理磁盘,腾出空间。 2.检查磁盘分区格式：如果是FAT16,则数据文件最大只能是2G，如果是FAT32,则数据文件最大只能是4G，改为NTFS分区则没有这种限制。 3.检查一下你有没有限制数据库文件的大小： 企业管理器--右键你的数据库--属性--文件增长限制--如果有限制大小,取消限制。 4.检查你的SQL版本,如果你用MSDE,则限制了数据文件最大是2G。 以上四项，如果使用的默认配置，基本上不会有变化，主要的解决方法是第5项 5.为 primary 组添加次要数据文件ndf alter database 库名 add file(NAME = 逻辑文件名,FILENAME = 文件路径)。 或企业管理器-->数据库属性-->添加，填上文件名，一般用mdf的文件名就好，扩展名是ndf 来源： https://www.cnblogs.com/Sabre/p/12008661.html

在实际的工作环境下，许多人会遇到海量数据这个复杂而艰巨的问题，它的主要难点有以下几个方面： 一、数据量过大，数据中什么情况都可能存在。 如果说有10条数据，那么大不了每条去逐一检查，人为处理，如果有上百条数据，也可以考虑，如果数据上到千万级别，甚至 过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可能存在，例如，数据中某处格式出了问题，尤其在程序处理时， 前面还能正常处理，突然到了某个地方问题出现了，程序终止了。 二、软硬件要求高，系统资源占用率高。 对海量的数据进行处理，除了好的方法，最重要的就是合理使用工具，合理分配系统资源。一般情况，如果处理的数据过TB级，小型机是要考虑的，普通的机子如果有好的方法可以考虑，不过也必须加大CPU和内存，就象面对着千军万马，光有勇气没有一兵一卒是很难取胜的。 三、要求很高的处理方法和技巧。 这也是本文的写作目的所在，好的处理方法是一位工程师长期工作经验的积累，也是个人的经验的总结。没有通用的处理方法，但有通用的原理和规则。 下面我们来详细介绍一下处理海量数据的经验和技巧： 一、选用优秀的数据库工具 现在的数据库工具厂家比较多，对海量数据的处理对所使用的数据库工具要求比较高，一般使用Oracle或者DB2，微软 公司最近发布的SQL Server 2005性能也不错。另外在BI领域：数据库，数据仓库

海量信息即大规模数据，随着互联网技术的发展，互联网上的信息越来越多，如何从海量信息中提取有用信息成为当前互联网技术发展必须面对的问题。 在海量数据中提取信息，不同于常规量级数据中提取信息，在海量信息中提取有用数据，会存在以下几个方面的问题： （1）数据量过大，数据中什么情况都可能存在，如果信息数量只有20条，人工可以逐条进行查找、比对，可是当数据规模扩展到上百条、数千条、数亿条，甚至更多时，仅仅只通过手工已经无法解决存在的问题，必须通过工具或者程序进行处理。 （2）对海量数据信息处理，还需要有良好的软硬件配置，合理使用工具，合理分配系统资源。通常情况下，如果需要处理的数据量非常大，超过了TB级，小型机、大型工作站是要考虑的，普通计算机如果有好的方法也可以考虑，如通过联机做成工作集群。 （3）对海量信息处理时，要求很高的处理方法和技巧，如何进行数据挖掘算法的设计以及如何进行数据的存储访问等都是研究的难点。 针对海量数据的处理，可以使用的方法非常多，常见的方法有Hash法、Bit-map法、Bloom filter法、数据库优化法、倒排索引法、外排序法、Trie树、堆、双层桶法以及MapReduce法。 Hash法 哈希函数的特点 哈希函数的构建方法 解决冲突的方法 Bit-map法 Bloom filter法 数据库优化法 倒排索引法 外排序法 Trie树 堆 双层桶法

1.理解global对象 global对象是作为 window 对象的一部分实现的，我们无法通过代码访问到 global 对象。 我们平时在全局环境下定义的内容（变量，函数，常量等等）都是作为 global 对象的属性存在的（都属于 global 对象） 2.基本类型（原始类型）数据的存储方式 变量在存储原始类型的数据时， 直接将数据存储到变量的内存空间中 ， 当我们将存储数据的变量赋值给另一个变量时，其实是将变量存储的 数据复制 了一份保存到另一个变量的内存空间中， 因为每个变量都是使用自己独立的存储空间保存原始类型的数据，因此我们改变其中一个变量空间中的数据时，不会影响到另一个变量 1 <body> 2 <script> 3 4 /* 5 变量在存储原始类型的数据时，直接将数据存储到变量的内容空间中。 6 */ 7 8 var color1 = 'red'; 9 10 /* 11 当我们将存储原始数据的变量赋值给另一个变量时，其实是将变量存储的数据复制了一份保存到了另一个变量的内存空间中。 12 */ 13 var color2 = color1; 14 15 /* 16 因为每个变量都是使用自己独立的存储空间保存原始类型的数据，因此我们改变其中一个变量空间中的数据时，不会影响到另一个变量。 17 */ 18 color1 = 'green'; 19 20 console