首先

今年，也就是2023年6月1日，Cassandra Day将在日本举办。去年，Cassandra Day分别在柏林、伦敦、阿姆斯特丹、河内、雅加达、休斯顿、圣塔克拉拉、西雅图和新加坡举办了活动。

本次东京举办的活动中，我们将发布与Apache Cassandra相关的文章。

关于Apache Cassandra

Apache Cassandra是一个开源的分布式数据库管理系统。

和其他分布式数据库管理系统一样，可以使用多个通用服务器来构建一个数据库（在开发等情况下，也可以使用单个服务器构建）。

在这里，我们将省略详细解释，而将介绍给对此感兴趣的人的角色交给官方网站和维基百科。

驱动程序与连接及连接池之间的关系。

这次我们会讨论一个小众话题，就是在Cassandra中，（基本上）不需要连接池。

急いで追加すると、Cassandra已经包含了连接池的概念和功能。
那么，意思是什么呢？以上所述的是，连接池的默认值为“1”，所以基本上不需要更改这个设置。

以下，

• なぜコネクションプールを必要がないのか？つまり、どんな点がRDBのコネクションプールの考え方と違うのか？

「基本的には」と注釈した理由である例外が発生するケース

关于这一点，我会进行解释

这篇稿件所基于的信息来自于以下文件，请随需要详细参考此处。

为什么不需要连接池，或者与关系型数据库（RDB）有何不同的原因？

（JDBC）连接池是一种创建和管理维持与数据库连接的线程数量的机制，可以说是基于同步通信。

对于这一点，Cassandra的客户端-服务器通信是异步的。客户端（通常指应用服务器）和服务器（构成集群的节点）之间通过一个连接进行异步通信，执行多个（应用服务器上的）数据通信（即对用户请求的数据库连接）。每个通信的唯一性和特性通过流ID进行管理。

在连接池情况下，与线程数相当的同时连接限制将遵循此流ID的上限。根据协议版本，此限制如下所示。

• protocol v2 以前: コネクション毎に128のストリームID stream ids per connection.

protocol v3 以降: コネクション毎に最大32768のストリームID

从这里开始，特别是对于 v3 以及以后的版本来说，我们可以明白同时连接数的限制不需要太过担心。

此外，驅動程式能夠識別集群並在一般環境下將客戶端的連接分散到多個節點。

以下是显示客户端请求与集群之间的一对多环境的图表。

使用（增加）连接池的情况

典型的な場合、コネクションプールを増やす必要があるのは、1つのノードクラスターです。
文書から、関連部分を引用します。

正如前述，协议v3的默认池大小为core = max = 1。这意味着所有请求都共享一个单一连接到特定节点，并因此共享一个单一Netty I/O线程。

这个 I/O 线程有时会耗尽 CPU 核心，并成为驱动程序的瓶颈。在我们的基准测试中，这在单节点集群和高吞吐量（约80K个请求/秒）下发生。

这个问题几乎不太可能发生。在大多数情况下，由于驱动程序连接到了多个节点，负载会分散到更多的I/O线程上。然而，如果您认为问题已经发生了，请注意以下几点。

上述的边界情况的处理也在文件中有所记载。

虽然如此，我认为大部分情况下并不需要利用这个案例作为契机。

最终

在这篇文章中，我们旨在事先澄清与Cassandra驱动程序连接相关的可能产生误解的问题，特别是那些对连接池较为熟悉的开发者可能存在的误解。

希望这能对您有所帮助。