Вы правы, соединение на самом деле находится в сеансе, а сеанс - это объект, который вы должны передать своим DAO для записи в Cassandra.

Пока вы используете один и тот же объект сеанса, вы должны повторно использовать соединения (вы можете видеть сеанс как свой пул соединений).

Изменить (2017/4/10): я уточнил этот ответ после @William Price one. Имейте в виду, что этому ответу 4 года, и Кассандра за это время немного изменилась!

принятый ответ _{(на момент написания)} дать правильный совет:

Пока вы используете один и тот же объект Session, вы [будете] повторно использовать соединения.

Однако некоторые части изначально были упрощены. Я надеюсь, что нижеследующее дает представление о масштабах каждого типа объектов и их соответствующих целях.

Строитель ≠ Кластер ≠ Сессия ≠ Соединение ≠ Заявление

Cluster.Builder - это используется для настройки и создания кластера

Cluster представляет весь Кольцо кассандры

Кольцо состоит из нескольких узлов (хостов), и кольцо может поддерживать одно или несколько пространств ключей. Вы можете запросить объект Cluster о свойствах уровня кластера (кольца).

Я также думаю об этом как об объекте, который представляет для кольца вызывающее приложение. Вы сообщили о потребностях вашего приложения (например, о шифровании, сжатии и т. Д.) Сборщику, но именно этот объект первым реализует / взаимодействует с фактическим кольцом C *. Если ваше приложение использует несколько учетных данных аутентификации для разных пользователей / целей, у вас, вероятно, будут разные объекты Cluster, даже если они подключены к одному кольцу.

Session сам по себе не соединение, но он управляет ими

Сеансу может потребоваться поговорить со всеми узлами в кольце, что невозможно сделать с одним TCP-соединением, за исключением особого случая колец, которые содержат ровно один (1) узел. Сеанс управляет пул соединений, и этот пул обычно будет иметь по крайней мере одно соединение для каждого узла в кольце. Вот почему вам следует как можно чаще повторно использовать объекты Session. Приложение не управляет подключениями напрямую и не получает доступа к ним.

Доступ к сеансу осуществляется из объекта Cluster; обычно он привязан к одному ключевому пространству за раз, которое становится ключевым пространством по умолчанию для операторов, выполняемых из этого сеанса. Оператор может использовать полное имя таблицы (например, keyspacename.tablename) для доступа к таблицам в других пространствах ключей, поэтому не требуется использовать несколько сеансов для доступа к данным в разных пространствах ключей. Использование нескольких сеансов для связи с одним и тем же кольцом увеличивает общее количество требуемых TCP-соединений.

Statement выполняется в Сессия

Заявления могут быть подготовлен или нет, и каждый либо изменяет данные, либо запрашивает их (а в некоторых случаях и то, и другое). Самые быстрые и эффективные операторы должны взаимодействовать не более чем с одним узлом, а сеанс из кластера с учетом топологии должен связываться только с этим узлом (или одним из его одноранговых узлов). на одном TCP-соединении. Наименее эффективные операторы должны касаться всех реплик (большинства узлов), но это будет обрабатываться узлом-координатором на самом кольце, поэтому даже для этих операторов Session будет использовать только одно соединение из приложения.

Кроме того, версии 2 и 3 используемого драйвером двоичного протокола Cassandra используют мультиплексирование в соединениях. Таким образом, хотя для одного оператора требуется хотя бы одно TCP-соединение, это одно соединение потенциально может обслуживать до 128 или 32k + асинхронных запросов одновременно, в зависимости от версии протокола (соответственно).

Просто обновление для сообщества. Вы можете настроить пул соединений следующим образом

private static Cluster cluster;

cluster.getConfiguration().getPoolingOptions().setMaxConnectionsPerHost(HostDistance.LOCAL,100);