Некоторые другие ответы были направлены на производительность записи, но это не то, о чем вы спрашивали - вы спрашивали о чтениях.
Производительность некэшированного чтения на жестких дисках неизбежно будет низкой как у Cassandra, так и у Scylla, потому что чтение для каждого диска требуется несколько поисков на жестком диске, и даже лучший жесткий диск не может выполнить больше, чем, скажем, 200 таких поисков в секунду. Даже с RAID нескольких из этих дисков вы редко сможете выполнять, скажем, более 1000 запросов в секунду. Поскольку современный многоядерный процессор может выполнять на несколько порядков больше процессорной работы, чем 1000 запросов в секунду, в случаях как Сциллы, так и Кассандры вы, скорее всего, увидите свободный процессор. Таким образом, основное преимущество Scylla, заключающееся в использовании гораздо меньшего количества ЦП на запрос, даже не имеет значения, когда диск является узким местом в производительности. В таких случаях я ожидаю, что производительность Сциллы и Кассандры (я предполагаю, что вы измеряете пропускную способность, когда говорите о производительности?) Должна быть примерно одинаковой.
Если, тем не менее, вы видите лучшую пропускную способность от Кассандра, чем Сцилла, есть несколько деталей, которые могут объяснить, почему, помимо общих проблем неправильной конфигурации клиента, поднятых в других ответах:
Если у вас низкие суммы из данные, которые могут поместиться в памяти, политика кэширования Cassandra лучше для вашей рабочей нагрузки. Cassandra использует кеш страниц ОС, который читает целые страницы диска и может кэшировать несколько элементов за одно чтение, а также несколько записей индекса. В то время как Scylla работает по-разному и имеет кеш строк - только кеширует данные чтения c. Кэширование Scylla лучше для больших объемов данных, которые не помещаются в памяти, но гораздо хуже, когда данные могут помещаться в памяти, пока весь набор данных не будет кэширован (после того, как все будет кэшировано, оно снова станет очень эффективным).
На жестких дисках детали сжатия очень важны для производительности чтения - если в одной настройке у вас есть больше sstables для чтения, это может увеличить количество операций чтения и снизить производительность. Это может измениться в зависимости от вашей конфигурации уплотнения или даже случайно (в зависимости от того, когда уплотнение запускалось в последний раз). Вы можете проверить, объясняет ли это ваши проблемы с производительностью, выполнив основное сжатие («nodetool compact») в обеих системах и проверив производительность чтения после этого. Вы можете переключить стратегию сжатия на LCS, чтобы обеспечить лучшую производительность чтения с произвольным доступом за счет увеличения объема работы по записи (на жестких дисках это может быть полезным компромиссом).
Если вы измеряете производительность сканирования (читаете всю таблицу), а не читаете отдельные строки, возникают другие проблемы: как вы, возможно, слышали, Scylla подразделяет каждый узел на сегменты (каждый фрагмент представляет собой один процессор). Это фантастика c для работы с ограниченным ЦП, но может быть хуже для сканирования небольших таблиц, поскольку теперь каждый sstable меньше и количество смежных данных, которые вы можете прочитать, прежде чем искать снова, меньше.
Я не знаю, какое из этих различий - или что-то еще - приводит к снижению производительности вашего варианта использования в Scylla, но я прошу иметь в виду, что все, что вы исправите, ваше производительность всегда будет плохой с жесткими дисками. С помощью SDD в прошлом мы измеряли более миллиона запросов чтения с произвольным доступом в секунду на одном узле. Жесткие диски не могут приблизиться. Если вам действительно нужна оптимальная производительность или производительность за доллар, SDD - это действительно путь к go.