Насчет сжатия — мы тестили на YCSB, которая делает чистый рандом и тут смысла жать не имело.
Насчет более реальных данных… Я помню как-то делал короткий тест и первое впечатление было такое что не понравилось и я отложил, но не исключаю что нужно было проделать все более тщательно.
SSD к нам приедут примерно в августе и это будет интересно)
Согласен, определенные фишки конечно в платной версии есть, я имел в виду, что они не выглядят как строго обязательные, без которых невозможно нормально работать. Вполне допускаю что на самом деле монетизация идет полных ходом, однако со стороны не вполне понятно за счет чего именно. Условно говоря я прямо сейчас могу развернуть 50 инстансов Scylla на кластере, залить туда пару ПБ и это будет работать. Зачем тогда платить и тем более платить много?
В отличие от Aerospike, где я на бесплатной версии могу только 600 ГБ поставить. Тут уже понятно что серьезному бизнесу с объемами придется платить за entreprise по любому.
Рейтинг db-engines не про монетизацию. Иначе глядя на место в рейтинге HBase можно было бы подумать, что они успешный бизнес, а не энтузиасты.
А на ту мысль, что сейчас не особо монетизируется, наводит тот факт, что никаких ограничений по функциональности в бесплатной версии нет (возможно есть, но я их не увидел, если так прошу указать, где их можно посмотреть). Что в свою очередь резко снижает количество желающих(=нуждающихся) заплатить. Что равно формулировке «не особо монетизируется».
Конечно какая-то отдельная большая компания может решить платить просто за поддержку 24/7, но это явно не будет столько же стоить сколько можно брать за включение того или иного функционала (число серверов, объем данных, консистентность и т.д.).
Был бы весьма признателен если сможете прокомментировать нестабильность динамики ops в ходе Insert для Scylla или дать контакты коллег, которые могут прояснить этот вопрос. Могу выслать логи ycsb (хотя стоит сразу сказать что в них ничего кроме колебания скорости нет и ошибок нет) и iostat, если требуется. Есть конфиги Scylla еще.
Спасибо. Так как redis, memcached и tarantul относятся скорее к классу in-memory, поэтому до них руки вряд ли дойдут. Сейчас меня интересуют решения для BigData, есть в планах протестировать в первую очередь самые популярные из этого класса.
Судя по тому что Scylla до сих пор не начали особо себя монетизировать и по отсутствию ее в рейтинге g2, а также по отсутствию в https://www.datanyze.com/market-share/databases--272, не сильно много кто использует.
В качестве key-value прекрасно работают все из перечисленных. Собственно ycsb тем и удобна, что одни и те же операции позволяет выполнять на разных БД.
Спасибо за интересный комментарий. То что касается рандомной операции пропуска и представления клиенту, это хороший вариант, когда клиенты могут "договориться" между собой. Но представьте себе случай, когда один потребитель (физически это может быть сотня потоков), запрашивает данные. Он же не знает, есть ли другие потребители сейчас. Если есть, то в общих интересах было бы не просить все кешировать (чтобы избежать GC). А если других читателей нет, то можно кешировать все (допустим потому, что все поместится в кеш). Таким образом это не получится отдавать чисто на откуп клиенту, все равно придется задействовать RS для обмена информацией и ещё надеяться, что клиенты захотят делиться кешем с другими клиентами, что и сложнее чисто технически и не всегда возможно так сказать "политически".
Рандомность же даёт честную пропорцию, все потребители оказываются в равном положении, ведь управлять офсетами в HFiles они не в состоянии (т.е. не смогут пробиться к кешу в обход других).
Насчёт скорости чистого BlockCache без оверхеда. Если совсем без обращений к файловой системе более миллиона записей в секунду, я писал про такие тесты тут: https://habr.com/ru/company/sberbank/blog/484096/
Если же начинается обращения к HDFS, то лучше всего на самом деле сделать тесты и узнать наверняка, но я сейчас без доступа к стенду. Добавлю ответ когда появится возможность проверить на практике (возможно через неделю-две только).
Печально… А есть возможность высадить к примеру две ноды на один сервер? Или там завязано общение на некий порт и по любому нужно поднимать второй ip адрес?
Да, МС был лишний, не подумал про кеш. Версия github.com/cloudera/hbase/tree/cdh5-1.2.0_5.14.2
Тот патч, о котором я писал, играет роль только при кол-во регионов на RS от 800-1000, так что можно не запариваться. Задумал ScyllaDB кстати так же проверить, дам знать что получится)
Насчет более реальных данных… Я помню как-то делал короткий тест и первое впечатление было такое что не понравилось и я отложил, но не исключаю что нужно было проделать все более тщательно.
SSD к нам приедут примерно в августе и это будет интересно)
«On Red Hat / CentOS edit /etc/sysconfig/scylla-server, and add --smp 2 --overprovisioned to restrict Scylla to 2 logical cores.»
docs.scylladb.com/getting-started/scylla_in_a_shared_environment
В отличие от Aerospike, где я на бесплатной версии могу только 600 ГБ поставить. Тут уже понятно что серьезному бизнесу с объемами придется платить за entreprise по любому.
А на ту мысль, что сейчас не особо монетизируется, наводит тот факт, что никаких ограничений по функциональности в бесплатной версии нет (возможно есть, но я их не увидел, если так прошу указать, где их можно посмотреть). Что в свою очередь резко снижает количество желающих(=нуждающихся) заплатить. Что равно формулировке «не особо монетизируется».
Конечно какая-то отдельная большая компания может решить платить просто за поддержку 24/7, но это явно не будет столько же стоить сколько можно брать за включение того или иного функционала (число серверов, объем данных, консистентность и т.д.).
Scylla(клиент+сервер) = CpuUsage_A -> OperationsPerSecond_X
Aerospike(клиент+сервер) = CpuUsage_B -> OperationsPerSecond_Y
Где OperationsPerSecond_X < OperationsPerSecond_Y
Иными словами клиенты и база совместно более требовательны к ресурсам что при прочих равных ведет к меньшей производительности.
В нашем случае клиенты как правило на тех же нодах что и инстансы БД, поэтому особенно интересна именно такая комбинация.
Любят они все собирать почтовые ящики, есть такое) Однако можно скачать community (и даже enterprise) без смс например под CentOS через wget по прямой ссылке:
https://www.aerospike.com/download/server/latest/artifact/el8
Другие варианты тут:
https://www.aerospike.com/docs/operations/install/linux/index.html
Спасибо. Так как redis, memcached и tarantul относятся скорее к классу in-memory, поэтому до них руки вряд ли дойдут. Сейчас меня интересуют решения для BigData, есть в планах протестировать в первую очередь самые популярные из этого класса.
Судя по тому что Scylla до сих пор не начали особо себя монетизировать и по отсутствию ее в рейтинге g2, а также по отсутствию в https://www.datanyze.com/market-share/databases--272, не сильно много кто использует.
В качестве key-value прекрасно работают все из перечисленных. Собственно ycsb тем и удобна, что одни и те же операции позволяет выполнять на разных БД.
Да, так и есть, за пару-тройку часов написал, хотелось уже выложить результаты, свопнуть так сказать из оперативки и заняться плотно другими делами)
Del
Спасибо за интересный комментарий. То что касается рандомной операции пропуска и представления клиенту, это хороший вариант, когда клиенты могут "договориться" между собой. Но представьте себе случай, когда один потребитель (физически это может быть сотня потоков), запрашивает данные. Он же не знает, есть ли другие потребители сейчас. Если есть, то в общих интересах было бы не просить все кешировать (чтобы избежать GC). А если других читателей нет, то можно кешировать все (допустим потому, что все поместится в кеш). Таким образом это не получится отдавать чисто на откуп клиенту, все равно придется задействовать RS для обмена информацией и ещё надеяться, что клиенты захотят делиться кешем с другими клиентами, что и сложнее чисто технически и не всегда возможно так сказать "политически".
Рандомность же даёт честную пропорцию, все потребители оказываются в равном положении, ведь управлять офсетами в HFiles они не в состоянии (т.е. не смогут пробиться к кешу в обход других).
Насчёт скорости чистого BlockCache без оверхеда. Если совсем без обращений к файловой системе более миллиона записей в секунду, я писал про такие тесты тут: https://habr.com/ru/company/sberbank/blog/484096/
Если же начинается обращения к HDFS, то лучше всего на самом деле сделать тесты и узнать наверняка, но я сейчас без доступа к стенду. Добавлю ответ когда появится возможность проверить на практике (возможно через неделю-две только).
Печально… А есть возможность высадить к примеру две ноды на один сервер? Или там завязано общение на некий порт и по любому нужно поднимать второй ip адрес?
Да, так как когда вовсю начинали наваливать то ловили Above memstore limit.
>>Как по мне так намного чаще регионы зависают в transition по разным причинам
Хе хе, есть такое дело))
Тот патч, о котором я писал, играет роль только при кол-во регионов на RS от 800-1000, так что можно не запариваться. Задумал ScyllaDB кстати так же проверить, дам знать что получится)