Написали мы софт, верифицировали, а потом
1) трактористы Васи порвали экскаватором оптику (реальный случай пропадания аплинка между РБ и Россией, в тот момент там свыше 50% всего внешнего канала было, сколько рвут кабелей океанических вообще помолчим).
2) ударили молнии и вторая половина датацентров легла (случай с амазоном)
Распределенные технологии, такие как интернет, по определению строятся на ненадежных системах, чем больше узлов в системе тем выше вероятность отказа. Поэтому для интернета стоит задача другая: как из ненадежных элементов построить достаточно устойчивую систему. Отмирание отдельной клетки не убивает организм (рак отдельная песня, но и с ним частично борются), выпадение одного сервера не ложит yandex/google/facebook (для них вылеты целиком стоек никак не сказываются на работе, даже падение целого датацентра не остановит работу). Те же DDoS это полностью правильная работа, но датацентр можно положить, тут не спасет никакая верификация.
Поэтому отдельные части верифицировать можно, но чем крупнее система, тем больше нужно полагаться на общую устойчивость, а не на то, что у нас каждый элемент будет работать правильно и идеально и никогда не сбоить.
использовать ненадежный МРТ сейчас за цену Х
или его появление в 10 клиниках в мире через 20 лет за цену 1000*X
я выбираю первый вариант, так как в некоторых случаях это нужно здесь и сейчас, а не через год, не говоря уже о больших сроках. многие новые разработки являются уникальными, либо используют новые физ-мат модели и переиспользовать просто нечего, поэтому фраза оказывается ложной:
>> Заоблачной стоимость будет только если каждый производитель каждый раз будет заново писать и верифицировать весь свой код, а если будут использованы ранее верифицированные открытые компоненты, то стоимость вырастет не сильно.
даже с обычной жизни мы постоянно сталкиваемся с вероятностями в медицине:
экспресс тесты на беременность/ВИЧ/диабет.
и вот тут мы начинаем спускаться уже глубже:
ядро для os для атомных, космических и медицинских вещей и так далеко не обычное используется, говорить, что там меньше архитектур и fs я бы точно не стал, так как хватает всего, поэтому и разработки такие дорогие, что продукты очень часто близки к уникальным или тираж очень маленький.
«а всё остальное на условном кроссплатформенном хаскеле нужно писать» — все любят повторять это как мантру, раз математический язык, то все хорошо, но почему-то все забывают уточнять, что как только поменялась немного модель данных, то с хаскелем все очень весело становится, про разворачивание ошибок компиляции отдельный вопрос (это все вытекает из математики).
иногда проще поступить по принципу эрланга: если что-то падает, дай ему упасть.
Но в нашем случае продолжаем работать и принимать решения уже на оставшихся данных, так как любая физическая сущность всегда может упасть или начать возвращать неправильные данные (можете посмотреть количество сбоев обычной RAM в датацентрах, интересная статистика, посмотрите на последние уязвимости Rowhammer), то есть ваша программа формально будет вести себя правильно, но данные ей будут поступать некорректные.
вот тут подходим к другому пункту:
верифицированный L4 это по сути минимальный гипервизор, который почти ничего не умеет.
В самом linux kernel от ядра как таковое совсем малый процент
первое место по объему это драйвера
дальше уже arch (все-таки количество поддерживаемых архитектур зашкаливает, сравните с seL4 который 4 вида arm и одни ia32 тянет)
и третье место за fs.
то есть формализовать только какой-то subset от ядра не проблема даже для монолита.
а вот формализовать все ядро действительно нету шансов
к тому же если посмотрите на последние уязвимости-ошибки, то окажется что по отдельности они не несут никаких деструктивных вещей, зачастую это даже ожидаемое их поведение, но вот грамотное построение цепочек из 10-15 таких недоуязвимостей создают большую дыру и тут даже верификация и микроядро не поможет, так как каждое из действий будет считаться допустимым, а истинная проблема возникнет на стыковке и объединении всех модулей
>> В новую версию принято более 13 тысяч исправлений от примерно 1500 разработчиков, размер патча — 41 Мб (изменения затронули 11303 файлов, добавлено 627751 строк кода, удалено 278958 строк).
вопрос: сколько людей и сколько времени будет проходить верификация только нового кода?
8700 строк кода — 12 человек — 4 года
348793 новых строк кода — ? человек — ? лет
дополнительно учитываем, что сложность верификации совсем нелинейна относительно объема кода (лично я допускаю что ближе к экспоненте)
Да, многие вещи в ядре дублируются и тд, тех же fs вагон и маленькая тележка, но все они кому-то нужны, так как специализированны под конкретные требования, нельзя написать одну fs которая удовлетворит всех, а потом её верифицировать и все счастливые.
p.s. сам регулярно прогоняю статический анализ по своему код, но это далеко не верификация, так как она будет не просто дорого, а очень дорого, проще переписать 10 раз с нуля под изменившиеся требования, чем 10 лет пилить морально устаревшее решение
>> Опять не понял, но сейчас в InFilter просто запрос в Set, скорее всего HashSet
посыпаю голову пеплом, уже пофиксили (к версии 0.9.2) =) но это было всего 2 марта, если откроете фикс который он делал, то там хорошо написано: Currently, InDimFilter is translated to «or + selector filters». Value matcher can use hash set for faster filtering.
List<DimFilter> fields = Lists.<DimFilter>newArrayList(new SelectorDimFilter(dimensionName, value));
for (String val : values) {
fields.add(new SelectorDimFilter(dimensionName, val));
}
dimFilter = new OrDimFilter(fields);
Обратите внимание на ValueMatcher: он последовательно применяет для каждого selector проверку пока кто-то не сработает. На больших объемах в IN это было достаточно плохо.
В принципе сейчас действительно уже проще, когда смотрел плотно эту часть, там с интерфейсами конкретно под эту задачу было сложнее. Сейчас же просто проверку вместо Set на что-то еще сделать не проблема, а если добавить какой bloom для больших наборов так вообще может оказаться очень хорошо.
>> А можно тут подробнее? Это какой тип запроса?
вот так сразу не вспомню точно условия, но насколько помню было «granularity»: «all» и порядочно сегментов.
>> Возможно, потому что никто не сделал эффективный способ, потому что никто не просил
у druid в общем случае это обычный отсортированный словарь ключей, по ключу находят строку в bitmap и дальше бегут по ней находя нужные rowid (условно конечно). когда у нас имеется несколько значений в IN, то нельзя просто сканировать один ряд, нужно пачку сразу и результаты результаты клеить.
дальше учитываем что основной протокол общения это rest/json, соответсвенно и передать большой кусок сложно само по себе.
кстати уже ловил проблему, когда несколько historical возвращают большие ответы и 90% времени запроса проводим в broker занимаясь «распарсили ответ от historical — merge результатов — генерация json клиенту»
p.s. это не наезд, из opensource для некоторых задач, особенно в условиях когда нужна доступность и возможность гибко расширять кластер, druid подходит хорошо и в новом проекте собираюсь опять его использовать
нет, там даже большой массив на вхождение будет неплохо снижать производительность. поэтому обычно все укладывается в бакеты (1: 1-10, 2: 11-20 и тд)
отдельно стоит уточнить, что все ключи для dimension когда bitmap строят в string переводят, поэтому использовать float/double как измерение очень не советую (много место сожрет на хранение, а выборку по диапазону все равно не получите)
В общем для некоторых вещей в лоб он очень неплох, особенно с учетом гибкого масштабирования, но вот модель «как и зачем хранить» как и с любым nosql нужно продумывать досконально
нет, в примере в статье говориться «использовать ids из вот этого файла»
lookup в druid это «я хочу чтобы ты вместо id вернул мне строковое значение из этого словаря» и происходит на этапе уже возврата данных клиенту
Cap’n Proto is an insanely fast data interchange format and capability-based RPC system. Think JSON, except binary. Or think Protocol Buffers, except faster.
так что разработчики не согласны с вами, что это «формат хранения данных, а не передачи».
смотрели в свое время, но если брать список по топику:
те же c++, те же зависимости бинарного кодогенератора по схеме от os где запускаешь
честное признание на их же сайте: Currently it only beats Protobufs in realistic-ish end-to-end benchmarks by around 2x-5x. We can do better. То есть ни о какой разнице на порядки разговор не идет. К тому же учитывая следующий абзац сравнение было на c++ версии, что происходит в java неизвестно
для java нету оффициального сериализатора, а сторонний заброшен с февраля (Cap’n Proto’s reference implementation is in C++. Implementations in other languages are maintained by respective authors and have not been reviewed by me)
как результат: взять такой продукт в продакшен вместо протестированного protobuf лично я не решусь никогда
0. да, можно указать, но он по умолчанию из окружения вытягивается, а в окружение почти все знакомые ставят apt-get/yum/port install protobuf-java
Я пока не видел людей которые считают protobuf серебрянной пулей =) чаще встречаю которые считают, что json это верх совершенства и пихают его везде, а потом ловят несогласованность форматов в рантайме. В свое время лично для меня proto решил много проблем, так как позволяет высунуть контракт протокола на сервисы и гарантировать его соблюдения.
Со строками чаще проблемы не в том что копируются туда-сюда, а в самом кодировании-декодировании в UTF8, так как в java локальное представление Unicode, вот тут CPU и проседает частенько =(
0. https://www.xolstice.org/protobuf-maven-plugin/ уже давно все есть
1. начиная с protobuf v3 одной командой в протофайле option java_multiple_files = true; отключаем генерацию большого файла, получаем набор class=>file. Править полученные протофайлы вам не запрещается, при большом желании можно расширить компилятор и он будет генерить то что вам нужно и прописывать интерфейсы какие хотите
2. как вы предлагаете изменять byte[] в котором по определенным смещениям лежат значения изменяемой длинны? (ваш же пункт 4, чтобы что-то поменять нам нужно будет хвостик сдвинуть влево-вправо и изменить размер самого массива) Если объект в системе вроде как и готов, но возможно еще будет меняться, то перекидывается ссылка на билдер, а вот если нужно отправить в wire клиенту, то тут уже и build() вызывается и получаем готовый слепок.
3. сами же и сказали решение проблемы, dto не должно думать как упаковать граф, а потом его распаковывать, или может JSON уже научился такое делать? с учетом того что proto v3 еще ближе приблизился к json, то упаковка графа в руках того кто упаковывает, а совсем не стандартная операция.
4. [PROTOBUF+ZIP] vs [JSON+GZIP] это спор на уровне: у нас есть SQL и у нас есть NoSQL, в одном схема прописана и если говно пришло то оно сразу отбросится, во втором мы что-то как-то запишем-прочитаем. И далеко не у всех текста гоняются, зачастую только ID нужных элементов. К тому же сами признали увеличенную нагрузку на CPU, что для мобильных приложений очень критично. Хотите еще быстрее, с меньшей нагрузкой на CPU и без схемы, то добро пожаловать в MessagePack, только потом не жалуйтесь, что клиенты прислали очередную кашу.
В общем у вас пожелания: я хочу бинарный формат, который работает быстро, является компактным, сохраняет и проверяет схему, сохраняет ссылочность, позволяет без копирования изменять поля прямо в byte[] и т.д.
Лично я не знаю таких форматов и вижу противоречия в требованиях: компактный vs изменения сразу упакованного массива, компактный-быстрый vs сохраняем целиком ссылки-граф.
все зависит от потребностей, если нету какого-то специфического софта завязанного на windows, то проблем с OC нету
linux-mac консоль и окружение пересекаются почти полностью, за исключением мелких моментов
Так что для девелоперов если брать по возможностям окружения, то для меня в порядке убывания это linux/macos/windows(тут обычно у меня только боль)
если брать полностью все окружение и возможности, то macos более вылизанная и гладкая, меньше телодвижений, чтобы что-то настроить, так как зачастую это не нужно.
что не нравится в windows: поддержку 4к мониторов нормально запилили только в 10ке, до этого разный dpi на ноуте и мониторе нельзя было проставить, в маке с момента появления ретин это возможно и работает отлично
что не нравится в macbook pro (именно железо): 16гб памяти это лимит и обновить нельзя, так как распаяна, а больше даже в новых нельзя купить, мне как девелоперу периодически не хватает…
по железу и батареи если начинать смотреть похожие конфигурации, то по ценнику что маки, что аналоги стоят сопоставимых денег
но по порядку:
1) там было написано МИНИМАЛЬНОЕ что нужно сделать, но до нормального бенчмарка код все равно недотягивает
2) java 490ms, python 330ms
но раз вы уже пошли до «сложных регулярных выражений» со ссылкой на вашу методику, то и тестируйте её, чего сразу и не прогнать конечный регексп написанный вами же?
у меня получилось:
java 855ms и python 750ms
и если сразу не было 2 раза, разрыв не то что в процентных числах, в абсолютных начал уменьшаться при росте общего времени выполнения
пытаетесь доказать, что питон быстрее? так это не питон, а си в данном случае быстрее, причем в треде с этим никто не спорит
вот только java реализация написана на java
python реализация на сях и полный список веселья тут,
а уж если вам так сильно необходимы быстрые регулярные выражений, то возьмите jregex, эта «нехорошая библиотека» на первом regexp выдает 130ms и на втором сложном 290ms, что оставляет глубоко в оппе как стандартную реализацию java, так и python
итого мы доказали: стандартная обертка питона быстрее стандартных реализаций java (разница от 15% до 50%), и в более чем 2 раза медленней оптимизированной java реализации
вывод: нужны быстрые регекспы, берешь не питон/java/js/непонятночто, а нормальную либу
потом можно продолжить поисковым движком elasticsearch (напомните мне схожий по возможностям продукт не на java, вроде sphinx что-то умеет, правда количество упоминаний и инсталяций в разы меньше)
дальше продолжаем быстрой распределенной очередью, чтобы заменить kafka (zeromq это конструктор, а не готовая распределенная персистентная очередь)
так как нам нужно распределенно считать, то следом в очередь spark, storm (даже у последователя heronосновной объем кода это java), gearpump
можно еще упомянуть hbase (бедные Airbnb и Xiaomi не знаю, что нельзя его было использовать) или его сородича accumulo (писалась по заказу АНБ с требованием жестких ACL вплоть до отдельной ячейки)
а вот тут и начинается веселье под названием безопасная публикация объектов. Также как и в плюсах: либо используешь безопасные примитивы, либо сам думаешь где у тебя есть барьеры, а где нету, а если не думая перекинул линку, то можешь вычитать или нули или частично сконструированный объект, единственная гарантия «нельзя прочитать мусор оставленный предыдущим объектом»
на этого говорят что «меряют сферического коня в вакууме и в дополнение неправильно»
но большинству достаточно цифр из желтых газет чтобы начать истерить
1) трактористы Васи порвали экскаватором оптику (реальный случай пропадания аплинка между РБ и Россией, в тот момент там свыше 50% всего внешнего канала было, сколько рвут кабелей океанических вообще помолчим).
2) ударили молнии и вторая половина датацентров легла (случай с амазоном)
Распределенные технологии, такие как интернет, по определению строятся на ненадежных системах, чем больше узлов в системе тем выше вероятность отказа. Поэтому для интернета стоит задача другая: как из ненадежных элементов построить достаточно устойчивую систему. Отмирание отдельной клетки не убивает организм (рак отдельная песня, но и с ним частично борются), выпадение одного сервера не ложит yandex/google/facebook (для них вылеты целиком стоек никак не сказываются на работе, даже падение целого датацентра не остановит работу). Те же DDoS это полностью правильная работа, но датацентр можно положить, тут не спасет никакая верификация.
Поэтому отдельные части верифицировать можно, но чем крупнее система, тем больше нужно полагаться на общую устойчивость, а не на то, что у нас каждый элемент будет работать правильно и идеально и никогда не сбоить.
или его появление в 10 клиниках в мире через 20 лет за цену 1000*X
я выбираю первый вариант, так как в некоторых случаях это нужно здесь и сейчас, а не через год, не говоря уже о больших сроках. многие новые разработки являются уникальными, либо используют новые физ-мат модели и переиспользовать просто нечего, поэтому фраза оказывается ложной:
>> Заоблачной стоимость будет только если каждый производитель каждый раз будет заново писать и верифицировать весь свой код, а если будут использованы ранее верифицированные открытые компоненты, то стоимость вырастет не сильно.
даже с обычной жизни мы постоянно сталкиваемся с вероятностями в медицине:
экспресс тесты на беременность/ВИЧ/диабет.
и вот тут мы начинаем спускаться уже глубже:
ядро для os для атомных, космических и медицинских вещей и так далеко не обычное используется, говорить, что там меньше архитектур и fs я бы точно не стал, так как хватает всего, поэтому и разработки такие дорогие, что продукты очень часто близки к уникальным или тираж очень маленький.
«а всё остальное на условном кроссплатформенном хаскеле нужно писать» — все любят повторять это как мантру, раз математический язык, то все хорошо, но почему-то все забывают уточнять, что как только поменялась немного модель данных, то с хаскелем все очень весело становится, про разворачивание ошибок компиляции отдельный вопрос (это все вытекает из математики).
иногда проще поступить по принципу эрланга: если что-то падает, дай ему упасть.
Но в нашем случае продолжаем работать и принимать решения уже на оставшихся данных, так как любая физическая сущность всегда может упасть или начать возвращать неправильные данные (можете посмотреть количество сбоев обычной RAM в датацентрах, интересная статистика, посмотрите на последние уязвимости Rowhammer), то есть ваша программа формально будет вести себя правильно, но данные ей будут поступать некорректные.
верифицированный L4 это по сути минимальный гипервизор, который почти ничего не умеет.
В самом linux kernel от ядра как таковое совсем малый процент
первое место по объему это драйвера
дальше уже arch (все-таки количество поддерживаемых архитектур зашкаливает, сравните с seL4 который 4 вида arm и одни ia32 тянет)
и третье место за fs.
то есть формализовать только какой-то subset от ядра не проблема даже для монолита.
а вот формализовать все ядро действительно нету шансов
к тому же если посмотрите на последние уязвимости-ошибки, то окажется что по отдельности они не несут никаких деструктивных вещей, зачастую это даже ожидаемое их поведение, но вот грамотное построение цепочек из 10-15 таких недоуязвимостей создают большую дыру и тут даже верификация и микроядро не поможет, так как каждое из действий будет считаться допустимым, а истинная проблема возникнет на стыковке и объединении всех модулей
>> В новую версию принято более 13 тысяч исправлений от примерно 1500 разработчиков, размер патча — 41 Мб (изменения затронули 11303 файлов, добавлено 627751 строк кода, удалено 278958 строк).
вопрос: сколько людей и сколько времени будет проходить верификация только нового кода?
8700 строк кода — 12 человек — 4 года
348793 новых строк кода — ? человек — ? лет
дополнительно учитываем, что сложность верификации совсем нелинейна относительно объема кода (лично я допускаю что ближе к экспоненте)
Да, многие вещи в ядре дублируются и тд, тех же fs вагон и маленькая тележка, но все они кому-то нужны, так как специализированны под конкретные требования, нельзя написать одну fs которая удовлетворит всех, а потом её верифицировать и все счастливые.
p.s. сам регулярно прогоняю статический анализ по своему код, но это далеко не верификация, так как она будет не просто дорого, а очень дорого, проще переписать 10 раз с нуля под изменившиеся требования, чем 10 лет пилить морально устаревшее решение
посыпаю голову пеплом, уже пофиксили (к версии 0.9.2) =) но это было всего 2 марта, если откроете фикс который он делал, то там хорошо написано: Currently, InDimFilter is translated to «or + selector filters». Value matcher can use hash set for faster filtering.
Or в свою очередь доходит до OrFilter
Обратите внимание на ValueMatcher: он последовательно применяет для каждого selector проверку пока кто-то не сработает. На больших объемах в IN это было достаточно плохо.
В принципе сейчас действительно уже проще, когда смотрел плотно эту часть, там с интерфейсами конкретно под эту задачу было сложнее. Сейчас же просто проверку вместо Set на что-то еще сделать не проблема, а если добавить какой bloom для больших наборов так вообще может оказаться очень хорошо.
>> А можно тут подробнее? Это какой тип запроса?
вот так сразу не вспомню точно условия, но насколько помню было «granularity»: «all» и порядочно сегментов.
это пилили уже пол года назад =) все еще пилят
>> Возможно, потому что никто не сделал эффективный способ, потому что никто не просил
у druid в общем случае это обычный отсортированный словарь ключей, по ключу находят строку в bitmap и дальше бегут по ней находя нужные rowid (условно конечно). когда у нас имеется несколько значений в IN, то нельзя просто сканировать один ряд, нужно пачку сразу и результаты результаты клеить.
дальше учитываем что основной протокол общения это rest/json, соответсвенно и передать большой кусок сложно само по себе.
кстати уже ловил проблему, когда несколько historical возвращают большие ответы и 90% времени запроса проводим в broker занимаясь «распарсили ответ от historical — merge результатов — генерация json клиенту»
p.s. это не наезд, из opensource для некоторых задач, особенно в условиях когда нужна доступность и возможность гибко расширять кластер, druid подходит хорошо и в новом проекте собираюсь опять его использовать
отдельно стоит уточнить, что все ключи для dimension когда bitmap строят в string переводят, поэтому использовать float/double как измерение очень не советую (много место сожрет на хранение, а выборку по диапазону все равно не получите)
В общем для некоторых вещей в лоб он очень неплох, особенно с учетом гибкого масштабирования, но вот модель «как и зачем хранить» как и с любым nosql нужно продумывать досконально
lookup в druid это «я хочу чтобы ты вместо id вернул мне строковое значение из этого словаря» и происходит на этапе уже возврата данных клиенту
С druid масштабирование понятно (докинули серверов в кластер, достаточно указать zookeeper-hadoop, там открылись сегменты новых-ребаланс старых)
С ClickHouse на этапе знакомства я не нашел как по быстрому можно расширить кластер.
Как вы собираетесь увеличивать емкость ClickHouse когда увидите, что нагрузка увеличилась x2 и нужно докинуть серверов?
ещё вижу сложности для Druid в случае «Использование внешних данных для обработки запроса», скормить файл на данном этапе в него нельзя.
p.s. Tranquility не использовал, обычно realtime nodes из kafka вычитывали данные самостоятельно.
так что разработчики не согласны с вами, что это «формат хранения данных, а не передачи».
p.s. лучше брать то, что решает конкретную задачу
те же c++, те же зависимости бинарного кодогенератора по схеме от os где запускаешь
честное признание на их же сайте: Currently it only beats Protobufs in realistic-ish end-to-end benchmarks by around 2x-5x. We can do better. То есть ни о какой разнице на порядки разговор не идет. К тому же учитывая следующий абзац сравнение было на c++ версии, что происходит в java неизвестно
для java нету оффициального сериализатора, а сторонний заброшен с февраля (Cap’n Proto’s reference implementation is in C++. Implementations in other languages are maintained by respective authors and have not been reviewed by me)
как результат: взять такой продукт в продакшен вместо протестированного protobuf лично я не решусь никогда
Я пока не видел людей которые считают protobuf серебрянной пулей =) чаще встречаю которые считают, что json это верх совершенства и пихают его везде, а потом ловят несогласованность форматов в рантайме. В свое время лично для меня proto решил много проблем, так как позволяет высунуть контракт протокола на сервисы и гарантировать его соблюдения.
Со строками чаще проблемы не в том что копируются туда-сюда, а в самом кодировании-декодировании в UTF8, так как в java локальное представление Unicode, вот тут CPU и проседает частенько =(
1. начиная с protobuf v3 одной командой в протофайле option java_multiple_files = true; отключаем генерацию большого файла, получаем набор class=>file. Править полученные протофайлы вам не запрещается, при большом желании можно расширить компилятор и он будет генерить то что вам нужно и прописывать интерфейсы какие хотите
2. как вы предлагаете изменять byte[] в котором по определенным смещениям лежат значения изменяемой длинны? (ваш же пункт 4, чтобы что-то поменять нам нужно будет хвостик сдвинуть влево-вправо и изменить размер самого массива) Если объект в системе вроде как и готов, но возможно еще будет меняться, то перекидывается ссылка на билдер, а вот если нужно отправить в wire клиенту, то тут уже и build() вызывается и получаем готовый слепок.
3. сами же и сказали решение проблемы, dto не должно думать как упаковать граф, а потом его распаковывать, или может JSON уже научился такое делать? с учетом того что proto v3 еще ближе приблизился к json, то упаковка графа в руках того кто упаковывает, а совсем не стандартная операция.
4. [PROTOBUF+ZIP] vs [JSON+GZIP] это спор на уровне: у нас есть SQL и у нас есть NoSQL, в одном схема прописана и если говно пришло то оно сразу отбросится, во втором мы что-то как-то запишем-прочитаем. И далеко не у всех текста гоняются, зачастую только ID нужных элементов. К тому же сами признали увеличенную нагрузку на CPU, что для мобильных приложений очень критично. Хотите еще быстрее, с меньшей нагрузкой на CPU и без схемы, то добро пожаловать в MessagePack, только потом не жалуйтесь, что клиенты прислали очередную кашу.
В общем у вас пожелания: я хочу бинарный формат, который работает быстро, является компактным, сохраняет и проверяет схему, сохраняет ссылочность, позволяет без копирования изменять поля прямо в byte[] и т.д.
Лично я не знаю таких форматов и вижу противоречия в требованиях: компактный vs изменения сразу упакованного массива, компактный-быстрый vs сохраняем целиком ссылки-граф.
linux-mac консоль и окружение пересекаются почти полностью, за исключением мелких моментов
Так что для девелоперов если брать по возможностям окружения, то для меня в порядке убывания это linux/macos/windows(тут обычно у меня только боль)
если брать полностью все окружение и возможности, то macos более вылизанная и гладкая, меньше телодвижений, чтобы что-то настроить, так как зачастую это не нужно.
что не нравится в windows: поддержку 4к мониторов нормально запилили только в 10ке, до этого разный dpi на ноуте и мониторе нельзя было проставить, в маке с момента появления ретин это возможно и работает отлично
что не нравится в macbook pro (именно железо): 16гб памяти это лимит и обновить нельзя, так как распаяна, а больше даже в новых нельзя купить, мне как девелоперу периодически не хватает…
по железу и батареи если начинать смотреть похожие конфигурации, то по ценнику что маки, что аналоги стоят сопоставимых денег
но по порядку:
1) там было написано МИНИМАЛЬНОЕ что нужно сделать, но до нормального бенчмарка код все равно недотягивает
2) java 490ms, python 330ms
но раз вы уже пошли до «сложных регулярных выражений» со ссылкой на вашу методику, то и тестируйте её, чего сразу и не прогнать конечный регексп написанный вами же?
у меня получилось:
java 855ms и python 750ms
и если сразу не было 2 раза, разрыв не то что в процентных числах, в абсолютных начал уменьшаться при росте общего времени выполнения
пытаетесь доказать, что питон быстрее? так это не питон, а си в данном случае быстрее, причем в треде с этим никто не спорит
вот только java реализация написана на java
python реализация на сях и полный список веселья тут,
а уж если вам так сильно необходимы быстрые регулярные выражений, то возьмите jregex, эта «нехорошая библиотека» на первом regexp выдает 130ms и на втором сложном 290ms, что оставляет глубоко в оппе как стандартную реализацию java, так и python
итого имеем:
java(standart)/java(jregex)/python(re)
490ms/130ms/330ms
855ms/290ms/750ms
итого мы доказали: стандартная обертка питона быстрее стандартных реализаций java (разница от 15% до 50%), и в более чем 2 раза медленней оптимизированной java реализации
вывод: нужны быстрые регекспы, берешь не питон/java/js/непонятночто, а нормальную либу
потом можно продолжить поисковым движком elasticsearch (напомните мне схожий по возможностям продукт не на java, вроде sphinx что-то умеет, правда количество упоминаний и инсталяций в разы меньше)
дальше продолжаем быстрой распределенной очередью, чтобы заменить kafka (zeromq это конструктор, а не готовая распределенная персистентная очередь)
так как нам нужно распределенно считать, то следом в очередь spark, storm (даже у последователя heronосновной объем кода это java), gearpump
можно еще упомянуть hbase (бедные Airbnb и Xiaomi не знаю, что нельзя его было использовать) или его сородича accumulo (писалась по заказу АНБ с требованием жестких ACL вплоть до отдельной ячейки)
вот так сидят все и формочки клепают
но большинству достаточно цифр из желтых газет чтобы начать истерить