У нас есть схема тестового кода, которая использует java-клиент для выполнения операций Cassandra INSERT/READ/QUERY. Мы создали единую установку узла с физическим сервером со следующей конфигурацией.Производительность Cassandra медленная со вторичными индексами
- ОС Linux SuSE 11.SP2
- память на физическом сервере 32GB
- Своп память 32GB
- процессор имеет 4 ядра с каждым 2ГГц
- Commit журнала на SSD, проживающим диск с 100GB (RAID-0 и локально к системе)
- Журнал данных, находящийся на диске SAS с 7 ТБ (5 дисков SAS, настроенных с использованием RAID-0 и локальных для системы).
- JRE версии 1.7.0.25
- Cassandra Version (раздел по умолчанию) 1.2.5
- MAX КУЧА РАЗМЕР 8GB
- HEAP_NEW_SIZE 400MB (100MB на ядро в соответствии с рекомендацией Cassandra).
ПРИМЕЧАНИЕ. Увеличение количества процессоров от 4 до 8 ядер помогло улучшить производительность, но очень мало.
Мы используем ниже тестовую схему с 5 вторичными индексами.
"CREATE TABLE test_table (
hash_key text PRIMARY KEY,
ctime timestamp,
ctime_bucket bigint,
extension text,
filename text,
filename_frag text,
filesize bigint,
filesize_bucket bigint,
hostname text,
mtime timestamp,
mtime_bucket bigint
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.000000 AND
gc_grace_seconds=864000 AND
read_repair_chance=0.100000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'SnappyCompressor'};
CREATE INDEX test_table_ctime_bucket_idx ON test_table (ctime_bucket);
CREATE INDEX test_table_extension_idx ON test_table (extension);
CREATE INDEX test_table_filename_frag_idx ON test_table (filename_frag);
CREATE INDEX test_table_filesize_bucket_idx ON test_table (filesize_bucket);
CREATE INDEX test_table_mtime_bucket_idx ON test_table (mtime_bucket);"
Мы пытаемся следующий INSERT и READ тесты с параметрами настройки по умолчанию, однако мы видим очень медленно чтения и записи. Чтение значительно медленнее, чем производительность записи. Когда мы удаляем вторичные индексы из вышеприведенной схемы, мы получаем примерно в 2 раза лучшую производительность, однако мы все же чувствуем, что есть возможность улучшить производительность с настройкой параметров Cassandra. Однако со вторичными индексами производительность очень плохая.
- 1M ВСТАВИТЬ обеспечивает около 7k OPS/сек
- 10M ВСТАВИТЬ обеспечивает около 5K OPS/сек (несколько капель производительность)
- 100M ВСТАВИТЬ обеспечивает около 5K Ops/сек
- 1000MM ВСТАВИТЬ обеспечивает около 4.5 K Ops/sec
Если мы удалим вторичные индексы, мы получим производительность около 11K Ops/sec для всех перечисленных выше нагрузок.
- 1M READ обеспечивает около: 4.5K Ops/сек
- 10M READ обеспечивает только около: 225 OPS/сек (резко падает производительность)
Мы хотели бы знать, из вашей группы экспертов о том, какие конкретные параметры настройки должны применяться для операций WRITE и READ для повышения производительности. Как мы можем отложить уплотнение и GC, чтобы избежать узкого места производительности, которое может сыграть определенную роль во время этих операций. Если есть какие-либо системные настройки, которые необходимо применить, мы хотели бы узнать из вашей команды экспертов.
Мы пытаемся выполнить следующие параметры настройки (в Cassandra.yaml и Cassandra-env.sh), однако мы не добились значительного улучшения производительности записи и чтения.