标签 Cassandra 下的文章

Apache Cassandra 是一个自由开源的 NoSQL 数据库管理系统，用于在许多服务器上操作大量信息，提供无单点故障的高可用性。

我不打算讨论 NoSQL 数据库的细节。我将会告诉你如何在基于 Ubuntu 的 Linux 发行版上安装 Apache Cassandra。

请注意，这更多是为了实践。

在 Linux 上安装 Apache Cassandra

有多种方法可以在 Ubuntu 和其他 Linux 发行版上安装 Cassandra：

  • 使用 Apache 的官方 deb 仓库安装：适合并推荐给基于 Debian 和 Ubuntu 的发行版。如果有更新的版本，会得到自动更新。
  • 使用 Docker 安装：适用于所有 Linux 发行版。
  • 从 tarball 安装：适用于所有 Linux，但不会自动更新到新版本。

这仅仅是为了练习和体验 Apache Cassandra。如果你要在一个项目中使用它和其他服务，你必须遵循该服务的完整配置和设置指南。

我将展示前两种方法。

方法 1：使用官方仓库在 Ubuntu 和 Debian 上安装 Cassandra

在你安装和使用 Cassandra 之前，你需要在你的系统上安装 Python 和 Java。你可能需要 在 Ubuntu 上安装 Java，但 Python 通常是预装的。

你可以用下面这行来检查先决条件：

java -version && python --version

所有先决条件都安装好了？那就好。让我们来安装 Cassandra。这里的方法与 在 Ubuntu 中添加任意外部仓库 相同。

首先，将 Apache Cassandra 仓库添加到你的源列表中。下面这个添加最新的主要版本（在写这篇文章的时候）4.0 系列。

echo "deb http://www.apache.org/dist/cassandra/debian 40x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list

Add Apache Cassandra repository

现在，下载并将 Apache Cassandra 仓库的密钥添加到服务器上的受信任密钥列表中。这样，你的系统就会信任来自你在上一步添加的仓库的软件包。

你应该确保 apt 可以通过 https 使用。

sudo apt install apt-transport-https

然后添加密钥：

wget https://www.apache.org/dist/cassandra/KEYS && sudo apt-key add KEYS

Add Apache Cassandra repository key

你已经添加了仓库。更新本地缓存，使你的系统知道这个新仓库的存在。

sudo apt update

最后，用以下命令安装 Cassandra：

sudo apt install cassandra

Installing Apache Cassandra on Ubuntu

安装完成后，Cassandra 服务会自动开始运行。如果你想的话，你仍然可以验证它：

sudo systemctl status cassandra.service

Check if Cassandra is running

你可以输入 cqlsh 连接到数据库。输入 exit 来退出这个 shell。

Entering cqlsh

这是非常基本和默认的设置。你可能需要根据你的需求来配置它。请查看 官方文档中的配置部分。

方法 2：使用 Docker 安装 Apache Cassandra

这个方法适用于任何 Linux 发行版，只要你打算在 Docker 设置中使用它。

当然，你需要在你的系统上安装 Docker 来实现这个方法。这是这个方法的前提条件，我让你处理这件事情。

如果你有 Docker，使用下面的命令来拉取 Apache Cassandra 的 Docker 镜像：

sudo docker pull cassandra:latest

Pulling Apache Cassandra docker image

完成后，你可以用 docker run 命令来启动 Cassandra，像这样：

sudo docker run --name cass_cluster cassandra:latest

Running Cassandra in a container

注意： --name 选项指的是创建的 Cassandra 集群的名称。

要与之前启动的 Cassandra 节点交互，你需要初始化 CQL shell，你可以用 Docker exec 命令这样做：

sudo docker exec -it cass_cluster cqlsh

Access the cqlsh running in Docker.

恭喜！ 现在你至少知道了在你的系统中安装 Apache Cassandra 的两种不同方法。

请记住，这篇文章只是一个介绍。如果你有兴趣了解更多关于 Apache Cassandra 的信息，请阅读 文档，在那里你可以找到更多关于这个神奇的 NoSQL 数据库管理系统的信息。如果这篇文章对你有帮助，请阅读并分享它。下一篇见。

via: https://itsfoss.com/apache-cassandra-ubuntu/

作者：Marco Carmona 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

速度和可扩展性是 Apache Cassandra 不变的追求；来学习一下如何充分发挥它的专长吧。

title=

Apache Cassandra 是一个数据库，但又不是一个简单的数据库；它是一个复制数据库，专为可扩展性、高可用性、低延迟和良好性能而设计调整。Cassandra 可以帮你的数据在区域性中断、硬件故障时，以及很多管理员认为数据量过多的情况下幸免于难。

全面掌握数据分区知识，你就能让 Cassandra 集群实现良好的设计、极高的性能和可扩展性。在本文中，我将探究如何定义分区，Cassandra 如何使用这些分区，以及一些你应该了解的最佳实践方案和已知问题。

基本概念是这样的: 供数据库关键函数（如数据分发、复制和索引化）使用的原子单元，单个这样的数据块就是一个分区。分布式数据系统通常会把传入的数据分配到这些分区中，使用简单的数学函数（例如 identity 或 hashing 函数）执行分区过程，并用得到的 “分区键” 对数据分组，进一步再形成分区。例如，假设传入数据是服务器日志，使用 “identity” 分区函数和每个日志的时间戳（四舍五入到小时值）作为分区键，我们可以对这些数据进行分区，实现每个分区各保存一小时的日志的目的。

Cassandra 中的数据分区

Cassandra 作为分布式系统运行，并且符合前述数据分区原则。使用 Cassandra，数据分区依赖于在集群级别配置的算法和在表级别配置的分区键。

title=

Cassandra 查询语言（CQL）使用大家很熟悉的 SQL 表、行、列等术语。在上面的示例图中，表配置的主键中包含了分区键，具体格式为： 主键 Primary Key = 分区键 Partition Key + [ 聚簇列 Clustering Columns ] 。

Cassandra 中的主键既定义了唯一的数据分区，也包含着分区内的数据排列依据信息。数据排列信息取决于聚簇列（非必需项）。每个唯一的分区键代表着服务器（包括其副本所在的服务器）中管理的若干行。

在 CQL 中定义主键

接下来的四个示例演示了如何使用 CQL 语法表示主键。定义主键会让数据行分到不同的集合里，通常这些集合就是分区。

定义方式 1（分区键：log\_hour，聚簇列：无）

CREATE TABLE server_logs(
   log_hour TIMESTAMP PRIMARYKEY,
   log_level text,
   message text,
   server text
   )

这里，有相同 log_hour 的所有行都会进入同一个分区。

定义方式 2（分区键：log\_hour，聚簇列：log\_level）

CREATE TABLE server_logs(
   log_hour TIMESTAMP,
   log_level text,
   message text,
   server text,
   PRIMARY KEY (log_hour, log_level)
   )

此定义方式与方式 1 使用了相同的分区键，但此方式中，每个分区的所有行都会按 log_level 升序排列。

定义方式 3（分区键：log\_hour，server，聚簇列：无）

CREATE TABLE server_logs(
   log_hour TIMESTAMP,
   log_level text,
   message text,
   server text,
   PRIMARY KEY ((log_hour, server))
   )

在此定义中，server 和 log_hour 字段都相同的行才会进入同一个分区。

定义方式 4（分区键：log\_hour，server，聚簇列：log\_level）

CREATE TABLE server_logs(
   log_hour TIMESTAMP,
   log_level text,
   message text,
   server text,
   PRIMARY KEY ((log_hour, server),log_level)
   )WITH CLUSTERING ORDER BY (column3 DESC);

此定义方式与方式 3 分区相同，但分区内的行会依照 log_level 降序排列。

Cassandra 如何使用分区键

Cassandra 依靠分区键来确定在哪个节点上存储数据，以及在需要时定位数据。Cassandra 通过查看表中的分区键来执行这些读取和写入操作，并使用 令牌 tokens （一个 -2^{63}−263 到 +2^{63}-1+263−1 范围内的 long 类型值）来进行数据分布和索引。这些令牌通过分区器映射到分区键，分区器使用了将分区键转换为令牌的分区函数。通过这种令牌机制，Cassandra 集群的每个节点都拥有一组数据分区。然后分区键在每个节点上启用数据索引。

title=

图中显示了一个三节点的 Cassandra 集群以及相应的令牌范围分配。这只是一个简单的示意图：具体实现过程使用了 Vnodes。

数据分区对 Cassandra 集群的影响

用心的分区键设计对于实现用例的理想分区大小至关重要。合理的分区可以实现均匀的数据分布和强大的 I/O 性能。分区大小对 Cassandra 集群有若干需要注意的影响：

  • 读取性能 —— 为了在磁盘上的 SSTables 文件中找到分区，Cassandra 使用缓存、索引和索引摘要等数据结构。过大的分区会降低这些数据结构的维护效率，从而对性能产生负面影响。Cassandra 新版本在这方面取得了长足的进步：特别是 3.6 及其以上版本的 Cassandra 引擎引入了存储改进，针对大型分区，可以提供更好的性能，以及更强的应对内存问题和崩溃的弹性。
  • 内存使用 —— 大分区会对 JVM 堆产生更大的压力，同时分区的增大也降低了垃圾收集机制的效率。
  • Cassandra 修复 —— 大分区使 Cassandra 执行修复维护操作（通过跨副本比较数据来保持数据一致）时更加困难。
  • “墓碑”删除 —— 听起来可能有点骇人，Cassandra 使用称为“ 墓碑 tombstones ”的独特标记来记录要删除的数据。如果没有合适的数据删除模式和压缩策略，大分区会使删除过程变得更加困难。

虽然这些影响可能会让人更倾向于简单地设计能产生小分区的分区键，但数据访问模式对理想的分区大小也有很大影响（有关更多信息，请阅读关于 Cassandra 数据建模 的深入讲解）。数据访问模式可以定义为表的查询方式，包括表的所有 select 查询。 理想情况下，CQL 选择查询应该在 where 子句中只使用一个分区键。也就是说，当查询可以从单个分区，而不是许多较小的分区获取所需数据时，Cassandra 是最有效率的。

分区键设计的最佳实践

遵循分区键设计的最佳实践原则，这会帮你得到理想的分区大小。根据经验，Cassandra 中的最大分区应保持在 100MB 以下。理想情况下，它应该小于 10MB。虽然 Cassandra 3.6 及其以上版本能更好地支持大分区，但也必须对每个工作负载进行仔细的测试和基准测试，以确保分区键设计能够支持所需的集群性能。

具体来说，这些最佳实践原则适用于任何分区键设计：

  • 分区键的目标必须是将理想数量的数据放入每个分区，以支持其访问模式的需求。
  • 分区键应禁止无界分区：那些大小可能随着时间无限增长的分区。例如，在上面的 server_logs 示例中，随着服务器日志数量的不断增加，使用服务器列作为分区键就会产生无界分区。相比之下，使用 log_hour 将每个分区限制为一个小时数据的方案会更好。
  • 分区键还应避免产生分区倾斜，即分区增长不均匀，有些分区可能随着时间的推移而不受限制地增长。在 server_logs 示例中，在一台服务器生成的日志远多于其他服务器的情况下使用服务器列会产生分区倾斜。为了避免这种情况，可以从表中引入另一个属性来强制均匀分布，即使要创建一个虚拟列来这样做，也是值得的。
  • 使用时间元素和其他属性的组合分区键，这对时间序列数据分区很有帮助。这种方式可以防止无界分区，使访问模式能够在查询特定数据时使用时间属性，而且能够对特定时间段内的数据进行删除。上面的每个示例都使用了 log_hour 时间属性来演示这一点。

还有一些工具可用于帮助测试、分析和监控 Cassandra 分区，以检查所选模式是否高效。通过仔细设计分区键，使解决方案的数据和需求保持一致，并遵循最佳实践原则来优化分区大小，你就可以充分利用数据分区，更好地发挥 Cassandra 的可扩展性和性能潜力。

via: https://opensource.com/article/20/5/apache-cassandra

作者：Anil Inamdar 选题：lujun9972 译者：unigeorge 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

虚拟表是什么以及如何使用。

在最近的发布的 Apache Cassandra 4.0 测试版中的众多新增功能中， 虚拟表 virtual table 是一个值得关注的功能。

在以前的 Cassandra 版本中，用户需要访问 Java 管理扩展 Java Management Extensions （JMX） 来查看 Cassandra 的细节，如运行中的 压实 compaction 、客户端、度量和各种配置设置。虚拟表消除了这些挑战。Cassandra 4.0 测试版让用户能够从一个只读的系统表中以 Cassandra 查询语言 Cassandra Query Language （CQL）行的形式查询这些细节和数据。

以下是之前 Cassandra 版本中基于 JMX 的机制是如何工作的。想象一下，一个用户想要检查集群中某个节点的压实状态。用户首先要建立一个 JMX 连接，在节点上运行 nodetool compactionstats。这个要求马上就给用户带来了一些复杂的问题。用户的客户端是否配置了 JMX 访问？Cassandra 节点和防火墙是否配置为允许 JMX 访问？是否准备好了适当的安全和审计措施，并落实到位？这些只是用户在处理 Cassandra 以前版本时必须面对的其中一些问题。

在 Cassandra 4.0 中，虚拟表使得用户可以利用之前配置的驱动来查询所需信息。这一变化消除了与实现和维护 JMX 访问相关的所有开销。

Cassandra 4.0 创建了两个新的 键空间 keyspace 来帮助用户利用虚拟表：system_views 和 system_virtual_schema。system_views 键空间包含了用户查询的所有有价值的信息，有用地存储在一些表中。system_virtual_schema 键空间，顾名思义，存储了这些虚拟表的所有必要的模式信息。

title=

重要的是要明白，每个虚拟表的范围仅限于其节点。任何虚拟表查询都将返回的数据，只对其协调器的节点有效，而不管一致性如何。为了简化这一要求，已经在几个驱动中添加了支持，以便在这些查询中指定协调器节点 （Python、DataStax Java 和其他驱动现在提供了这种支持）。

为了说明这一点，请查看这个 sstable_tasks 虚拟表。这个虚拟表显示了对 SSTables 的所有操作，包括压实、清理、升级等。

title=

如果用户在以前的 Cassandra 版本中运行 nodetool compactionstats，则会显示相同类型的信息。 在这里，这个查询发现该节点当前有一个活动的压缩。它还显示了它的进度以及它的键空间和表。得益于虚拟表，用户可以快速收集这些信息，并同样有效地获得正确诊断集群健康状况所需的能力。

需要说明的是，Cassandra 4.0 并没有去除对 JMX 访问的需求。JMX 仍然是查询某些指标的唯一选择。尽管如此，用户会欢迎简单地使用 CQL 来获取关键集群指标的能力。由于虚拟表提供的便利，用户可能会将之前投入到 JMX 工具的时间和资源重新投入到 Cassandra 本身。客户端工具也应该开始利用虚拟表提供的优势。

如果你对 Cassandra 4.0 测试版及其虚拟表功能感兴趣，请试试试它。

via: https://opensource.com/article/20/10/virtual-tables-apache-cassandra

作者：Ben Bromhead 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Apache Cassandra 数据库近来引起了很多的兴趣，这主要源于现代云端软件对于可用性及性能方面的要求。

那么，Apache Cassandra 是什么？它是一种为高可用性及线性可扩展性优化的分布式的联机交易处理 (OLTP) 数据库。具体说到 Cassandra 的用途时，可以想想你希望贴近用户的系统，比如说让我们的用户进行交互的系统、需要保证实时可用的程序等等，如：产品目录，物联网，医疗系统，以及移动应用。对这些程序而言，下线时间意味着利润降低甚至导致其他更坏的结果。Netfilix 是这个在 2008 年开源的项目的早期使用者，他们对此项目的贡献以及带来的成功让这个项目名声大噪。

Cassandra 于2010年成为了 Apache 软件基金会的顶级项目，并从此之后就流行起来。现在，只要你有 Cassadra 的相关知识，找工作时就能轻松不少。想想看，NoSQL 语言和开源技术能达到企业级 SQL 技术的高度，真让人觉得十分疯狂而又不可思议的。这引出了一个问题。是什么让它如此的流行？

由于采用了亚马逊发表的 Dynamo 论文中率先提出的设计，Cassandra 有能力在大规模的硬件及网络故障时保持实时在线。由于采用了点对点模式，在没有单点故障的情况下，我们能幸免于机架故障甚至全网中断。我们能在不影响用户体验的前提下处理数据中心故障。一个能考虑到故障的分布式系统才是一个没有后顾之忧的分布式系统，因为老实说，故障是迟早会发生的。有了 Cassandra， 我们可以直面残酷的生活并将之融入数据库的结构和功能中。

我们能猜到你现在在想什么，“但我只有关系数据库相关背景，难道这样的转变不会很困难吗？”这问题的答案介于是和不是之间。使用 Cassandra 建立数据模型对有关系数据库背景的开发者而言是轻车熟路。我们使用表格来建立数据模型，并使用 CQL （ Cassandra 查询语言）来查询数据库。然而，与 SQL 不同的是，Cassandra 支持更加复杂的数据结构，例如嵌套和用户自定义类型。举个例子，当要储存对一个小猫照片的点赞数目时，我们可以将整个数据储存在一个包含照片本身的集合之中从而获得更快的顺序查找而不是建立一个独立的表。这样的表述在 CQL 中十分的自然。在我们照片表中，我们需要记录名字，URL以及给此照片点赞过的人。

在一个高性能系统中，毫秒级处理都能对用户体验和客户维系产生影响。昂贵的 JOIN 操作制约了我们通过增加不可预见的网络调用而扩容的能力。当我们将数据反范式化使其能通过尽可能少的请求就可获取时，我们即可从磁盘空间成本的降低中获益并获得可预期的、高性能应用。我们将反范式化同 Cassandra 一同介绍是因为它提供了很有吸引力的的折衷方案。

很明显，我们不会局限于对于小猫照片的点赞数量。Canssandra 是一款为高并发写入优化的方案。这使其成为需要时常吞吐数据的大数据应用的理想解决方案。实时应用和物联网方面的应用正在稳步增长，无论是需求还是市场表现，我们也会不断的利用我们收集到的数据来寻求改进技术应用的方式。

这就引出了我们的下一步，我们已经提到了如何以一种现代的、性价比高的方式储存数据，但我们应该如何获得更多的动力呢？具体而言，当我们收集到了所需的数据，我们应该怎样处理呢？如何才能有效的分析几百 TB 的数据呢？如何才能实时的对我们所收集到的信息进行反馈，并在几秒而不是几小时的时间利作出决策呢？Apache Spark 将给我们答案。

Spark 是大数据变革中的下一步。 Hadoop 和 MapReduce 都是革命性的产品，它们让大数据界获得了分析所有我们所取得的数据的机会。Spark 对性能的大幅提升及对代码复杂度的大幅降低则将大数据分析提升到了另一个高度。通过 Spark，我们能大批量的处理计算，对流处理进行快速反应，通过机器学习作出决策，并通过图遍历来理解复杂的递归关系。这并非只是为你的客户提供与快捷可靠的应用程序连接（Cassandra 已经提供了这样的功能），这更是能洞悉 Canssandra 所储存的数据，作出更加合理的商业决策并同时更好地满足客户需求。

你可以看看 Spark-Cassandra Connector (开源) 并动手试试。若想了解更多关于这两种技术的信息，我们强烈推荐名为 DataStax Academy 的自学课程

via: https://opensource.com/life/16/5/basics-cassandra-and-spark-data-processing

作者：Jon Haddad,Dani Traphagen 译者：KevinSJ 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出