Нет ну можно сэмулировать namenode-у, которая для записи будет отдавать адрес нужного инстанса БД, и писать в эту кучу независимых БД. Потом накрутить движок вычислений поверх этого. Получится хадуп :)

https://github.com/sorintlab/stolon

Это HA

Если коротко базы не масштабируются.

Нет ну можно сэмулировать namenode-у, которая для записи будет отдавать адрес нужного инстанса БД, и писать в эту кучу независимых БД. Потом накрутить движок вычислений поверх этого. Получится хадуп :)

Это называется greenplum

Тогда у меня какое то неправильное понимание горизонтального масштабирования.

Это называется greenplum

Есть ещё Pg XC, PG XL

Тогда у меня какое то неправильное понимание горизонтального масштабирования.

Если попробовать коротко, должна быть возможность писать количеством клиентов пропорциональным размеру кластера. И иметь возможность прошерстить все данные за время обратно пропорциональное размеру кластера.

Тогда у меня какое то неправильное понимание горизонтального масштабирования.

Жертва маркетинга прост ):

Жертва маркетинга прост ):

СТОКГОЛЬМСКИЙ СИНДРОМ

Если попробовать коротко, должна быть возможность писать количеством клиентов пропорциональным размеру кластера. И иметь возможность прошерстить все данные за время обратно пропорциональное размеру кластера.

Насчет времени спорно

Почему?

Потому что обычно это в вертикальном

Не понятно, можно разъяснить подробнее?

Горизонтальное масштабирование может давать параллельность обработки, но не дает гарантий сокращения времени получения информации

Всё равно непонятно. Если я делаю фулскан, фильтр строк по регекспу например, я не должен ожидать что при большем кол-ве нод это отработает быстрее?

А если вы будете делать по условию, которое находится на одной ноде?

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

Есть k-safe, но и он не даст сокращение времени пропорционально количеству нод

Мы говорим про чтение и запись. Про алгоритмы речи не идёт, очевидно.

Ну вернее идёт если алгоритм параллелится.

Так я про то, как писать и читать

А если вы будете делать по условию, которое находится на одной ноде?

Это что означает?)

Про то, как писать

ну такими аргументами мы далеко не уйдём)

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

Ну и горизонтальное масштабирование делают не столько для параллели, сколько для отказаустойчивости. Поэтому реальный выхлоп от количества нод 2k+1 будет в лучшем случае k

У вас есть обрывки верных мыслей, но в целом всё не так. 2k+1 -> k это вы откуда-то вырвали из какой-то доки по MR и обобщаете на всё. Конечно же для распараллеливания, это была основная цель.

Пересечения с отказоустойчивостью есть обширные. Но утверждать что это для HA а не для ускорения - неверно.

Берём простой фулскан, каждую строку в данных заменяем на её половину. Где тут 2k+1 -> k, непонятно.

Просто вы мыслите только в рамках HA, я же мыслю в рамках баз, в основном реляционных

кто-нибудь настраивал SSL на клоудере?

кто-нибудь настраивал SSL на клоудере?

Было дело.

Было дело.

Есть какой-нибудь толковый гайд по этому делу?

Только дока с их сайта. Я не ней делал

Т9 блин.. я по ней делал

кто-нибудь настраивал SSL на клоудере?

Я делал.

Я делал.

Тоже по доке? На сколько нод кластер?

Тоже по доке? На сколько нод кластер?

Это почти неважно.

Что-то по доке, что-то коллеги подсказали.

#job В один из крупных банков России требуется системный администратор Hadoop. Заниматься предстоит - Установка, настройка и поддержка различных компонентов экосистемы Hadoop. - Разработка DR решений. - интеграцией Big Data решений с системами банка; - разработка системы подготовки банковской отчетности - участие в DevOps процессах обслуживания и развития распределенного кластера и устранения неполадок. Надо иметь опыт - администрирования ОС семейства Linux. - внедрения и поддержки кластеров данных на основе экосистемы Hadoop (HDFS, YARN, MapReduce, Spark, Impala). - Желательно опыт работы с Cloudera сборкой. - работы с высоконагруженными системами 24/7 Знание английского, языков программирования (java, python ...), OpenSource инструментов – очень приветствуется. ЗП 150-170 net после собеседования, ДМС. Офис в центре Москвы.

кто-нить уже завел хадупа с 10ой jdk?

на девятой то вроде бывают проблемы

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

забей зачем она?)

еще более втюненый г1 и грааль

ну лан, хрен с ним с гц, грааль

заводил но не на spark

так и я не про спарк

в ближайщии дни дажее планировал померять с графиками итд

у меня g1 в 8 нормально 50гб оперативы отрабатывает, но все равно интересно померять

кто-нить уже завел хадупа с 10ой jdk?

а это возможно?

а это возможно?

зачем ты задаешь на мой вопрос такой же вопрос?)

а почему нет?

*не спарк и не hadoop, просто scala сервис

Смысл в десятке, если она будет допиливаться + хадуп экосистема не перешла на 9

что значит 10ка будет допиливаться? через полгода 11

Кстати были статьи что спарк и флинк в некоторых задачах лучше использовать не с г1 а с кмс

вот тут надо опять же версии jvm уточнять, потому что g1 8ки, 9ки и 10ки не одно и тоже

в последнем случае сильно (паралелльная сборка одного из этапов)

11 это LTS, на неё и есть смысл смотреть. десятка вообще не актуальна, её поддерживать не будут.

%)

да и 9ка тож

угу. девятку потыкать тока ради новых фич

Мне кажется, ближайшие годы все будут сидеть на 8, и глядя на очередной скорострельный релиз Java думать "что это было?" или "шо, опять?!". :-)

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

а также рублики неочевидное и невероятное в jave x

и сидеть на спарке 1.6, а по пятницам в баре вспоминать причмокивая времена джавы 6 и спарка 1.3

Мне кажется, ближайшие годы все будут сидеть на 8, и глядя на очередной скорострельный релиз Java думать "что это было?" или "шо, опять?!". :-)

поддержка уже почти закончилась у 8ки, security-update-ов не будет, так что не будут сидеть.. хочешь-не хочешь, а переходить надо

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

а ораклы его каждые два года новый собираются выпускать?

а ораклы его каждые два года новый собираются выпускать?

сложный вопрос... http://www.oracle.com/technetwork/java/eol-135779.html 9ка вообще анонсируется как переходная, типа - сваливайте с нее как только сможете по поводу 10ки - я не до конца табличку понял.. возможно как в убунте будет - раз в пол года релиз, и LTS с какой то продленной поддержкой?

LTS будет 11

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

Типа того.

Есть какой-то не новый проект на Java, выходит новая Java. Проект не тривиальный, нужен период ожидания, пока пофиксят косяки новой версии, пока проверят совместимость новой версии с кодом проекта, - и тут же выходит следующая версия Java. И так далее.

Скромнее надо быть с темпом релизов, IMHO. Давать время освоиться.

ну с 9кой фактически уже поигрались немного - проект запустился с ней без каких то танцов с бубном... если кто любит спринг с хибернейтом - то у них будут некоторые проблемы - но они лечатся изменением строки запуска https://dou.ua/lenta/articles/problems-with-java-9/

ну так будут переходить с одного LTS на другой, полтора года как минимум. по крайней мере у нас план таков

#job #вакансия #москва Добрый вечер! Ищу в команду DBA по направлению Big Data – в крупную процессинговую компанию. Описание здесь: https://hh.ru/vacancy/24204641 По поводу зарплаты – не могу, к сожалению, озвучить вилку, но компания опирается на требования кандидата и предлагает очень привлекательные условия.

Вилку озвучить - придётся.

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

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

помню прекрасно момент, когда вышла java8 а в компании с умным видом объясняли соискателям почему java6 пока лучшее решение

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

Я про 9+

Раньше как-то проще и понятнее было.

про модули в 9 уже говорят с 7 версии, вроде бы как

одно дело говорят, другое дело как реализуют в итоге

мы вот приложение на 1.3 MLoC с 6 на 8 мигрировали — пришлось только пару сотен тестов подправить, да всякие мелочи. в принципе, нормально вышло с обратной совместимостью.

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

Надо было сразу на Scala всё писать. :-)

кстати да.. java и scala совместно живут конечно.. но как то совсем криво и неудобно

скала это write-only язык. когда у тебя два человека c PhD одну лямбду под спарк пишут в четыре руки, то ещё ничё. а вот если три десятка обалдуев без особого образования пилят ынторпрайзного монстра, то несколько иной коленкор. скала там только отдельно стоящим модулем.

скала это write-only язык. когда у тебя два человека c PhD одну лямбду под спарк пишут в четыре руки, то ещё ничё. а вот если три десятка обалдуев без особого образования пилят ынторпрайзного монстра, то несколько иной коленкор. скала там только отдельно стоящим модулем.

а есть рид онли языки?

:))

и тип стратегии; at least once, etc

Перловка