cassandra的缓存
mysql用得最多了，再就PostgreSQL。
2. Uber实时推送平台是如何打造的
原文：Uber’s Real-Time Push Platform
译者：LZM
Uber 建立的出行平台每天在处理全球数以百万计的打车订单。
实时打车市场是一个十分活跃的市场。一次行程包括多个参与者（乘客、司机），他们需要能在 APP 上实时查看、修改当前旅程的状态。因此，Uber 需要保证每个参与者和他们的 APP 实时同步相关信息，无论是接车时间、达到时间还是行驶路线和附近的司机。
今天，手机端呈现的功能日益丰富，而这些功能对实时信息同步的需求也逐渐增多。本文将介绍 Uber 工程团队如何把 Uber 平台信息同步机制从轮询转为基于 gRPC 的双向消息流协议。
在 Uber 后台，一个行程连接了现实世界中的乘客和司机。在行程过程中，这两个实体需要实时更新后台系统的信息。
我们思考一个场景：乘客发出打车请求，而司机在系统上等待接单。Uber 配对系统在后台自动匹配二者，向司机发送订单。到此为止，每一方（乘客、司机、后台）应该彼此同步他们的内容。
如果一个新订单带来，司机 APP 会每隔几秒轮询一次信息以及时更新订单状态。与此同时，乘客 APP 也会每隔几秒轮询一个信息来查看司机时候接单。
轮询的频率由数据改变的速率决定。对于一个大型 APP（例如 Uber APP），这个变化速率从几秒到几个小时不等，变化范围十分宽泛。
80% 的后台 API 请求都是来自客户端的轮询请求。激进的轮询策略能让 APP 的消息保持最新，但也会导致服务器资源耗尽。任何轮询过程中的 bug 都可能频繁导致后台负载显着加剧，甚至崩溃。随着需要动态实时数据的功能的增加，这个方法变得不再可行。
轮询会导致更快的电池消耗、应用程序延迟和网络级拥塞。这在城市中使用 2G/3G 网络或网络不稳定的地方尤其明显。在这些地方，应用程序每次尝试拉取信息时，都会重试多次。
随着功能增加，开发者们尝试重载轮询 API 或重建一个新的 API。在高峰期，APP 同时向多个 API 发送轮询请求。每个 API 负载数个功能。这些轮询 API 本质上成为一组分片负载 API。但是，在 API 级别上保持一致性和逻辑分离仍然是一个越来越大的挑战。
冷启动问题是其中最具挑战性的问题之一。每当 APP 启动，所有功能都希望从后台获取最新状态，以渲染用户界面。这导致多个 API 并发竞争，APP 不能成功渲染出正常界面，直到关键组件的消息被返回。在没有优先级的情况下，因为所有的 API 都有一些关键信息，所以应用加载时间会持续增加。糟糕的网络条件会进一步恶化冷启动问题。
很明显，我们需要一个彻头彻尾的、对消息同步机制的改变。我们开启了建立一个全新的实时推送平台的旅程。在这个平台上，服务器可以根据需要向应用程序发送数据。当我们采用这种新架构时，我们发现效率有显着的改进，同时也解决了不同的问题和挑战。
接下来，来看看我们对推送平台的几代改进以及该平台是如何演变的。
虽然使用消息推送是取代轮询的自然选择，但在如何构建推送机制上有很多需要考虑的问题。四个主要设计原则如下：
1）从轮询到推送的简单迁移
目前存在大量端设备在进行轮询。新系统必须利用现有的、分配给轮询 API 的负载和逻辑，而不是完全推倒重来。
2）简易开发
与开发轮询 API 相比，开发人员在推送数据方面不应该做截然不同的事情。
3）可靠性
所有消息应该通过网络可靠地发送到客户的 APP 上，并在发送失败时重试。
4）高效率
随着 Uber 在发展中国家的迅速发展，数据使用成本对我们的用户来说是一个挑战，对于每天要在 Uber 平台上呆上几个小时的司机来说尤其如此。新协议必须最小化服务器和移动应用程序之间的数据传输量。
我们将这个消息推送系统命名为 RAMEN (Realtime Asynchronous MEssaging Network，实时异步消息网络)。
任何时候，实时信息都在变化。消息的生命周期开始于决定生成一条信息的那一刻。微服务 Fireball 用于决定何时推送消息。很大部分决策都由配置文件决定。Fireball 在系统间监听多种类型的事件，并决定是否推送给该消息涉及的客户。
例如，当一个司机加单，司机和行程的状态都会改变，并触发 Fireball。之后，根据配置文件的内容，Fireball 决定何类消息应该推送给客户。通常，一个触发器会向多个用户发送多个消息。
任何事件都可能被触发器捕获，例如一些客户行为（如发出打车请求、打开 APP）、定时器到期、消息总线上的后端业务事件或是地理上的驶出 / 驶入事件。所有这些触发器都被过滤并转换为对各种后台 API 的调用。这些 API 需要客户的上下文信息，如设备定位、设备的操作系统以及 APP 的版本号，来生成一个响应。Fireball 获取设备上下文 RAMEN 服务器，并在调用 API 时将它们添加到头部。
所有来自 Uber APP 的服务器调用都由我们的 API 网关提供。推送有效负载以同样的方式生成。一旦 Fireball 决定了推送消息的对象和时间，API 网关就负责决定推送什么。网关会调用各类域服务来生成正确的推送负载。
网关中的所有 API 在如何生成有效负载方面是相似的。这些 API 分为拉取式和推送式两种。。拉取式 API 由移动设备调用来执行任何 HTTP 操作。推送 API 由 Fireball 调用，它有一个额外的 “推送” 中间件，可以拦截拉取式 API 的响应，并将其转发给推送消息系统。
将 API 网关介乎于二者之间有以下好处：
l 拉式和推式 API 共享端设备上的大部分业务逻辑。一个给定的负载可以从拉式 API 无缝切换到推式 API。例如，无论你的 APP 是通过拉式 API 调用拉出一个客户对象，还是 Fireball 通过推式 API 调用发送一个客户对象，他们都使用相同的逻辑。
l 网关负责处理大量业务逻辑，如推送消息的速率、路由和消息验证。
在适当的时候，Fireball 和网关一起生成发送给客户的推送消息。负责将这些信息传递到移动设备的是 “推送消息传递系统”。
每条消息推送会根据不同的配置执行，这些配置项包括：
1）优先级
由于为不同的用例生成了数百个不同的消息负载，因此需要对发送到 APP 的内容进行优先排序。我们将在下一节中看到，我们采用的协议限制在单个连接上发送多个并发负载。此外，接收设备的带宽是有限的。为了给人一种相对优先级的感觉，我们将信息大致分为三个不同的优先级：
l 高优先级：核心功能数据
l 中优先级：其他有助于提升客户体验的功能数据
l 低优先级：需要发送的数据规模大且使用频率不高
优先级配置用于管理平台的多种行为。例如，连接建立后，消息按照优先级降序排列在套接字（socket）中。在 RPC 失败的情况下，通过服务器端重试，高优先级消息变得更加可靠，并且支持跨区域复制。
2）存活时间
推送消息是为了改善实时体验。因此，每个消息都有一个预先定义的生存时间，从几秒到半个小时不等。消息传递系统将消息持久化并在发生错误时重试传递消息，直到有效值过期为止。
3）去重复
当通过触发器机制或重传机制多次生成相同的消息时，此配置项确定是否应该删除重复的消息推送。对于我们的大多数用例，发送给定类型的最新推送消息足以满足用户体验，这允许我们降低总体数据传输速率。
消息推送系统的最后一个组件是实际的有效负载交付服务。该服务维持着与世界各地数百万 APP 程序的活跃连接，并在它们到达时将有效信息同步。世界各地的移动网络提供了不同级别的可靠性，因此传输系统需要足够鲁棒以适应故障。我们的系统保证 “至少一次” 交货。
为了保证可靠传输，我们必须基于 TCP 协议，建立从应用程序到数据中心的持久连接。对于 2015 年的一个应用协议，我们的选择是使用带有长轮询、网络套接字或最终服务器发送事件 (SSE) 的 HTTP/1.1。
基于各种考虑，如安全性、移动 SDK 的支持和数据大小的影响，我们决定使用 SSE。Uber 已经支持了 HTTP + JSON API 栈，它的简单性和可操作性使它成为我们当时的选择。
然而，SSE 是一种单向协议，即数据只能从服务器发送到应用程序。为了提供之前提到的 “至少一次” 的保障，需要确认和重传机制以构建到应用程序协议之上的交付协议中。在 SSE 的基础上，我们定义了一个非常优雅和简单的协议方案。
客户端开始接收第一个 HTTP 请求的消息 /ramen/receive?seq=0，在任何新会话开始时序列号为 0。服务器以 HTTP 200 和 “Content-Type: text/event-stream” 响应客户端以维护 SSE 连接。接下来，服务器将按照优先级降序发送所有挂起的消息并依次递增序列号。由于底层传输协议是 TCP 协议，如果没有交付带有 seq#3 的消息，那么该连接应该已断开、超时或失败。
客户端期望在下一个看到的带有最大序列号重新连接 (在本例中 seq=2)。这就告诉了服务器，即使编号 3 写到了套接字上，它也没有被正常传递。然后服务器将重新发送相同的消息或以 seq=3 开始的任何更高优先级的消息。该协议构建了流连接所需的可恢复性，服务器负责大部分的存储工作，在客户端实现起来非常简单。
为了获知链接是否存活，服务器每 4 秒会发送一个心跳包，这类数据包大小只有一个比特。如果超过 7 秒没有收到来自服务器的消息或心跳，客户端会认定服务终端并重新发起链接。
在上面的协议中，每当客户端重新以一个更高的序列号发起连接时，它就充当服务器刷新旧消息的确认机制。在一个环境良好的网络中，用户可能会保持连接数分钟，从而导致服务器不断积累旧消息。为了缓解这个问题，应用程序会每 30 秒一次调用 /ramen/ack?seq=N，不管连接质量如何。协议的简单性允许用许多不同的语言和平台非常快速地编写客户端。
在设备上下文存储上，RAMEN 服务器在每次建立连接时存储设备上下文，并将此上下文暴露给 Fireball。每个设备上下文的 id 是用户及其设备参数对应的唯一哈希值。这允许隔离推送消息，即使用户在不同的设置下同时使用多个设备或应用程序。
第一代 RAMEN 服务器使用 Node.js 编写，并使用 Uber 内部的一致性哈西 / 分片框架 Ringpop。Ringpop 是一个去中心化的分片系统。所有连接都使用用户的 UUID 进行分片，并使用 Redis 作为持久性数据存储。
在接下来的一年半时间里，消息推送平台在整个公司得到了广泛的应用。高峰期时，RAMEN 系统通过维持高达 60 万个并发数据流连接，每秒向三种不同类型的应用程序推送超过 70000 个 QPS 消息。该系统很快成为服务器 - 客户端 API 基础结构中最重要的部分。
随着通信量和持久连接的快速增加，我们的技术选择也需要扩展。基于 Ringpop 的分布式分片是一个非常简单的架构，不会随着 ring 中的节点数量的增加而动态扩展。Ringpop 库使用一种 gossip 协议来评估成员资格。gossip 协议的收敛时间也随着环的大小增加而增加。
此外，Node.js 是单线程的，并且会有更高级别的事件循环延迟，从而进一步延迟成员信息的收敛。这些问题可能引发拓扑信息不一致，进而导致消息丢失、超时和错误。
2017 年初，我们决定重新启动 RAMEN 协议的服务器实现，以继续扩大应用规模。在这次迭代中，我们使用了以下技术：Netty、Apache Zookeeper、Apache Helix、Redis 和 Apache Cassandra。
1）Netty： Netty 是一个用于构建网络服务器和客户端的高性能库。Netty 的 bytebuf 允许零拷贝缓冲区，这使得系统非常高效。
2）Apache ZooKeeper： Apache ZooKeeper 对网络连接进行一致性哈希，可以直接传输数据，不需要任何存储层。但是与分散的拓扑管理不同，我们选择了 ZooKeeper 的集中共享。ZooKeeper 是一个非常强大的分布式同步和配置管理系统，可以快速检测连接节点的故障。
3）Apache Helix： Helix 是一个健壮的集群管理框架，运行在 ZooKeeper 之上，允许定义自定义拓扑和重新平衡算法。它还很好地从核心业务逻辑中抽象出拓扑逻辑。它使用 ZooKeeper 来监控已连接的工作者，并传播分片状态信息的变化。它还允许我们编写一个自定义的 Leader-Follower 拓扑和自定义的渐进再平衡算法。
4）Redis 和 Apache Cassandra： 当我们为多区域云架构做准备时，有必要对消息进行正确的复制和存储。Cassandra 是一个持久的跨区域复制存储。Redis 被用作 Cassandra 之上的容量缓存，以避免分片系统在部署或故障转移事件中常见的群发问题。
5）Streamgate： 这个服务在 Netty 上实现了 RAMEN 协议，并拥有所有与处理连接、消息和存储相关的逻辑。该服务还实现了一个 Apache Helix 参与者来建立与 ZooKeeper 的连接并维护心跳。
6）StreamgateFE (Streamgate Front End)： 该服务充当 Apache Helix 的旁观者，从 ZooKeeper 上侦听拓扑变化。它实现了反向代理。来自客户机 (火球、网关或移动应用程序) 的每个请求都使用拓扑信息进行分片，并路由到正确的 Streamgate 工作程序。
7）Helix Controllers： 顾名思义，这是一个 5 节点的独立服务，单独负责运行 Apache Helix Controller 进程，是拓扑管理的大脑。无论何时任何 Streamgate 节点启动或停止，它都会检测到更改并重新分配分片分区。
在过去的几年中，我们一直在使用这种架构，并且实现了 99.99% 的服务器端可靠性。我们推动基础设施的使用持续增长，支持 iOS、Android 和 Web 平台上的十多种不同类型的应用程序。我们已经使用超过 1.5M 的并发连接来操作这个系统，并且每秒推送超过 250,000 条消息。
服务器端基础设施一直保持稳定运行。随着我们为更多新城市提供各种各样的网络服务和应用程序，我们的重点将是继续提高向移动设备消息推送机制的长尾可靠性。我们一直在试验新协议、开发新方法，以弥合和现实需求的差距。在检查以往的不足时，我们发现以下方面是导致可靠性下降的原因。
1）缺乏认证
RAMEN 协议在减少数据传输进行了优化，仅在每 30 秒或客户端重新连接时才发送确认消息。这将导致延迟确认，在某些情况下无法确认消息达到，因此很难区分是真正的消息丢失还是确认失败。
2）连接不稳定
维持客户端和服务器的正常连接至关重要。跨不同平台的客户端实现方式在处理错误、超时、后退或应用生命周期事件 (打开或关闭)、网络状态更改、主机名和数据中心故障转移等方面有许多细微差别。这导致了不同版本间的性能差异。
3）传输限制
由于该协议在 SSE 协议基础上实现，因此数据传输是单向的。但是，许多新的应用程序要求我们启用双向消息传输机制。没有实时的往返行程时间测量，确定网络状况、传输速度、缓解线路阻塞都是不可能的。SSE 也是一个基于文本的协议，它限制了我们传输二进制有效负载的能力，不需要使用像 base64 这样的文本编码，从而获得更大的有效负载。
2019 年底，我们开始开发下一代 RAMEN 协议以解决上述缺点。经过大量考量，我们选择在 gRPC 的基础上进行构建。gRPC 是一个被广泛采用的 RPC 栈，具有跨多种语言的客户端和服务器的标准化实现，对许多不同的 RPC 方法提供了一流的支持，并具有与 QUIC 传输层协议的互操作性。
新的、基于 gRPC 的 RAMEN 协议扩展了以前基于 SSE 的协议，有几个关键的区别：
l 确认消息立即通过反向流发送，提高了确认的可靠性，而数据传输量几乎没有增加。
l 实时确认机制允许我们测量 RTT，了解实时的网络状况。我们可以区分真正的消息损失和网络损失。
l 在协议之上提供了抽象层，以支持流多路传输等功能。它还允许我们试验应用级网络优先级和流控制算法，从而在数据使用和通信延迟方面带来更高的效率。
l 协议对消息有效负载进行抽象，以支持不同类型的序列化。将来，我们会探索其他序列化方法，但要将 gRPC 保留在传输层。
l 不同语言的客户端实现也让我们能够快速支持不同类型的应用程序和设备。
目前，这项开发工作处于 beta 版阶段，很快就能上线。
消息推送平台是 Uber 出行体验的组成部分之一。今天有数百种功能建立在该平台的基础服务之上。我们总结了消息推送平台在 Uber 出行生态中取得巨大成功的几个关键原因。
1）职能分离
消息触发、创建和传递系统之间明确的职责分离允许我们在业务需求发生变化时将注意力转移到平台的不同部分。通过将交付组件分离到 Apache Helix 中，数据流的拓扑逻辑和核心业务逻辑被很好的区分开，这允许在完全相同的架构上使用不同的有线协议支持 gRPC。
2）行业标准技术
构建在行业标准技术之上使我们的实现更加鲁棒且低成本。上述系统的维护开销非常小。我们能够以一个非常高效的团队规模来传递平台的价值。根据我们的经验，Helix 和 Zookeeper 非常稳定。
我们可以在不同的网络条件下扩展到数百万用户的规模，支持数百个功能和几十个应用程序。该协议的简单性使其易于扩展和快速迭代。
原文:
https://eng.uber.com/real-time-push-platform/
3. Cassandra怎么实现查询“不等于某值”操作
不支持主要是为派或春了性能考虑，比较流行的实践是在应用端实现，类似你这种做法。用等于来做性能会更好select * from table where status = 1、select * from table where status = 3、select * from table where status = 4，而且也适合来缓存。比如下次你再拿大于2的，就直接取刚才缓存的尘耐3和4就可以了
虽然团嫌看起来有点矬，但用nosql就是有代价的
4. Cassandra中的Primary Key、Partition Key、Clustering Key都是什么
Cassandra中的Key有如下三种类型
每张表都需要有主键。主键可以是一个字段或者多个字段的组合。每条记录的主键必须唯一。举个例子
这个数据表的主键有多个字段，称做复合主键。
Cassandra 根据分区键，使用一致性哈希算法，把数据分配到集群的旅凳各个机器上。一个机器可以包含多个分区。 Cassandra 保证同一分区键的数据都在一台机器上。通过合理的设置分区键，可以信镇祥让你的查询让尽量少的机器处理，提升查询的效率
对于单主键字段来说，分区键和主键是同一个字段。
对于复合主键字段来说，默认情况下，分区键是复合主键的第一个字段。如上例中，分区键是 club 字段
可以通过括号来将分区键指定为多个字段，如将上面 CQL 的11行修改为
Clustering Keys决定了分区内数据的排序。让我们再看一下最初的例子
在主键中的字段，除了分区键外都是 clustering key 。既然 club 是主键，那么 league name kit_number position goals 是Clustering key。你可以定义 clustering key 中每个字段的升降序。可以将 kit_number 降序、 goals 升序
排序顺序与主键中字段的顺序相同。因此，在上面的例子中，数据是按照如下布局的
定义不滑搏同字段升降序的语法如下(默认为升序)
5. 北大青鸟java培训：学习Java应该了解的大数据和框架
很多人都在知道，计算机行业的发展是非常迅速的，软件开发人员想要跟上时代的发展，最重要的就是不断挑战自己。
在学习软件开发的过程，前期学习的知识是远远不够的，需要了解更多的知识，并且挑战更多的复杂性。
现在学习Java语言不能忽略工具和框架的使用，工具和框架的构建越来越复杂。
很多人不知道学习工具和框架有什么用？下面辽宁电脑培训为大家具或御配体了解Java开发应该了解的大数据工具和框架。
一、MongoDB这是一种最受欢迎的，跨平台的，面向文档的数据库。
MongoDB的核心优势是灵活的文档模型，高可用性复制集和可扩展的碎片集群。
辽宁java培训建议可以尝试以多种方式了解MongoDB，例如MongoDB工具的实时监控，内存使用和页面错误，连接，数据库操作，复制集等。
二、Elasticsearch主要是能够为云构建的分布式RESTful搜索引擎。
Elasticsearch主要是使用在Lucene之中的服务器，能够进行分布式多用户能力的全文搜索引擎，并且还是使用在Java的开发衫指中，这是现在很多企业中使用最流行的搜索引擎。
ElasticSearch不仅是一个全文搜索引擎，而且是一个分布式实时文档存储，每个字段都能够被索引并且可以被搜索。
它也是一个具有实时分析功能的分布式搜索引擎，java课程发现它还可以扩展到数百个服务器存储和处理数PB的数据。
ApacheCassandra是一套开源分布式NoSQL数据库系统。
集GoogleBigTable的数据模型与AmazonDynamo的完全分布式架构于一身。
于2008开源，此后，由于Cassandra良好的可扩展性，被Digg、Twitter等Web2.0网站所采纳，成为了一种流行的分布式结构化数据存储方案。
四、Redis开源（BSD许可证）内存数据结构存储，用作数据库，缓存和消息代理。
Redis是一个开源的，基于日志的Key-Value数据库，用ANSIC编写，支持网络，可以基于内存持久化，并提供多种语言的API。
Redis有三个主要功能，辽宁IT培训认为可以将它与许多其他竞争对手区分开来：Redis是一个将数据完全存储在内存中的数据库，仅使用磁盘用于持久性目的。
6. Apache Cassandra数据库的优缺点有哪些
Apache Cassandra数据库的优缺点有哪些？本文将超越众所周知的一些细节，探讨与 Cassandra 相关的不太明显的细节。您将检查 Cassandra 数据模型、存储模式设计、架构，以及与 Cassandra 相关的潜在惊喜。在数据库历史文章 “What Goes Around Comes Around”中，Michal Stonebraker 详细描述了存储技术是如何随着时间的推移而发展的。实现关系模型之前，开发人员曾尝试过其他模型，比如层次图和有向图。值得注意的是，基于 SQL 的关系模型（即使到现在也仍然是事实上的标准）已经盛行了大约 30 年。鉴于计算机科学的短暂历史及其快速发展的步伐，这是一项非凡的成就。关系模型建立已久，以至于许多年来，解决方案架构师很容易为应用程序选择数据存储。他们的选择总是关系数据库。诸如增加系统、移动设备、扩展的用户在线状态、云计算和多核系统的用户群之类的开发已经导致产生越来越多的大型系统。Google 和 Amazon 之类的高科技公司都是首批触及规模问题的公司。他们很快就发现关系数据库并不足以支持大型系统。为了避免这些挑战，Google 和 Amazon 提出了两个可供选择的解决方案：Big Table 和 Dynamo，他们可以由此放松关系数据模型提供的保证，从而实现更高的可扩展性。Eric Brewer 的 “CAP Theorem”后来官方化了这些观察结果。它宣称，对于可扩展性系统，一致性、可用性和分区容错性都是权衡因素，因为根本不可能构建包含所有这些属性的系统。不久之后，根据 Google 和 Amazon 早期的工作，以及所获得的对可扩展性系统的理解，计划创建一种新的存储系统。这些系统被命名为 “NoSQL” 系统。该名称最初的意思是 “如果想缩放就不要使用 SQL”，后来被重新定义为 “不只是 SQL”，意思是说，除了基于 SQL 的解决方案外，还有其他的解决方案。有许多 NoSQL 系统，而且每一个系统都缓和或改变了关系模型的某些方面。值得注意的是，没有一个 NoSQL 解决方案适用于所有的场景。每一个解决方案都优于关系模型，且针对一些用例子集进行了缩放。我的早期文章 “在 Data Storage Haystack 中为您的应用程序寻找正确的数据解决方案” 讨论了如何使应用程序需求和 NoSQL 解决方案相匹配。Apache Cassandra是其中一个最早也是最广泛使用的 NoSQL 解决方案。本文详细介绍了 Cassandra，并指出了一些首次使用 Cassandra 时不容易发现的细节和复杂之处。Apache CassandraCassandra 是一个 NoSQL 列族 (column family) 实现，使用由 Amazon Dynamo 引入的架构方面的特性来支持 Big Table 数据模型。Cassandra 的一些优势如下所示：高度可扩展性和高度可用性，没有单点故障NoSQL 列族实现非常高的写入吞吐量和良好的读取吞吐量类似 SQL 的查询语言（从 0.8 起），并通过二级索引支持搜索可调节的一致性和对复制的支持灵活的模式这些优点很容易让人们推荐使用 Cassandra，但是，对于开发人员来说，至关重要的一点是要深入探究 Cassandra 的细节和复杂之处，从而掌握该程序的复杂性。 什么是列？列 有点用词不当，使用名称单元格 很可能更容易理解一些。我会坚持使用列，因为这是一种习惯用法。Cassandra 数据模型包括列、行、列族和密钥空间 (keyspace)。让我们逐一进行详细介绍它们。•列：Cassandra 数据模型中最基本的单元，每一个列包括一个名称、一个值和一个时间戳。在本文的讨论中，我们忽略了时间戳，您可以将一个列表示为一个名称值对（例如 author="Asimov"）。•行：用一个名称标记的列的集合。例如，清单 1 显示了如何表示一个行： 清单 1. 行的示例"Second Foundation"-> { author="Asimov", publishedDate="..", tag1="sci-fi", tag2="Asimov" }Cassandra 包括许多存储节点，并且在单个存储节点内存储每一个行。在每一行内，Cassandra 总是存储按照列名称排序的列。使用这种排序顺序，Cassandra 支持切片查询，在该查询中，给定了一个行，用户可以检索属于给定的列名称范围内的列的子集。例如，范围 tag0 到 tag9999 内的切片查询会获得所有名称范围在 tag0 和 tag9999 内的列。•列族：用一个名称标记的行的集合。清单 2 显示了样例数据的可能形式： 清单 2. 列族示例Books->{ "Foundation"->{author="Asimov", publishedDate=".."}, "Second Foundation"->{author="Asimov", publishedDate=".."}, … }人们常说列族就像是关系模型中的一个表格。如下例所示，相似点将不复存在。•密钥空间：许多列族共同形成的一个组。它只是列族的一个逻辑组合，并为名称提供独立的范围。最后，超级列位于一个列族中，该列族对一个密钥下的多个列进行分组。正如开发人员不赞成使用超级列一样，在此，我对此也不作任何讨论。Cassandra 与 RDBMS 数据模型根据以上对 Cassandra 数据模型的描述，数据被放入每一个列族的二维 (2D) 空间中。要想在列族中检索数据，用户需要两个密钥：行名称和列名称。从这个意义上来说，尽管还存在多处至关重要的差异，关系模型和 Cassandra 仍然非常相似。•关系列均匀分布在表中的所有行之间。数据项之间通常有明显的纵向关系，但这种情况并不适用于 Cassandra 列。这就是 Cassandra 使用各个数据项（列）来存储列名称的原因。•有了关系模型，2D 数据空间就完整了。2D 空间内的每一个点至少应当拥有存储在此处的 null 值。另外，这种情况不适用于 Cassandra，Cassandra 可以拥有只包括少数项的行，而其他行可以拥有数百万个项。•有了关系模型，就可以对模式进行预定义，而且在运行时不可以更改模式，而 Cassandra 允许用户在运行时更改模式。•Cassandra 始终存储数据，这样就可以根据其名称对列进行排序。这使得使用切片查询在列中搜索数据变得很容易，但在行中搜索数据变得很困难，除非您使用的是保序分区程序。•另一个重要差异是，RDMBS 中的列名称表示与数据有关的元数据，但绝不是数据。而在 Cassandra 中，列名称可以包括数据。因此，Cassandra 行可以拥有数百万个列，而关系模型通常只有数十个列。•关系模型使用定义良好的不可变模式来支持复杂的查询，这些查询中包括 JOIN 和聚合等。使用关系模型，用户无需担心查询就可定义数据模式。Cassandra 不支持 JOIN 和大多数 SQL 搜索方法。因此，模式必须满足应用程序的查询要求。7. 请教Cassandra如何安全关闭的相关推荐
cat pidfile | xargs kill
在cassandra的bin目录下，有个stop-server的脚本，里面是用
kill `cat <pidfile>李首`
可见，cassandra的正确关闭弯扰升方法就这个了
如果再想安全一点，那么可以先用nodetool drain操作，阻止该几点继续接收埋老请求，执行成功之后，在执行kill命令，关闭该cassandra节点。
8. 关于NoSQL的思考：为什么我们要优化存储的写性能
比如Cassandra，MongoDB这两个NoSQL的杰出代表。究其原因，我们可能会想到是因为当前UGC模式已经发展到白热化，用户产生内容导致读写比已经接近或者说小于1：1。 但是我认为这绝不是个中真实原因。 1. 缓存导致存储的raw read效率不再重要 真实原因是我们对读的优化已经做得足够多了，数据存储我们使用Memcached，TokyoTyrant/TokyoCabinet等缓存存储，页面及文件缓存我们使用squid，nginx proxy_cache等存储，都可以达到非常好的读缓存效果，如果数据即时性要求不高，或者说缓存设计合理（读写皆缓存），缓存命中率会足够的高，因此我们无需再过分优化底层存储的raw read效率。 试想缓存层如果有高达99％以上的命中率，那么相对于raw read设备，我们的亿级的数据读取请求就轻松的变成百万级请求，上千并发轻松变成数十并发。当然，这需要我们的缓存层足够靠谱。比如 nginx proxy_cache 可以多较多，这时候宕掉一台不至于使全部读请求穿透到底层存储。至于多了之后purge等操作如何全面的执行，不在本文讨论之列。 综上，raw read效率不需要再提升，因为其需求已经被缓存层大量取改顷慎代。 2. 无法取代的rawwrite功能 看到缓存减轻raw read的工作量，我们可以在想是否有方法可以减轻rawwrite的工作量。答案是不可以的。如果您认为可以。可以留言探讨。既然rawwrite的工作量是不可取代的，那么我们大概可以有两种方法提升写操作的性能。 3.1 sharding 通过对数据的分区，我们可以将数据进行分布式的存储，于是每个结点只会分配到一部分的rawwrite请求。这样相当于公司员工效率不变，多招了人。但由于结点的增多，其中有结点出问题的效率也大大增加。于是我们不得不做一些replication操作来提供HA方案。 3.2 提升rawwrite效率 如上面的举例，我们只能选择提升rawwrite效率来实现总体（核敬包括cache层）更好的读写效率。这里通常使用的方法就是将随机的写操作在内存中进行序列化，并在一定量后进行顺序的flush到磁盘操作。所谓将内存当成硬盘，将硬盘当作磁带就是这个意思。（可参见我更早的一篇文章：《NoSQL理论之-内存是新的硬盘，硬盘是新的磁带》）所以我们看到前面说到的很多NoSQL产品着重对乎册写操作进行了优化，而对读性能提升并不明显，甚至不惜以更慢的读作为提升写操作性能的代价。 4. 总结 由于读性能可以通过设置合理的缓存策略来减少raw read操作的数量。因此不仅对读写比不大的情形需要着重进行写操作的优化，对读写比大的情况下，仍旧需要优化写性能而非读性能。
9. cassandra 查询超时
在对某个表做count时出现如下错误(在做业务性测试，生产环境请不要简单粗暴做count操作，耗时还可能不准)
很奇怪，另外一个表应该是跟他相同条数的，都能直接count出来，但是当前表count一直报错，而且数据还差2两条(跟ES里面的数据对比后得知)
在网上可以直接查询相关问题，结果也出来了很多。其中我给出几个具有参考性的链接
其中第一个链接其实已经反映了我这次的问题，但是我第一眼看到这个答案并没有感觉到确切符合我当前的问题，然后后面看到第二个链接时，明白了去哪儿看日志。
在 cassandra system.log 看到了count产生的日志，前面后后观察了很长的日志，结果会出现如下一些情况
上面是3个有不同于常见日志的信息，下面是常见的日志信息
这哗绝腊个问题曾经以为被定位到问题，但是最终却发现还是无能为力。这里说下历程
第一次以为找到缘由
做count 操作操作时，就跟其他读操作一样，需要将数据加载到缓存中。数据来源包括 SSTables，tombstone标记，这些数据都放在缓存中。
缓存的大小由cassandra.yaml中的 file_cache_size_in_mb 设置控制。 默认大小为 512 MB
count出问题这张表是因为有一个字段存了很长的文本内容，count整个表时，将所有数据(完整的每行数据)加载到内存就导致内存不足。
第二次
根据上面的方式解决count超时不久后又发现超时，但这次却是不同之前说的两个表。这次没有再去调配置大小，而是在@玄陵 的指导下 跟踪了cpu idle 跟磁盘的 %util
在跟踪的过程中刚好出现 %util 达到 100% , 99% 的情况。然后他认为就是磁盘性能造成的超时。但是我跟踪了磁盘负载很高的时间刚好是定时任务在往cassandra里面写数据。那 %util 高应该是写入造成的，我在定时任务跑完然后再去执行count 也还是超时，所以我不太认同时磁盘性能造成count超时。当然，我们的确实存在磁盘性能，这个后续需要好好调优
无果
我宏信之前执行count sql 时一直在 datagrip (一种cassandra的可视化管理)中操作。偶然想去cassandra 终端使用cqlsh执行，结果竟然有意外之喜
在cqlsh 首次执行也是超时，但是后面执行就能成功统计。而在datagrip中统计却一直出现超时错误。那这两个有什么表现不一样么
观察日志发现：在datagrip做操作时，system.log 会输出很多(全是查询的sql语句)，而在cqlsh中进行统计时，发现system.log 竟然只有少量的日志输出，甚至没有常见的查询日志，也是异常奇怪。目前找不到更多原因乱滑，只能记录存档了。
对于这个问题花费了很多力气，查过缓存不足，tombstone太多，cpu, 硬盘。但最后我更倾向这个操作违反了cassandra的设计，cassandra 是分布式的，记录是分区存储。当在做 聚合查询 时 却没有带where 限制条件，那么很可能不能得到你预期的结果。count可以对一个数据量小小的table进行，但是数据量稍微大一点，可能就不能这么用了。
对于其他聚合查询请点击下面链接
解决
如果是业务层需要做count统计，需要根据分区键去做count
如果只是观察数据总条数，建议直接在cqlsh上进行统计(不要使用其他工具)，当然这个也依然存在超时的问题。所以这里推荐 一个 非常好的统计工具 brianmhess/cassandra-count
这个工具通过使用numSplits参数拆分令牌范围，可以减少每个查询计数的数量并减少超时的可能性。
目前使用下来效果还非常不错
10. Cassandra实战 笔记-《Cassandra内部数据存储结构》
Cassandra的配置文件可以对Cassandra中的数据进行配置。cassandra.yaml 中关于存放数据信息的配置如下：
数据信息一共分为以下3类：
在data目录下，Cassandra 会将每一个 Keyspace 中的数据存储在不同的文件目录下，并且 Keyspace 文件
目录的名称与 Keyspace 名称相同。
假设有两个 Keyspace，分别为 ks1 和 ks2，但在 data目录下，将看到3个不同的目录：ks1，ks2和 system。其中 ks1 和 ks2 用于存储系统定义的两个 Keyspace 的数据，另外一个 system 目录是 Cassandra 系统默认的一个 Keyspace，叫做 system，它用来存储 Cassandra 系统的相关元数据信息以及 HINT 数据信息。
当 Cassandra 有数据需要更新时，第一个记录这个更新的地方就是 Commitlog。
Commitlog由如下两个部分构成：
CommitLog - xxx.log 、 CommitLog - xxx.log.header 。
在 CommitLog - xxx.log 文件灶圆中，保存了每一次更新操作的值。
在 CommitLog - xxx.log.header 文件中，记录了哪些数据已经从 memtable 中写入 SSTable 中。
通过log. header文件中记录的元数据信息, Cassandra 可以及时删除不必要的Commitlog文件，减少磁盘的占用量，并在Cassandra重启时,加快从Commitlog中恢复数据的速度。
Commitlog文件的大小可以在配置文件中指定，默认是128MB。
当一个Commitlog文件大小超过设置的阈值后，将会新建一个Commitlog,并将更新数据写人这个新的文件中。
Cassandra提供了两种记录Commitlog的方式:周期记录( periodic)和批量记录( batch)。如果使用周期记录的方式，需要在配置文件进行如下配置:
Cassandra会每次更新信息将写人 Commitlog 中，并且每隔一定的时间间隔( commitlog-sync_ period in ms )调用 org apache. cassandra. io. util. BufferedRandomAccessFile. syne() 同步 Commitlog 文件。
如果使用批量记录的方式，需要在配置文件进行如下配置:
Cassandra会缓存每次更新信息，每隔一定的时间间隔( commitlog sync_ batch _window_in_ ms )调用 org. apache. cassandra. io. util. BuferedRandomAccessFile. syne () 同步Commitlog 文件，最后将之前缓存的更新信息写人Commitlog中。
如果不允许数据丢失，可以使用周期的方式记录 Commitlog。圆友如果写入数据量非常大，同时可以承担由于机器可能宕机导致的数据丢失的风险，则使用批量记录的方式记录 Commitlog。
在实际的使用中，可以根据情况来选用合适的 Commitlog记录方式。
数据写入 Commitlog 后，将缓存在 Memtable 中。
Cassandra 中橘辩槐每一个 Memetable 只为一个 ColumnFamily 提供服务。
当下面3个条件中任意个满足后，会将Memtable中缓存的数据写入磁盘，形成一个SSTable文件。
上面提到的3个参数都可以在配置文件中进行设置，Cassandra 为每一个ColumnFamily提供单独的配置。
每当有数据进人 Memtable 中时，会将数据保存到成员变量 ColumnFarmilies 中，并解析这个数据，排除重复或者是已经过期的数据。具体实现如下:
当Cassandra需要将Memtable中缓存的数据写人磁盘时，会按照内存中Key的顺序写人SSTable中。
使用 Memtable 的优势在于：将随机 IO 写变为顺序 IO 写，降低大量的写操作对存储系统的压力。
Cassandra 中的 Memtable 会缓存客户端写入的数据，当Memtable中缓存的某一个ColumnFamily中的数据量( 对应配置文件中的 memtable_ throughput_ in mb 和 memtable_ operations_in_ millions 或者超过上一次生成SSTable的时间(对应配置文件中的 memtable flush_ after_mins )后，Cassandra 会将Memtable中对应的ColumnFamily的数据持久化到磁盘中，生成一个SSTable文件。
如ColumnFamily名称为Cfl的一个SSTable文件由如下文件组成:
其中，“Cf1”为ColumnFamily的名称;“e” 为版本的标识(这个标识在0.7之前的版本中是没有的);“1”代表这是名称为Cfl的ColumnFamily的第一个SSTable,这个数字会随着新的SSTable文件的生成不断增加;“Data”、“Filter”、 “Index"和“Statistics" 分别代表 SSTable 4个不同组成部分，它们的作用各不相同。
在Cassandra中，除了用户自己定义的 Keyspace 之外，还有一个特殊的 Keyspace :名称为system的系统表空间。
用户不能在 Cassandra 中创建名为 system 的 Keyspace,只能由 Cassandra 系统自动创建。系统表空间的主要有以下两个作用:
如果系统首次启动，Cassandra 将会自动在data目录下创建系统表空间，并将系统元数据信息存放在系统表空间中。以后启动的过程中，Cassandra 将会直接从系统表空间中读取系统元数据信息。
如果 Cassandra 发现某一个节点宕机，就会将发送给宕机节点的数据以 HINT 的形式发送给另外台 Cassandra 服务器。接收到 HINT 数据的 Cassandra 服务器将数据缓存到系统表空间中，当其发现宕机的 Cassandra 恢复后，将缓存 HINT 数据发送给恢复的服务器，完成数据传输后，将缓存的 HINT 数据从系统表空间中删除。
本章从原理上分析和讲解了 Cassandra 的内部数据存储结构Commitlog、Memtable、SSTable和构成SSTable的4个子文件。了解Cassandra的内部数据存储构造有利于为基于Cassandra的应用程序设计合理的数据模型，以及找出造成读写瓶颈的原因。另外还介绍了Cassandra的系统表空间，了解了整个系统元数据管理的机制。