я не хочу гнать маркетинговую инфу, просто попробуйте сами, и если что я постараюсь помочь, или сам или в нашем слаке помогут

Нет. У нас контекст разговора задан вопросом о распределенном хранилище. Совершенно вторично nosql ли это.

ну значит я влез немного позже чем контекст был задан. Кстати, о хранилищах, ceph заявили в прошлом году что портируют весь свой код на seastar framework, а это та самая штука на которой построили Сциллу

@dyasny вы всегда так усиленно сциллу будете рекламировать? =)

я не против, но когда начинают показывать только плюсы и игнорировать минусы, то начинается полное игнорирование и отговаривание людей от использования данных технологий

при больших updates ведёт себя не очень хорошо (сейчас лочится партиция)
https://github.com/scylladb/scylla/issues/2578

в некоторых случаях реактор может подвисать на секунды и десятки секунд, уже вагон багов было по этому поводу, из последнего
https://github.com/scylladb/scylla/issues/4405

отсутвие нормального тюнинга и настройки throughput на диск/сеть/etc при компакшене-репликации, стандартный автотюнинг сциллы не всегда работает корректно

я понимаю что работаете в компании-разработчике, но пихать сцылу как затычку в каждую бочку может превратиться в то, как сейчас многие монгу воспринимают: “спасибо, не надо”

просто из-за того что на волне хайпа затянули туда, где ей не место

И педис!

хотя в настройках все прописал как рекомендовано на hortonworks.com

От души))

Можно в двух словах, зачем нужен NFSGateway сервис в HDFS?
Какие-то особые кейсы записи данных в hdfs?
Или может используется в других сервисах каких-то?

можешь замонтировать себе hdfs лоально на тачку

Если ты хочешь писать на локальный диск и зеркалировать эти данные в HDFS. Например, если у тебя есть контрагент, который только в push режиме может отправлять данные на выделенную ноду.

Отлично, спасибо.

Крайне шаткая вещь

Можно смело ставить на крон ежедневный umount ; mount /mnt/hdfs

еще лучше делай это перед запуском очередного джоба 😉

Инженеры! Пытаюсь запустить спарк джобу с использованием другой версии спарк, чем установленна. Действую по этой инструкции https://stackoverflow.com/questions/53928408/how-to-use-different-spark-version-spark-2-4-on-yarn-cluster-deployed-with-spa Но все равно запускается ванильная версия спарка

Это код, код идеальным не бывает. Если не хватает конкретных фичеров мы всегда рады запросам на гитхабе

Ну а баги чинятся, куда они денутся?

@dyasny извиняюсь, но опять маркетинговый булшит
"мы не знаем ваш ворклоад, но давайте вы попробуете наше решение, а вдруг прокатит?"

на практике это зачастую прокатывает на PoC в 10GB данных, а когда оказывается 10+TB уже в проде, то
добро пожаловать в наш слак чат разрабов и вот эту платную подписку купите на саппорт, может что-то придумаем но не обещаем

теперь более предметно как инженеры про seastar:
есть знакомые c/c++ девелоперы которые пытались seastar использовать
да, они подтвердили что он написан хорошо и предоставляет много отличных абстракций,
но конкретно они его у себя выпилили, так как он принуждает использовать его подход к обработке, что для них не совсем подходит
в частности: за ядром закрепляется обработчик и sharing nothing, с одной стороны линейный скейл и cpu друг другу в кеш не лезут, не нужны синхронизации, с другой это всё хорошо работает пока у вас не cpu bound задачи

перейдём теперь на scylladb и как она его использует:
каждая партиция закреплена за ядром
запросы на одну партицию обрабатываются в пределях одного потока, что даёт нам преимущества в виде отсутствия синхронизаций и перекидывания данных между ядрами

до тех пор пока это IO bound задачи:
1) вставить данные потоком
2) вернуть данные прочитав с диска

то их async на диск и внутренний асинхронный процессинг и reactor себя показывает очень хорошо
так как решает многие вопросы которые были у кассандры (мы не ждем данных с диска, а можем процессить другие запросы)

но если мы нарываемся на другие задачи которые больше CPU bound, то начинаются проблемы:
1) compaction  - scylladb пытается динамически предугадать размер сколько мы должны прочитать следующий блок, чтобы потом его быстро отпроцессить, причем соблюсти баланс
а) захватим меньше - сделаем быстро - нужно ждать пока следующий квант времени дадут, скорость компакшена может просесть
б) захватим много - процессим долго - весь процессинг запросов на этой партиции останавливается (get/put/etc выстраиваются в очередь, latency растет, все же помнят что одна партиция - один поток)

проблема что один и тот же блок по размеру может занять совершенно разное время в зависимости это были просто потоком таймсерии (можно просто sorted merge делать, можно сказать что упираемся в io) или вагон updates (тут еще нужно уже считать и находить кто последний был, объединять разные колонки и тд, намного больше cpu понадобится, и подход кассандры с отдельными потоками на compaction уже не кажется таким уж плохим)

2) record updates  - уже существующих записей, опять же если запись существует, то merge её больше упирается в cpu при расчётах, плюс лок на memtable

то есть 2578 и 4405 это не совсем баги, их можно назвать издержками принятых архитектурных решений
и так быстро их не исправить
именно поэтому они висят уже годами и их пытаются решить лишь подставляя очередные костыли


ещё раз: я не против scylladb или любой другой технологии пока дискусия идёт в рамках "опишите ваш ворклоад - у нас есть продукт с такими плюсами/минусами - в вашем случае он походит/не подходит потому что..."


но когда всем пытаются впарить что-то даже не выясняя как это будут использовать, очередную серебрянную пулю которая решит все ваши проблемы, то это совсем не инженерный подход, а напоминает классику продажников

такое было с хадупом и общим подходом nosql, потом монгой, потом с кликхаусом, сейчас вот со сциллой

а в чем проблема возникает?

как показала моя печальная практика, 70% разрабов берут инструменты вообще не думая