после слов «вполне могу» желательно бы список продуктов на уровне hadoop/ignite =)
ravendb это в лучшем случае couchdb, но даже со своим rest интерфейсом очень часто проигрывает в измерениях.
hadoop это полноценная платформа поверх и совместно с которой крутится очень много чего: mapreduce, spark, flink, storm, hbase, accumulo, phoenix, cassandra, kafka и можно продолжать очень долго
у MS была хорошая попытка в виде dryad, правда они её слили, а вот идеи из неё уже и вошли в spark/flink.
вообще в сфере перемалывания и nosql доминируют 2 языка java и c++, местами другие jvm языки в виде scala и clojure.
и тут зачастую вопрос не в том что java туда зашла раньше, а в том что никто ради хадупа не будет покупать еще пару сотен лицензий на windows server, если от хост системы только и требуется что выступать пускателем кода, никаких групповых политик или еще чего.
почти все перечисленные решения могут работать и на windows (не всегда оптимально, но могут), правда в реальной жизни я в работе только linux видел.
с появлением .net core может что-то и поменяется, но тут начинается уже битва рантаймов (именно поэтому некоторые продукты отходят от jvm и переходят на c++), и тут опять же у jvm пока рантайм смотрится чуть лучше. на данный момент я не видел в жизни как себя ведет gc у .net на хипах по 64GB и выше, а в реальной жизни встречались и выше.
признаюсь, что плотно под .net не разрабатываю, но когда смотрю доклады по кишкам .net в части оптимизации расходов памяти (те же доклады по memory traffic в resharper) и вопросов производительности, то очень часто случается культурный шок от того, что у себя на jvm о данных вопросах даже не задумываешься, все из коробки уже работает хорошо.
так что повторюсь: вопрос далеко не только в маркетинге, но и в рантайме (как и где он может запускаться, ну и насколько утилит готовых на все случаи жизни для него существуют), возможно с появлением .net core что-то начнет меняться, но это займет не год и не два, а в лучшем случае пять лет.
p.s. с интересом слежу за развитием .net платформы и попыткой её стать действительно кроссплатформенной, но уже видно отрезвление у многих, что это не спринт (через год-два у нас все будет отлично работать на linux/mac), а достаточно долгий марафон. остается лишь пожелать удачи, конкуренция и обмен идеями никогда никому не вредила.
это уточнение было на то, что можно повесить читателей сколько хочешь, пока они в пределах группы.
я уточнял что даже в пределах группы не более чем количество партиций.
простейший пример:
1) имеем топик на 10 партиций
2) 20 читателей с одной consumer group
вопрос:
сколько читателей будет одновременно работать?
10 будут читать, другие 10 будут висеть в воздухе ожидая пока кто-то из тех 10 отвалится.
до тех пор пока вы продолжаете использовать «то я всегда использую схему M*N <= P» все действительно можно разрулить, вот только я и начал разговор с того что
>> в общем представление партиции как упорядоченный лог накладывает свои ограничения, а держать 100500 партиций в пределах топика тоже не хочется, так как это дополнительные накладные расходы.
варианты решений есть, правда не всегда удобные и не избавляют от накапливания данных если некоторые консьюмеры начинают подтормаживать.
то есть используя схему M*N <= P мы можем получить что все вычитали, сидят курят, а один читатель продолжает пыхтеть из-за неравномерности распределения сообщений по партициям. и никто из его группы ему помочь не может. (хотя признаю что на такое только раз или два нарывался)
для вашего случая как уже сразу писалось нужно держать достаточно большое количество партиций, чтобы при необходимости масштабирования всем хватило работы. а устанавливать 100+ партиций не всегда оправдано из-за накладных расходов.
вот только я не пойму схему работы на версиях до 0.9 включительно:
1) когда вы делаете poll вам вернулся map с различных партиций или пачка сообщений даже из одной,
2) если обрабатывать последовательно даже одним потоком и в самом конце делать commit, то все равно остается вопрос что делать если обработали несколько, а потом упали, оффсет незакомиченный, а данные обработаны
согласен что на 0.10 данной проблемы нету так как можно прочитать ровно 1 сообщение, до 0.9 включительно нужно городить костыли и по мере обработки сообщения вызывать не просто commitSync()/commitAsync() (которые закомитят максимальный офсет из того что вам вернули по poll), а вариант с указанием где и что комитим
в данном случае можно обработать 1 сообщение, закомитить его,
обработать следующее и тд.
Даже если нам poll вернул достаточно большой блок мы сдвигаемся по очереди по каждому и по мере работы комитим
тут именно вопрос чтобы исключить двойную обработку отдельных сообщений
комитить в конце обработки блока не проблема и на 0.9, но иногда это не вариант =\
>> Сделать n читателей (по размеру пула, например) в рамках одной группы
нельзя сделать читателей больше чем количество партиций, 1 партиция — 1 читатель.
архитектурное ограничение для ускорения работы, так как broker делает sendfile между файловым дескриптором и дескриптором на сокет. вернее создать можно, но читать реально будет только по количеству партиций, остальные будут стоять в очереди пока какая-либо партиция не освободится
>> Каждый из них будет читать 1 сообщение, обрабатывать, коммитить, потом читать следующее.
указывать количество сообщений для вычитывания появилось начиная с 0.10 версии, до этого можно только управлять размером буфера, а там уж сколько попадет сообщений в этот буфер.
>> При такой схеме не обязательно строго привязывать читателя к партишону в кафке.
нельзя не привязывать читателя, подключение нового читателя обычно проходит по схеме:
1) подключился новый читатель в группу
2) бросилось всем читателям в группе сообщение что сейчас будет ребалансинг, притормозите работу
3) разослалась инфа о том кто какую партицию теперь будет обрабатывать
то есть вычитать не из той которая к тебе привязана нельзя, а процесс перепривязки достаточно долгий.
поэтому обычно читатель работает с 1+ партициями,
при вашей схеме держа:
M серверов по N потоков, P — количество партиций
каждый поток имеет своего читателя,
M*N > P — мы хоть и имеем несколько потоков которые курят, но зато каждый поток получает упорядоченные данные и нормально может комитить офсет.
M*N < P — тут в один поток влетает перемешенные данные из 2х партиций, при желании можно организовать доп логику и тоже работать, просто нужно будет проверять с какой партиции пришло сообщение и отправлять commit offset не общий, а именно в эту партицию
если же за 1 читателем находится пул потоков, то тут уже мешанина и async обработка неупорядоченная. проблему выше описал
p.s. чтобы было понятно: кафка отправляет подтверждение не на отдельное сообщение, а offset в пределах очереди, как бы говоря «все что было до этого оффсета я обработала»
>> В Kafka данные делятся по разделам (partition) и чтобы соблюдать порядок доставки каждый получатель сообщений читает данные ровно из одного раздела
неправильно, из одной партиции может читать только один читатель, чтобы соблюдать очередность в пределах партиции, но читатель может подписаться на несколько партиций и тогда дефолтный клиент при подписке не 2+ партициях уже выдает немного перемешанные данные.
>> Это может приводить к блокировке очереди в случае, когда получатель по каким-либо причинам обрабатывает сообщения медленнее обычного.
каждая партиция независима, о какой блокировке всей очереди идет речь? так как каждая партиция полностью независима, то у вас просто будет затык в определенной партиции, как поступать в этом случае отдельный вопрос, но остальные партиции продолжат работать без проблем.
а теперь реальные проблемы кафки если использовать как очередь запросов:
если у вас одну партицию разгребает за читателем пул потоков, то непонятно как комитить оффсет, то есть пришли сообщения mes1, mes2, mes3, раскинулись по 3 потокам, потоки выполнили их в порядке mes3, mes2, mes1.
Не дождавшись mes1 нельзя комитить mes3, иначе если мы сразу закомитим mes3, не дожидаясь mes1 и упадем, то mes1 повторно уже не вычитается.
Но и если ждем mes1 и произошло падение, то потом все этих три сообщения обработаются повторно, даже уже выполнившийся mes3.
в общем представление партиции как упорядоченный лог накладывает свои ограничения, а держать 100500 партиций в пределах топика тоже не хочется, так как это дополнительные накладные расходы.
Не знаю каким боком автор мерил производительность, но у меня в похожей ситуации и размере сообщений получалось из кафки 400k+ messages / second, а дальше упиралось в мой код.
Поэтому пока это смотрится: а смотрите что мы на Go сумели написать, Go сейчас модный, так что вы должны выбрать нас.
проблема в том, что очень часто сталкиваюсь с позицией «есть возможность — давайте использовать»
другая ситуация что 51% это возможно и надо, поэтому оставшиеся 49% тоже будут страдать, так как врубается на всех сразу
уверен многие последний абзац даже не будут читать, так как по всей статье идет внушение что server push это отличнейшая технология которую просто обязан внедрить каждый, кто хочет уменьшить скорость загрузки страницы
во всех этих server push меня смущает только пару вопросов:
1) клиенту может это все и не нужно (мобильный интернет)
2) у клиента уже есть эти данные закешированные, все что ему хочется знать это 304 NOT MODIFIED
не могу понять почему многие текущие разработки идут по принципу:
1) у пользователя простаивает cpu, надо его загрузить хоть чем-то
2) у пользователя простаивает канал в интернет, давайте мы по push закешируем весь сайт и пару поддоменов в нагрузку, может понадобится
ну дублирование не совсем корректное название, особенно что она очень легковесная, но хорошо.
по поводу друида: вы данные в него предполагали напрямую заливать?
просто везде где сталкивался с метриками мы гнали их через очередь, мало ли как индексатор себя поведет
независимо это cassandra/hbase/druid
1) HBase — Есть мастер нода – SPOF. мастеров в кластере несколько, выбираются кворумом, выпадение даже текущего не влияет на работу кластера (сам делал rolling restart всего кластера под нагрузкой, вышестоящие приложения лишь замечали небольшой скачек latency, драйвер сам детектил поведение и повторял запрос в новую ноду)
2) Druid — Долгове́чность — немного не понял, так как:
а) данные поступают в систему из kafka, пока блок не окажется в deepstorage то offset в kafka не комитится, данные всегда в очереди доступны
б) так как данные по большему immutable (сегменты полностью immutable, метаданные в реляционке лежат), то гарантии сохранности лежат или на deepstorage (это s3/hdfs зачастую) или как у вас резервирования sql базы сделано.
можете добавить сюда еще:
одно на нашем собственном Java-фреймворке, который основан на Spring и другое на kraken.js, с использованием express, dust.js и другого открытого кода.
никто не знает, кто что и как комитил в этот собственный фреймворк.
Отдельно смущает количество страниц в секунду, неужели там настолько тяжелые вызовы api?
причем стоит добавить, что aggregate с последующим «count: {$sum: 1}» работает на порядки медленнее, чем делать find(...).count() из-за особенностей реализации, разница в некоторых случаях у меня была миллисекунды-секунды vs минуты.
index используется в обоих случаях, но по разному
count может пробежаться по индексу и просто посчитать количество входов
агрегаты всегда производят материализацию объектов найденых, а уже потом только прибавляют 1, в итоге получаем fetch и disk io.
1. мы говорим о следующих пунктах:
а) интеллектуальная собственность (я тут полностью согласен с решением суда, вопрос по API возник бы рано или поздно, зато сейчас прецедент есть)
б) авторские права на код (не на сам язык, сам язык для разработки чего-либо никто не запрещал, копировать со сменой лицензии и вырезанием авторских прав есть запрет). Это если бы вы попытались использовать рантайм для Python/Lua от http://www.activestate.com/ и перетянули в свой «my-super-python-lua» дистрибутив стандартные библиотеки от них, а потом жаловались что вас за Python/Lua судят.
2. сам код openjdk под GPLv2, как и ядро linux, разрабатывай-открывай, либо не открывай, но тогда используй внутри не распространяя никому (хватает закрытых кастомных сборок jdk со специфическими патчами и никто никого не судит). GPL не означает «что хочу, то и делаю».
Вот поэтому за судом и следила вся индустрия, так как если бы судья сказал что «api действительно является ИС», то тогда бы попали все, нельзя было бы сделать ни одну стороннюю реализацию любого api, даже моки уже попадали бы под нарушение. Но судья попался грамотным и сказал обратное, поэтому все спят спокойно. Можно и реализовывать и применять.
А за копипасту со сменой лицензии доказали, что любой умный человек реализует почти таким же методом, вплоть до именования переменных.
Назовите пример открытых технологий, а то куда не посмотришь, то везде оказываются ограничения:
— ms за патенты в linux судиться,
— MPEG-LA за кодеки с гуглом (хотя тот считает что vp8-vp9 свободные кодеки),
— Yahoo! показывал что у него есть патенты на идею адблоков,
— про .net не говорю даже, там вообще все на «мы код открыли и обещаем за патенты не судить, честное слово» (почему тогда не открыли под нормальной лицензией, а то верить на слово ещё то удовольствие)
Поэтому и хотелось бы получить:
1) пример ОТКРЫТОЙ технологии
2) критерии открытости (свободно копировать, использовать, продавать изменения не показывая их)
ещё раз:
1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все в индустрии, так как процесс был знаковый)
2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах и лицензии)
по второму подробней:
взять код под GPL лицензией и сказать, что теперь это apache лицензия и дальше вы если хотите, то сорцы закрывайте (а апач это позволяет) нельзя по условиям gpl, так как это нарушение, именно за это по второму пункту и были претензии.
Причем gpl => apache не относится конкретно к java, за это можно на любой gpl продукт попасть в суд, но никто же не говорит что gpl несвободная лицензия. Вернее говорят apache и bsd, что gpl недостаточно свободная, но каждый понимает свободу по своему.
то есть если есть сторонний продукт, который занимается раскидыванием jdk по машинкам в домене, но он платный хоть и можно скачать бесплатно, то это делает сразу же java несвободное технологией?
так под эту тему любое можно подвести:
1) .net несвободная технология, так как для нормальной работы если я скачаю нелицензионный windows мне ms счета выставит
2) js несвободная технология, так как за использование пиратского IE с windows для запуска ms опять счета выставит
3) sql несвободная технология, так как за его использование на oracle/db2/mssql некоторые компании счета выставляют
4) etc. можно продолжать аналогии до бесконечности
отличайте технологию и экосистему с продуктами
то что можно бесплатно скачать, не значит что данный продукт бесплатен
и уж тем более сторонние продукты не определяют свободность-открытость технологии
основные вопросы к Google были по 2 пунктам:
1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все индустрии)
2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах)
видел =) за самим граалем уже давно посматриваю, хотя сейчас они планы чуть урезали, чтобы выйти сразу хоть с чем-то в прод, а уже потом добивать фичами
последнее время в этой части движение активное началось, помимо грааля зашевелились ibm http://www.eclipse.org/omr/
по осени дополнительно и свою версию jit открыли, в перспективе рассчитывают целиком свою версию jvm выложить и дальше двигаться по принципу Oracle «есть открытая версия, а есть наша сертифицированная с поддержкой, разница минимальная». http://openj9.mybluemix.net/
давно существуют алгоритмы и сборщики на подсчете ссылок, но у них есть свои проблемы:
1) атомарное увеличение-уменьшение количества ссылок не самая быстрая операция, а там нужна именно атомарная, так как часто мы не знаем куда убежала ссылка на объект и какие потоки еще держат данный объект
2) полностью вопроса с паузами он не снимает, хотя и делает на порядки более предсказуемым поведение.
Про второй пункт более подробно:
представьте что у Вас имеется структура в виде дерева и в программе держится только корень,
в какой-то момент корень выходит из зоны видимости и следовательно может быть собран,
после того как собран корень уменьшаются счетчики на объекты которые держались корнем и они тоже отправляются на удаление
и так проходит по всем элементам
в итоге у Вас возникает проблема, что выход из блока и инвалидация всего одной ссылки вызывает каскадную нагрузку на работу с памятью и очень часто предсказать Вы не можете в каком месте это выстрелит.
в классических языках с поколениями пройдет фаза mark и потом copy в новую область все кто выжил, а не будет вызываться пачка мелких удалений, просто пометим всю область как мусор и занулим.
p.s. известный факт: иногда из программы проще выйти по exit сразу в операционную систему, чем аккуратно освободить все участки памяти по очереди =) это касается любого managed языка
ravendb это в лучшем случае couchdb, но даже со своим rest интерфейсом очень часто проигрывает в измерениях.
hadoop это полноценная платформа поверх и совместно с которой крутится очень много чего: mapreduce, spark, flink, storm, hbase, accumulo, phoenix, cassandra, kafka и можно продолжать очень долго
у MS была хорошая попытка в виде dryad, правда они её слили, а вот идеи из неё уже и вошли в spark/flink.
вообще в сфере перемалывания и nosql доминируют 2 языка java и c++, местами другие jvm языки в виде scala и clojure.
и тут зачастую вопрос не в том что java туда зашла раньше, а в том что никто ради хадупа не будет покупать еще пару сотен лицензий на windows server, если от хост системы только и требуется что выступать пускателем кода, никаких групповых политик или еще чего.
почти все перечисленные решения могут работать и на windows (не всегда оптимально, но могут), правда в реальной жизни я в работе только linux видел.
с появлением .net core может что-то и поменяется, но тут начинается уже битва рантаймов (именно поэтому некоторые продукты отходят от jvm и переходят на c++), и тут опять же у jvm пока рантайм смотрится чуть лучше. на данный момент я не видел в жизни как себя ведет gc у .net на хипах по 64GB и выше, а в реальной жизни встречались и выше.
для той же jvm вот ultra-low pause допиливает redhat и odnoklassniki его уже в прод пустили
признаюсь, что плотно под .net не разрабатываю, но когда смотрю доклады по кишкам .net в части оптимизации расходов памяти (те же доклады по memory traffic в resharper) и вопросов производительности, то очень часто случается культурный шок от того, что у себя на jvm о данных вопросах даже не задумываешься, все из коробки уже работает хорошо.
так что повторюсь: вопрос далеко не только в маркетинге, но и в рантайме (как и где он может запускаться, ну и насколько утилит готовых на все случаи жизни для него существуют), возможно с появлением .net core что-то начнет меняться, но это займет не год и не два, а в лучшем случае пять лет.
p.s. с интересом слежу за развитием .net платформы и попыткой её стать действительно кроссплатформенной, но уже видно отрезвление у многих, что это не спринт (через год-два у нас все будет отлично работать на linux/mac), а достаточно долгий марафон. остается лишь пожелать удачи, конкуренция и обмен идеями никогда никому не вредила.
я уточнял что даже в пределах группы не более чем количество партиций.
простейший пример:
1) имеем топик на 10 партиций
2) 20 читателей с одной consumer group
вопрос:
сколько читателей будет одновременно работать?
10 будут читать, другие 10 будут висеть в воздухе ожидая пока кто-то из тех 10 отвалится.
до тех пор пока вы продолжаете использовать «то я всегда использую схему M*N <= P» все действительно можно разрулить, вот только я и начал разговор с того что
>> в общем представление партиции как упорядоченный лог накладывает свои ограничения, а держать 100500 партиций в пределах топика тоже не хочется, так как это дополнительные накладные расходы.
варианты решений есть, правда не всегда удобные и не избавляют от накапливания данных если некоторые консьюмеры начинают подтормаживать.
то есть используя схему M*N <= P мы можем получить что все вычитали, сидят курят, а один читатель продолжает пыхтеть из-за неравномерности распределения сообщений по партициям. и никто из его группы ему помочь не может. (хотя признаю что на такое только раз или два нарывался)
просто очень часто встречаю именно комит как есть, без указания доп параметров. в общем можно считать что понял вашу идею, у самих сделано похоже.
вот только я не пойму схему работы на версиях до 0.9 включительно:
1) когда вы делаете poll вам вернулся map с различных партиций или пачка сообщений даже из одной,
2) если обрабатывать последовательно даже одним потоком и в самом конце делать commit, то все равно остается вопрос что делать если обработали несколько, а потом упали, оффсет незакомиченный, а данные обработаны
согласен что на 0.10 данной проблемы нету так как можно прочитать ровно 1 сообщение, до 0.9 включительно нужно городить костыли и по мере обработки сообщения вызывать не просто commitSync()/commitAsync() (которые закомитят максимальный офсет из того что вам вернули по poll), а вариант с указанием где и что комитим
void commitSync(Map<TopicPartition, OffsetAndMetadata> offsets);
в данном случае можно обработать 1 сообщение, закомитить его,
обработать следующее и тд.
Даже если нам poll вернул достаточно большой блок мы сдвигаемся по очереди по каждому и по мере работы комитим
тут именно вопрос чтобы исключить двойную обработку отдельных сообщений
комитить в конце обработки блока не проблема и на 0.9, но иногда это не вариант =\
нельзя сделать читателей больше чем количество партиций, 1 партиция — 1 читатель.
архитектурное ограничение для ускорения работы, так как broker делает sendfile между файловым дескриптором и дескриптором на сокет. вернее создать можно, но читать реально будет только по количеству партиций, остальные будут стоять в очереди пока какая-либо партиция не освободится
>> Каждый из них будет читать 1 сообщение, обрабатывать, коммитить, потом читать следующее.
указывать количество сообщений для вычитывания появилось начиная с 0.10 версии, до этого можно только управлять размером буфера, а там уж сколько попадет сообщений в этот буфер.
>> При такой схеме не обязательно строго привязывать читателя к партишону в кафке.
нельзя не привязывать читателя, подключение нового читателя обычно проходит по схеме:
1) подключился новый читатель в группу
2) бросилось всем читателям в группе сообщение что сейчас будет ребалансинг, притормозите работу
3) разослалась инфа о том кто какую партицию теперь будет обрабатывать
то есть вычитать не из той которая к тебе привязана нельзя, а процесс перепривязки достаточно долгий.
поэтому обычно читатель работает с 1+ партициями,
при вашей схеме держа:
M серверов по N потоков, P — количество партиций
каждый поток имеет своего читателя,
M*N > P — мы хоть и имеем несколько потоков которые курят, но зато каждый поток получает упорядоченные данные и нормально может комитить офсет.
M*N < P — тут в один поток влетает перемешенные данные из 2х партиций, при желании можно организовать доп логику и тоже работать, просто нужно будет проверять с какой партиции пришло сообщение и отправлять commit offset не общий, а именно в эту партицию
если же за 1 читателем находится пул потоков, то тут уже мешанина и async обработка неупорядоченная. проблему выше описал
p.s. чтобы было понятно: кафка отправляет подтверждение не на отдельное сообщение, а offset в пределах очереди, как бы говоря «все что было до этого оффсета я обработала»
неправильно, из одной партиции может читать только один читатель, чтобы соблюдать очередность в пределах партиции, но читатель может подписаться на несколько партиций и тогда дефолтный клиент при подписке не 2+ партициях уже выдает немного перемешанные данные.
>> Это может приводить к блокировке очереди в случае, когда получатель по каким-либо причинам обрабатывает сообщения медленнее обычного.
каждая партиция независима, о какой блокировке всей очереди идет речь? так как каждая партиция полностью независима, то у вас просто будет затык в определенной партиции, как поступать в этом случае отдельный вопрос, но остальные партиции продолжат работать без проблем.
а теперь реальные проблемы кафки если использовать как очередь запросов:
если у вас одну партицию разгребает за читателем пул потоков, то непонятно как комитить оффсет, то есть пришли сообщения mes1, mes2, mes3, раскинулись по 3 потокам, потоки выполнили их в порядке mes3, mes2, mes1.
Не дождавшись mes1 нельзя комитить mes3, иначе если мы сразу закомитим mes3, не дожидаясь mes1 и упадем, то mes1 повторно уже не вычитается.
Но и если ждем mes1 и произошло падение, то потом все этих три сообщения обработаются повторно, даже уже выполнившийся mes3.
в общем представление партиции как упорядоченный лог накладывает свои ограничения, а держать 100500 партиций в пределах топика тоже не хочется, так как это дополнительные накладные расходы.
Не знаю каким боком автор мерил производительность, но у меня в похожей ситуации и размере сообщений получалось из кафки 400k+ messages / second, а дальше упиралось в мой код.
Поэтому пока это смотрится: а смотрите что мы на Go сумели написать, Go сейчас модный, так что вы должны выбрать нас.
другая ситуация что 51% это возможно и надо, поэтому оставшиеся 49% тоже будут страдать, так как врубается на всех сразу
уверен многие последний абзац даже не будут читать, так как по всей статье идет внушение что server push это отличнейшая технология которую просто обязан внедрить каждый, кто хочет уменьшить скорость загрузки страницы
1) клиенту может это все и не нужно (мобильный интернет)
2) у клиента уже есть эти данные закешированные, все что ему хочется знать это 304 NOT MODIFIED
не могу понять почему многие текущие разработки идут по принципу:
1) у пользователя простаивает cpu, надо его загрузить хоть чем-то
2) у пользователя простаивает канал в интернет, давайте мы по push закешируем весь сайт и пару поддоменов в нагрузку, может понадобится
по поводу друида: вы данные в него предполагали напрямую заливать?
просто везде где сталкивался с метриками мы гнали их через очередь, мало ли как индексатор себя поведет
независимо это cassandra/hbase/druid
1) HBase — Есть мастер нода – SPOF. мастеров в кластере несколько, выбираются кворумом, выпадение даже текущего не влияет на работу кластера (сам делал rolling restart всего кластера под нагрузкой, вышестоящие приложения лишь замечали небольшой скачек latency, драйвер сам детектил поведение и повторял запрос в новую ноду)
2) Druid — Долгове́чность — немного не понял, так как:
а) данные поступают в систему из kafka, пока блок не окажется в deepstorage то offset в kafka не комитится, данные всегда в очереди доступны
б) так как данные по большему immutable (сегменты полностью immutable, метаданные в реляционке лежат), то гарантии сохранности лежат или на deepstorage (это s3/hdfs зачастую) или как у вас резервирования sql базы сделано.
если я что-то неправильно понял, то уточните
одно на нашем собственном Java-фреймворке, который основан на Spring и другое на kraken.js, с использованием express, dust.js и другого открытого кода.
никто не знает, кто что и как комитил в этот собственный фреймворк.
Отдельно смущает количество страниц в секунду, неужели там настолько тяжелые вызовы api?
index используется в обоих случаях, но по разному
count может пробежаться по индексу и просто посчитать количество входов
агрегаты всегда производят материализацию объектов найденых, а уже потом только прибавляют 1, в итоге получаем fetch и disk io.
поэтому сравнения вообще ни о чём =)
а) интеллектуальная собственность (я тут полностью согласен с решением суда, вопрос по API возник бы рано или поздно, зато сейчас прецедент есть)
б) авторские права на код (не на сам язык, сам язык для разработки чего-либо никто не запрещал, копировать со сменой лицензии и вырезанием авторских прав есть запрет). Это если бы вы попытались использовать рантайм для Python/Lua от http://www.activestate.com/ и перетянули в свой «my-super-python-lua» дистрибутив стандартные библиотеки от них, а потом жаловались что вас за Python/Lua судят.
2. сам код openjdk под GPLv2, как и ядро linux, разрабатывай-открывай, либо не открывай, но тогда используй внутри не распространяя никому (хватает закрытых кастомных сборок jdk со специфическими патчами и никто никого не судит). GPL не означает «что хочу, то и делаю».
А за копипасту со сменой лицензии доказали, что любой умный человек реализует почти таким же методом, вплоть до именования переменных.
Назовите пример открытых технологий, а то куда не посмотришь, то везде оказываются ограничения:
— ms за патенты в linux судиться,
— MPEG-LA за кодеки с гуглом (хотя тот считает что vp8-vp9 свободные кодеки),
— Yahoo! показывал что у него есть патенты на идею адблоков,
— про .net не говорю даже, там вообще все на «мы код открыли и обещаем за патенты не судить, честное слово» (почему тогда не открыли под нормальной лицензией, а то верить на слово ещё то удовольствие)
Поэтому и хотелось бы получить:
1) пример ОТКРЫТОЙ технологии
2) критерии открытости (свободно копировать, использовать, продавать изменения не показывая их)
1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все в индустрии, так как процесс был знаковый)
2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах и лицензии)
по второму подробней:
взять код под GPL лицензией и сказать, что теперь это apache лицензия и дальше вы если хотите, то сорцы закрывайте (а апач это позволяет) нельзя по условиям gpl, так как это нарушение, именно за это по второму пункту и были претензии.
Причем gpl => apache не относится конкретно к java, за это можно на любой gpl продукт попасть в суд, но никто же не говорит что gpl несвободная лицензия. Вернее говорят apache и bsd, что gpl недостаточно свободная, но каждый понимает свободу по своему.
так под эту тему любое можно подвести:
1) .net несвободная технология, так как для нормальной работы если я скачаю нелицензионный windows мне ms счета выставит
2) js несвободная технология, так как за использование пиратского IE с windows для запуска ms опять счета выставит
3) sql несвободная технология, так как за его использование на oracle/db2/mssql некоторые компании счета выставляют
4) etc. можно продолжать аналогии до бесконечности
отличайте технологию и экосистему с продуктами
то что можно бесплатно скачать, не значит что данный продукт бесплатен
и уж тем более сторонние продукты не определяют свободность-открытость технологии
основные вопросы к Google были по 2 пунктам:
1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все индустрии)
2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах)
последнее время в этой части движение активное началось, помимо грааля зашевелились ibm
http://www.eclipse.org/omr/
по осени дополнительно и свою версию jit открыли, в перспективе рассчитывают целиком свою версию jvm выложить и дальше двигаться по принципу Oracle «есть открытая версия, а есть наша сертифицированная с поддержкой, разница минимальная». http://openj9.mybluemix.net/
в
>> Начиная с Java 9, Graal можно использовать как JVM плагин.
первичная идея была предоставить интерфейс JIT для поддержки сторонних реализаций
http://openjdk.java.net/jeps/243
Но есть сборки jvmci и для java 8, так что при желании можно гонять уже сейчас
>> А следующие части не относятся к OpenSource
>> Поддержка AOT
но тут пошли поезда от Марка Райнхольда и случился http://openjdk.java.net/jeps/295
в итоге core часть от graal уже войдет и в кодовую базу java 9
1) атомарное увеличение-уменьшение количества ссылок не самая быстрая операция, а там нужна именно атомарная, так как часто мы не знаем куда убежала ссылка на объект и какие потоки еще держат данный объект
2) полностью вопроса с паузами он не снимает, хотя и делает на порядки более предсказуемым поведение.
Про второй пункт более подробно:
представьте что у Вас имеется структура в виде дерева и в программе держится только корень,
в какой-то момент корень выходит из зоны видимости и следовательно может быть собран,
после того как собран корень уменьшаются счетчики на объекты которые держались корнем и они тоже отправляются на удаление
и так проходит по всем элементам
в итоге у Вас возникает проблема, что выход из блока и инвалидация всего одной ссылки вызывает каскадную нагрузку на работу с памятью и очень часто предсказать Вы не можете в каком месте это выстрелит.
в классических языках с поколениями пройдет фаза mark и потом copy в новую область все кто выжил, а не будет вызываться пачка мелких удалений, просто пометим всю область как мусор и занулим.
p.s. известный факт: иногда из программы проще выйти по exit сразу в операционную систему, чем аккуратно освободить все участки памяти по очереди =) это касается любого managed языка
Верифицировать и гарантировать работу ВСЕХ составляющих дорого, долго и не имеет смысла.