Мне интересно зачем

Т.е. Какие потребности вы имеете

И как хотите из закрыть

чорт!

Главное, чтобы не началось

Т.е. Какие потребности вы имеете

Судя по всему - мы, возможно, будем партнерами партнером Мезосферы

Не знаю, какая это потребность

В деньгах?

Это бизнесовая потребность

:)

https://github.com/tsaikd/gogstash

гагстэш))

Блин, ну если не кубернетис/dcos, тогда что? Coreos/fleet?

центос и паппет Никита )

:(

а еще tinc для сеточки в DO )

https://v1.std3.ru/bb/62/1463583825-bb62457bcfc86be8584a7f0e24942b6b.gif

Вот, кстати, ты какую задачу решаешь tinc?

https://v1.std3.ru/bb/62/1463583825-bb62457bcfc86be8584a7f0e24942b6b.gif

еще его можно научить ругаться как пирата, и повязку на глаз повесить

Сделать общий l2 для хостов?

Сделать общий l2 для хостов?

по факту да, потому что у DO нет такого.

есть еще meshbird но руки как то никак.

Вообще я хотел не об инструментах поговорить, а о задачах

Проблемах, вызовах, если угодно

как жить с персистнетными данными требующими хорошего latency в докерах ?

во ту меня есть ES кластер на 3х машинках, там по 1ТБ данных на каждой. туда ходит аналитика(люди) и постоянно что то читают и постоянно туда льются данные.

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

но мне хочется иметь хороший latency до данных и при этом их надежно где то хранить.

на самом деле идея чуть страшнее, вот хочу я динамически скейлить hbase на рид, с восстановление локальности данных и всего такого.

*главное чтобы чистяков не понабежал )

никита ты гдеее )

А? Звали?

на самом деле идея чуть страшнее, вот хочу я динамически скейлить hbase на рид, с восстановление локальности данных и всего такого.

Хехехех

Заскейлить на рид LSM-tree это хорошо

=)

Следующий шаг - получить миллион долларов приза за мужскую беременность

И это не выглядит невероятным по сравнению с

Блин, я афк внезапно, 20минут

Я пугаюсь, когда вижу в профессиональном сообществе слово “внезапно”

Следующий шаг - получить миллион долларов приза за мужскую беременность

а что типа реплии регионов не помогут ?

Если мы говорим об уменьшении latency - то там поможет только много блочного кэша

И довольно частые major compactions

Которые, правда, пока проходят, просаживают производительность

kubernetes + fleet + coreos)

kubernetes + fleet + coreos)

а какие задачи решили этим стеком?

Если мы говорим об уменьшении latency - то там поможет только много блочного кэша

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

как жить с персистнетными данными требующими хорошего latency в докерах ?

а прием тут докер-то?

ты вызовов просил )

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

Ниже некоторого порогового лейтенси ты так не уйдешь

Ты же делаешь полосу шире (и это хорошо, да)

Но минимальный логический субъект поиска по ключу - регион

А регион - это либо один файл, либо несколько

да, но лейтенси тут уже опредлеяет как раз локальность данных и кеш локальный. не ?

И, когда файлов несколько - пройтись надо будет по всем

Ну вот кэш работает только для тех данных, которые уже читали

А при холодном чтении придется лезть в регион

А там может быть пачка файлов

Да, конечно, там к ним приделаны блум фильтры (если приделаны)

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

ты вызовов просил )

чет забыл уточнить, в контексте контейнеров, CI/CD и прочего)

а. и они вымываться будут постоянно. ты про это ?

ну я это вижу как меньшую проблему...

Но если блум даст фолс позитив - придется слазить в каждый фаел

ERROR: S client not available

А если там еще и несколько версий - придется выбрать последнюю

а. и они вымываться будут постоянно. ты про это ?

Да, если воркинг сет большой

ну это вроде как актуально для любой базы будет.

вон постгря потому и опрерирует сама страничками. похожие проблемы решает не ?

Вот постгря-то, как раз, плохо оперирует страничками сама

У нее, как раз, double caching

они утверждают обратное

Гиде?

Я с Олегом Бартуновым этот вопрос обсуждал вот месяц назад

там теперь mmap, вроде

Ай, остановитес

мне фил сказал!!11

Речь о том, что страница лежит и в shared_buffers и в файловом кэше

И mmaped file проходит через файловый кэш, конечно же

То есть - там сейчас нет O_DIRECT

Я хожу сейчас а семираы от постгреспро и они советовали отдавать побольше постгре

И мы его попробуем вкрутить

Я хожу сейчас а семираы от постгреспро и они советовали отдавать побольше постгре

Ну - это дельный совет

Но все равно будет double caching

И это лишнее - файловый кэш надо отрывать

Но это в коде надо ковырять

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

Ну да

Более специфичный кэш лучше работает, чем кэш общего применения

Более специфичный кэш лучше работает, чем кэш общего применения

это да.

Господа в Париже

А здесь девопсы

я нет, я с Парижу решил вас почитать

=))