Требования для QA выставляет заказчик, и мы их менять не можем.
Рынок квалифицированных php/python соглашусь очень небольшой, половина с чем общался Crawler в глаза не видели. У нас продуктовый аутсорс, то есть, у нас люди сидят на 1 проекте у заказчика и делают ему продуктовую разработку так скажем, пилят 1 продукт.
А ничего что они получили деньги и контракт только за счёт того, что он вне рабочее время пошёл и выучился, сдал экзамен и потом у заказчика выполнил работу? Или это не считается?
Сейчас мало кто идёт в ВУЗ в 16 лет, сейчас чаще в 18, т.к. в 7 лет в школу, и 11 лет обучения без перепрыгивания. В 22 года она как раз закончила бакалавриат и имела 1 год опыта работы.
Конечно на разных конференциях уже ходят 13-15 middle разработчики, но это явно не повод требовать 3 года опыта работы у студентки, которая училась на бюджете.
разрабы сциллы крайне не рекомендуют так делать, они делали её именно с расчётом полной утилизации оборудования, большая часть их клиентов сидит на мощных инстансах aws, и на очень мощном железе. и производительность будет существенно ниже у такой конфигурации по сравнению с 1 экземпляром бд.
эластик не модифицирует настройки ядра чисто под себя и 1 процесс, в отличии от сциллы. плюс эластик не совсем то с чем надо сравнивать большинство бд, плюс у эластика это проблема в его архитектуре и не умении в 2020 году в heap больше 64 гб, плюс у эластика много проблем с производительностью в целом на мощном железе, он просто не умеет его утилизировать. В отличии от той же сциллы, которая наоборот утилизирует железо по максимуму, нет ограничений по памяти, нет jvm.
сциллу нельзя, она оптимизирует систему под 1 свой процесс, вообще всю систему, иначе производительность будет хуже. вообще идея несколько бд держать на 1 сервере идиотизм.
нет смысла, scylla оптимизирована под ssd, у вас же чисто hdd и даже под коммит лог и кеши нет ssd, смысла со scylla нет, плюс scylla требует обязательной оптимизации дисковой подсистемы.
затем что scylla оптимизирована full под ssd, и направление работы с hdd разрабы уже говорили их не очень интересует, и их можно понять, у них мало клиентов на hdd, а большая часть вообще в амазоне.
commit log я вынес на nvme, но даже вы выше писали что он пишет потоково, а значит это была бы загрузка просто на запись, а не iops, тем более в ssd. я raid я максимально разгружал от кешей и тп.
я просто помню что по iops нагрузка на nvme была половина от data, я выше написал что я вынес, подробнее мне было некогда разбирать что и как грузит. А по iops у меня нагрузка почти фулл нагружала дисковый массив.(если брать iops диска и умножать на кол-во дисков), был сделан raid0 средствами mdraid через scylla_setup.
У меня было много update, это заставляло на много больше работать compaction, что в свою очередь и грузило диски. Во вторых я тоже полностью подводные камни не знаю, может ещё какой то кеш выносить надо было.
без ssd отдельного под систему и кеши смысла ставить cassandra нет. плюс что hbase что cassandra должны жить на отдельном от другого софта железа(за исключением spark, их лучше на одной ноде, если позволяет конфигурация)
SSD стали дешёвые, заказать ssd вполне реально, особенно учитывая сколько потом это будет экономить оборудования. Более того с выходом qlc ssd, можно вообще на них перейти и цена схожа будет с enterprise hdd. Плюс у вас нет update и потому запись у меня могла бы быть сильно больше.
На счёт xfs ссылку вряд ли дам, у scylla в было где то в бенчах, но про xfs я узнал на irc cassandra и из google рассылок.
помимо коммит лога есть ещё логи gc, server и debug, и в дефолте там очень не хилые размеры, не смотря на то что там чисто текст. Судя по 53М на дату, у меня логи эти в день были больше. чем у топикстартера дата на 5 дисках.
вы отключали swap? объём данных записанных у вас очень небольшой, у меня в сек запись была больше, мы за 3 недели записали full storage, при том что половина операций это update, плюс у вас не выставлена оптимизация под hdd, а по дефолту идёт оптимизация под ssd чтения\записи. это указывается в cassandra.yaml. Так же в cassandra-env.sh по дефолту стоит скрипт для оптимизации расходов ресурсов, но при больших нагрузках надо отключать скрипт, и ставить руками значения
MAX_HEAP_SIZE=«80G»
HEAP_NEWSIZE="*M" где за основу берётся кол-во физический ядер -2(если говорим о физ железе)
Воскресная статья о том, как в сбербанке искали способ не работать c Cassandra, по-другому статью назвать сложно. Ну а теперь по пунктам.
1) Вы используете deprecated GC, да в кассандре он по default, но проблема в том, default у кассандры не сделан под нагрузки, не говоря уже о bigdata. Необходимо было поставить G1GC, и 60-80 Gbyte Heap, далее начались бы ошибки в gc, в логах пишется, по факту влияет на сильно, и работает лучше чем если часто сбрасывать на диск. Есть лечение ставим www.azul.com/downloads/zulu-community/?&architecture;=x86-64-bit&package;=jdk ставим вот это и получаем отсутствие ошибок у GC, а так же ещё +50-60% к производительности cassandra(графики увы предоставить не могу, работа была для МО).
2) Непонятно как были настроены диски под Cassandra, непонятно как вообще было что настроено, начиная от sysctl.conf заканчивая лимитами. docs.datastax.com/en/dse/5.1/dse-dev/datastax_enterprise/config/configRecommendedSettings.html этой статьи хватает для начала, по мере работы добавится ещё несколько пунктов, а например я ставлю fs.file-max = 1073741824 vm.max_map_count = 1073741824 vm.dirty_bytes = 1073741824 vm.dirty_background_bytes = 10485760 (настройки тестил, ставил меньше, нашёл на github)
3) Для нормальной работы кассандра необходимо вынести на отдельный/е ssd saved_caches, key_cache, row_cache, counter_cache, thrift_prepared_statements_cache они не всегда даже будут использоваться, но вынести их на отдельный от /data накопитель обязательно необходимо.
Необходимо логи системы и cassandra держать на отдельном от data носителе. У меня был nvme под это дело, система+логи+кеши были на отдельном nvme, а data была на 24 hdd sas 7200 128 cache.
4) Cassandra работает существенно лучше на XFS, которую надо специально подготовить, проще всего это сделать через скрипт Scylla_setup, так же этот скрипт сразу настроит нужные для процессора настройки, а их там не мало. При желании можно самому прочесть скрипт и поставить руками настройки.
5) Cassandra не любит hyper-threading его отключение сильно снижает latency на больших нагрузках.
6) Cassandra не имеет под собой HDFS, поэтому её надо ставить на raid 0, в вашем случае вы работали с 1 диском, естественно у вас результаты были гораздо хуже чем с hbase, где это сделал за вас hdfs(образно, понятное дело, что там механизм иной, но суть в том, что нагрузка шла на все диски а не на 1 как в вашем случае).
В заключении, у меня было 3 ноды cassandra, кейс гораздо более сложный, была запись по 300к/с и 160к/с update, тоже rf3, и 3 ноды, запись длилась на показе заказчику 3 недели, и latency был ниже вашего. Да было по 800 мб чтение с data, и запись 500 мб, дисковая подсистема была почти полностью загружена.
Рынок квалифицированных php/python соглашусь очень небольшой, половина с чем общался Crawler в глаза не видели. У нас продуктовый аутсорс, то есть, у нас люди сидят на 1 проекте у заказчика и делают ему продуктовую разработку так скажем, пилят 1 продукт.
Конечно на разных конференциях уже ходят 13-15 middle разработчики, но это явно не повод требовать 3 года опыта работы у студентки, которая училась на бюджете.
без ssd отдельного под систему и кеши смысла ставить cassandra нет. плюс что hbase что cassandra должны жить на отдельном от другого софта железа(за исключением spark, их лучше на одной ноде, если позволяет конфигурация)
SSD стали дешёвые, заказать ssd вполне реально, особенно учитывая сколько потом это будет экономить оборудования. Более того с выходом qlc ssd, можно вообще на них перейти и цена схожа будет с enterprise hdd. Плюс у вас нет update и потому запись у меня могла бы быть сильно больше.
На счёт xfs ссылку вряд ли дам, у scylla в было где то в бенчах, но про xfs я узнал на irc cassandra и из google рассылок.
MAX_HEAP_SIZE=«80G»
HEAP_NEWSIZE="*M" где за основу берётся кол-во физический ядер -2(если говорим о физ железе)
1) Вы используете deprecated GC, да в кассандре он по default, но проблема в том, default у кассандры не сделан под нагрузки, не говоря уже о bigdata. Необходимо было поставить G1GC, и 60-80 Gbyte Heap, далее начались бы ошибки в gc, в логах пишется, по факту влияет на сильно, и работает лучше чем если часто сбрасывать на диск. Есть лечение ставим www.azul.com/downloads/zulu-community/?&architecture;=x86-64-bit&package;=jdk ставим вот это и получаем отсутствие ошибок у GC, а так же ещё +50-60% к производительности cassandra(графики увы предоставить не могу, работа была для МО).
2) Непонятно как были настроены диски под Cassandra, непонятно как вообще было что настроено, начиная от sysctl.conf заканчивая лимитами. docs.datastax.com/en/dse/5.1/dse-dev/datastax_enterprise/config/configRecommendedSettings.html этой статьи хватает для начала, по мере работы добавится ещё несколько пунктов, а например я ставлю fs.file-max = 1073741824 vm.max_map_count = 1073741824 vm.dirty_bytes = 1073741824 vm.dirty_background_bytes = 10485760 (настройки тестил, ставил меньше, нашёл на github)
3) Для нормальной работы кассандра необходимо вынести на отдельный/е ssd saved_caches, key_cache, row_cache, counter_cache, thrift_prepared_statements_cache они не всегда даже будут использоваться, но вынести их на отдельный от /data накопитель обязательно необходимо.
Необходимо логи системы и cassandra держать на отдельном от data носителе. У меня был nvme под это дело, система+логи+кеши были на отдельном nvme, а data была на 24 hdd sas 7200 128 cache.
4) Cassandra работает существенно лучше на XFS, которую надо специально подготовить, проще всего это сделать через скрипт Scylla_setup, так же этот скрипт сразу настроит нужные для процессора настройки, а их там не мало. При желании можно самому прочесть скрипт и поставить руками настройки.
5) Cassandra не любит hyper-threading его отключение сильно снижает latency на больших нагрузках.
6) Cassandra не имеет под собой HDFS, поэтому её надо ставить на raid 0, в вашем случае вы работали с 1 диском, естественно у вас результаты были гораздо хуже чем с hbase, где это сделал за вас hdfs(образно, понятное дело, что там механизм иной, но суть в том, что нагрузка шла на все диски а не на 1 как в вашем случае).
В заключении, у меня было 3 ноды cassandra, кейс гораздо более сложный, была запись по 300к/с и 160к/с update, тоже rf3, и 3 ноды, запись длилась на показе заказчику 3 недели, и latency был ниже вашего. Да было по 800 мб чтение с data, и запись 500 мб, дисковая подсистема была почти полностью загружена.