文章目录
- 1 一致性哈希
- 2 No SQL与New SQL存储系统
- 3 存储技术选择
1 一致性哈希
一致性hash是首先计算四个ip地址对应的hash值hash(ip1),hash(ip2),hash(ip3),hash(ip3)，计算出来的hash值是0~最大正整数直接的一个值，这四个值在一致性hash环上呈现如下图：
user1、user2的请求会落到服务器ip2进行处理，user3的请求会落到服务器ip3进行处理、user4的请求会落到服务器ip4进行处理，user5、user6的请求会落到服务器ip1进行处理。
下面考虑当ip2的服务器挂了的时候会出现什么情况：
根据顺时针规则可知user1,user2的请求会被服务器ip3进行处理，而其它用户的请求对应的处理服务器不变，也就是只有之前被ip2处理的一部分用户的映射关系被破坏了，并且其负责处理的请求被顺时针下一个节点委托处理。
下面考虑当新增机器的时候会出现什么情况 ：
根据顺时针规则可知之前user1的请求应该被ip1服务器处理，现在被新增的ip5服务器处理，其他 用户的请求处理服务器不变，也就是新增的服务器顺时针最近的服务器的一部分请求会被新增的服务器 所替代。
一致性哈希特征 • 单调性(Monotonicity) • 分散性(Spread) • 平衡性(Balance)
2 No SQL与New SQL存储系统
通常，NoSQL数据库具有以下几个特点：
（1）灵活的可扩展性 （2）灵活的数据模型 （3）与云计算紧密融合
• 是关系型数据库的补充，而不是取代者
键-值（Key-Value）数据库
这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据，这类数据库对于IT系统来说的优势在于简单、易部署。
如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB。
列存储数据库
这部分数据库通常是用来应对分布式存储的海量数据，键仍然存在，但是它们的特点是指向了多个列，这些列是由列家族来安排的。
如：Cassandra, HBase, Riak
文档型数据库 文档型数据库的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档 型数据库可以看作是键值数据库的升级版，允许之间嵌套键值，而且文档型数据库比键值数据库的查询 效率更高。 如：CouchDB, MongoDB，国内也有文档型数据库SequoiaDB。
图形（Graph）数据库 图形结构的数据库使用灵活的图形模型，并且能够扩展到多个服务器上。 如：Neo4J, InfoGrid, Infinite Graph
REmote DIctionary Server (Redis) 是一个简单性与复杂性并存的键-值存储系统，为具有原子更新能力的高层数据结构提供服务器端支持。
Redis的外围由一个键、值映射的字典构成，值的类型不仅限于字符串，支持以下抽象数据类型：
• 字符串列表
• 无序不重复的字符串集合
• 有序不重复的字符串集合
• 键、值都为字符串的哈希表
同时，还包括了键的过期功能以及发布-订阅机制，后者可以用作（例如实时流处理系统和前端之间）消息总线。
Redis优势
•性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
• 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
• 原子 – Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。
• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。
Redis 与其他 key - value 缓存产品有以下三个特点：
• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
• Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
• Redis支持数据的备份，即master-slave模式的数据备份。
Redis 应用场景
•数据缓存 — 提高访问性能
• 会话缓存 — 保存web会话信息
• 排行磅/计算器 — NGINX+lua+redis计数器进行IP自动封禁
• 消息队列 — 构建实时消息系统，聊天，群聊
Redis 键（Keys）
Redis 键命令用于管理 redis 的键。Redis 键命令的基本语法如下：
redis 127.0.0.1:6379> COMMAND KEY_NAME
实例：
redis 127.0.0.1:6379> SET runoobkey redis
OK
redis 127.0.0.1:6379> DEL runoobkey
(integer) 1
3 存储技术选择
键-值存储
如果事先知道聚集结构，Redis等键-值持久存储的效果最好。通常来说，这些存储系统也青睐简 单查询，因为查询完全是由客户端来管理的。这使得它们最适合交互有限的应用，例如仪表板应用。
应用场景：GitHub (Riak)、BestBuy (Riak)、Twitter (Redis和Memcached)、StackOverFlow (Redis)、 Instagram (Redis)、Youtube (Memcached)、Wikipedia (Memcached)
文档存储
根据文档存储的设计特点，当有大量度量值要以自然分组的形式存储时，文档存储是最佳选择。 如果查询模式是将文档提取到工作集合，而工作集合本质上是将文档“预热”，从而为后续查询提供更 快的访问速度，那么使用文档存储的效果也会很好。
应用场景： SAP (MongoDB)、Codecademy (MongoDB)、Foursquare (MongoDB)、NBC News (RavenDB)
分布式哈希存储
Cassandra、Voldemort、BigTable 和DynamoDB 是关系数据库与键-值存储的“混血儿”。类 似于键-值存储，当聚集模式已知，从而可以由流处理基础架构进行非规范化处理时，这类存储的性能 最好。
与键-值存储不同的是，它们通常提供高效的范围查询或集合查询，通常还支持二级索引以提高查 询性能。
与关系数据库不同的是，这类存储对ad hoc聚集计算的支持通常不是很好，它们通常不支持 GROUP BY和SUM操作，这都需要客户端进行聚集计算。
关系数据库
关系数据库适用于ad hoc聚集计算和查询，对于列数据库则更是如此，因为列数据库有专门的索 引和存储机制来优化许多特有的聚集查询。
关系数据库中的“实时”通常指的是，处理数据流时有几分钟或几小时的延迟，而不是几毫秒， 在这种数据摄取速度非常快的情况下，关系数据库表现不佳
云数据库
云数据库是指被优化或部署到一个虚拟计算 环境中的数据库，可以实现按需付费、按需扩展、 高可用性以及存储整合等优势。
云数据库的特性有：实例创建快速、支持只 读实例、故障自动切换、数据备份、Binlog备份、 访问白名单、监控与消息通知。
如 ： 阿 里 云 数 据 库 RDS 、 阿 里 云 数 据 库 MangoDB版、亚马逊关系型数据库服务、亚马逊 Redshift、亚马逊DynamoDB等
将Hadoop作为ETL和数据仓库
从Kafka中摄取数据
Kafka为Hadoop提供了非常简单的数据摄取机制。 LinkedIn使用Camus工具执行从Kafka到Hadoop的数据摄取，默认情况下，Camus假定要处理 的数据大体遵从LinkedIn自己的内部数据格式，该格式是基于Avro的。
Flume支持将Hadoop分布式文件系统（Hadoop Distributed File System，HDFS）的数据摄取 作为它的一个sink。
事件与处理时间
在Kafka与Flume摄取数据的过程中，当发生错误时，导入时间是问题的关键。如果处理流水线中 断，导入时间（而不是数据的生成时间）就确定了应该处理哪些数据。而对于多数恢复和维护场景来说 ，事件的时间无关紧要，对于要查看历史数据的用户来说，可以让查看过程更容易。
ETL过程中使用Hadoop
对于Hadoop中的ETL流水线有许多选择。其中比较流行的是Pig和Hive。前者是Hadoop的脚本 语言，由Yahoo！开发，可以用于ETL处理。后者是Hadoop的Map-Reduce框架的类SQL接口，它是 数据库开发人员的主流选择。
另外一个更通用的选择是Sqoop，这是一个Apache项目，用于在Hadoop和其他数据存储之间进 行批量传输。该项目的软件包中包含一个服务器，负责管理用于批量输入和输出的Hadoop作业，它由 单独的客户端进程控制。
Lambda架构中，实时系统像以前一样更新其数据存储，而不考虑事务，主要优势：无需管理服务 器、持续扩展、次秒级计量。
Lambda架构的主要思想就是将大数据系统构建为多个层次：Batch Layer，Speed Layer和 Serving Layer。
数据流进入系统后，同时发往Batch Layer和Speed Layer处理。Batch Layer以不可变模型离线存 储所有数据集，通过在全体数据集上不断重新计算构建查询所对应的Batch Views。Speed Layer处理 增量的实时数据流，不断更新查询所对应的Realtime Views。Serving Layer响应用户的查询请求，合 并Batch View和Realtime View中的结果数据集到最终的数据集
Batch layer：存储数据集，在数据集上预先计算查询函数，构建查询所对应的View。能够很好的 处理离线数据，但有很多场景数据不断实时生成，并且需要实时查询处理
Speed layer：处理增量数据流，不断更新Realtime View
Serving layer：响应用户查询请求，合并Batch View和Realtime View中的结果集到最终的数据 集
