1) делать замеры производительности на ideon само по себе глупо
2) в примере java происходит измерение в одном интервале «медленного режима интерпретатора» и «быстрого скомпилированного», общее число 500мс совсем не говорит о том какого режима было больше, а напоминает известный анекдот
вот пример с моей стороны pastebin
он еще содержит туеву хучу потенциальных ошибок измерения в разделе вырезания кода эскейп анализом, но все-таки чуть лучше чем было сразу
итого на моей системе получаем устоявшуюся скорость:
1) nodejs 100ms
2) java 200ms
3) python 400ms
зря @rossws сразу не привел примеры его java кода сразу, было бы меньше вопросов про прогрев и итерации
как минимум были предложения по https://github.com/amplab/spark-indexedrdd и которые местами мне интересны, в качестве быстрого распределенного хранилища, без необходимости тянуть сбоку imdb + получаем и локальность вычислений
>> Хм, в презентациях посвящённых Catalyst использовался, вполне себе dataframe-api и не было sql. Ну и потом, они же взаимозаменяемы и оптимизация будет одинаковой
не могут быть они полностью взаимозаменяемые, так как в dataframe как и у rdd хватает терминальных операций, а sql может состоять из нескольких слоев и проще выполнять push down для предикатов. с sql у нас на руках весь план запросов имеется. хотя для простых запросов действительно функционально одинаковы sql vs dataframe.
p.s. и самый простой вопрос который мне нравится к спарку: данные у меня приходят пускай и условно равномерно, но бывают всплески, как мне гарантировать что в какой-то момент я не захлебнусь? у того же beam/dataflow для окна есть тригеры по объему, что мне делать в этом случае со спарком, который не позволяет управлять размером очередного батча
streaming — как пилили микробатчи, так и будем пилить, ожидать честного стриминга не стоит и «он вам не нужен» sql — как пилили кастомный Catalyst, так и будем пилить, плевать мы хотели на другие уже существующие и отлаженные инструменты (для примера https://calcite.apache.org/ ) rdd — забили на развитие, используйте dataframe dataframe — пока юзайте, но учтите, что основные изменения у нас в sql, так что может и вам что от планировщика перепадет, но вообще лучше тоже двигайте в sql, там все оптимизации
и да, dataframe уже в разы быстрее чем rdd для питона, так как имеет схему и гонит данные в лямбды достаточно хорошо, поэтому arrow больше для общения между любыми системами интересно
я не спорю, что спарк развивается, но зачастую шумихи больше чем достижений
вот возьмите Фрунзенский район =) еще то веселье, даже в ванне запах хлорочки летом может стоять, про чай из этой воды я вообще молчу. Пока жил в Партизанском районе меня все и из под крана устраивало, а после переезда сразу начал покупать бутилированную, потом поставил фильтр с обратным осмосом.
а теперь главные вопросы которые почему-то остаются за кадром:
1. sharding — у вас он ручной,
1.1 что делать если клиенты в разных шардах растут с разной скоростью и у нас на одном шарде 100млн, а на другом 1млн записей?
1.2 как делать перебалансировку в случае если нам нужно добавить +1 сервер в кластер
2. fault tolerance
2.1 мультимастер еще нужно уметь настраивать, в master-slave при выпадении master тоже веселье
если у вас 1 мастер и пачка слейвов, так как нагрузка на запись минимальная, почти все это чтение, то вам конечно повезло,
но ведь nosql любят в первую очередь за то, что у вас ключи разбиты по бакетам которых заметно больше чем серверов и эти бакеты свободно мигрируют между узлами (решаем задачу 1 с балансировкой и добавлением новых узлов), а выпавшего мастера автоматически подхватывает кто-то другой (в hbase и mongodb на основе кворума, у cassandra вообще мастера нету) (решаем задачу сложности конфигурации для задачи 2).
правда если уж начали про mysql в качестве nosql, то я бы ожидал услышать про handlersocket, чтобы проходить уже даже и мимо планировщика запросов, а сразу ломиться на получение данных
в письме было что черновое видео будет доступно быстро, полное монтирование уже к концу мая
опрос заполнил и тишина, в итоге непонятно «опрос не засчитали или пока ничего и нету»?
по мне главный плюс и минус kudu в отказе от использования hdfs:
1) плюс — мы не зависим от еще одной абстракции, точно управляем локальностью данных
2) минус — вопросы отказоустойчивости изобретаем повторно
наличие или отсутствие jvm зачастую сильно не решает основные вопросы: что и как храним и какие запросы делаем по данным,
так как практика показывает, что говнокод можно написать на любом языке =) хотя согласен что проект интересный и если будет опыт использования, то ждем статью ;)
Для работы из других языков программирования Hbase предоставляет Thrift API и Rest API.
Для этого запускаются отдельные сервера-сервисы которые выступают проксей на нативный API и может оказаться, что узким местом и является этот самый прокси. Плюсом у вас клиент всегда стучится на один явный api сервер, а не на размазанный кластер, что очень хорошо позволяет сделать ограничение доступа.
Такая проблема возникла, что работа клиента представляет собой цикл: подключились к мастеру => забрали метаданные => постучались на нужный регион сервер. Сам же клиент при необходимости и метаданные у себя обновляет при миграции регионов, должен же он знать куда стучать. Накладываем на это собственный бинарный протокол и получаем, что сделать REST прокси на java оказывается проще, чем делать поддержку клиентов для разных языков. Сейчас ситуация исправляется за счет того, что протокол поменяли на protobuf и остается закодить только логику работы с серверами метаданных-данных, а не логику+бинарный протокол (который еще и меняли периодически).
Отдельно стоит упомянуть сопроцессоры (coprocessor) которые можно использовать как:
тригеры — вешаются на любом из действий (prePut, postPut, preGet, postGet, etc.) и через них можно сделать как индексацию дополнительную (на вставке данных дополнительно обновлять еще какую ячейку, например поле SUM), так и проверку доступов (acl и throttling через них и сделаны)
хранимые процедуры — позволяют расширять функциональность, например разослать на все машинки запрос посчитать сумму, а потом в клиенте сделать только агрегацию результатов, вместо того чтобы через scan все тянуть на клиент. Но возможности конечно достаточно большие
в использовании действительно проявляется, в первую очередь на уровне изоляции ресурсов,
с другой стороны если у вас в кластере крутиться только spark для обработки и hive/map-reduce/etc отсутствуют, то yarn будет всего-лишь дополнительной прослойкой
говоря о плюсах-минусах YARN для SPARK мне кажется лишь стоит указать возможность использования кластера разными группами, так как YARN нам может дать гарантии по нарезанию ресурсов с лимитами и что dev задача не скушает весь prod. Но если у нас прод живет отдельно, то там YARN может оказаться оверхедом.
p.s. инструменты выбираются под задачу, а не задачи пытаются подтянуть под используемые инструменты, поэтому как и что гонять становится ясно только после полного изучения задачи и окружения ;)
По поводу YARN: конечно, никто не запрещает поставить HDFS отдельно, но для него тоже надо выделять ресурсы, и это легче всего делать инструментом из инфраструктуры hadoop с помощью YARN.
HDFS НЕЛЬЗЯ поставить через YARN =) у них разные задачи
с помощью yarn можно:
1) развернуть spark
2) запустить map-reduce задачу
3) с определенными костылями запустить hbase
но вот yarn сам использует для некоторых задач hdfs, поэтому можно рассматривать что yarn работает поверх hdfs.
Думаю вы видели данную картинку, на которой видно что HDFS без YARN нормально живет и кушать не просит.
Нас заинтересовал прирост в скорости чтения glusterfs, так как операций чтения у нас намного больше
Эти задачи как раз и решает локальность данных, хотя если у вас на вход одна партиция и пару гигабайт данных, то glusterfs может и выиграет, но если имеется 2-3ТБ данных и 20 партиций которые могут локально отфильтровать-сгруппировать данные, то вы сразу проседаете в разы и локальность становится задачей номер 1. Именно поэтому те кто хотел бы использовать glusterfs в качестве замены HDFS пилят glusterfs-hadoop плагины для реализации hdfs интерфейсов по получению метаданных о том где какой блок лежит. Если уж нужен POSIX для hdfs, то FUSE драйвера для него существуют.
Примеры насколько важна локальность данных. А в вашей ссылке проверяли линейное чтение, что конечно полезно когда у вас хранилище отдельно, а обработка отдельно, но в большинстве случаев BigData это не имеет смысла, особенно когда чтение превышает в разы запись.
Далее аналитик может разобрать не задекларированные ключи с помощью map функций.
по поводу хранения:
не оказывается ли в итоге, что основную часть времени вы занимаетесь парсингом?
исходя из своего опыта могу сказать, что иногда проще сделать выборку, распарсить и сохранить в другую parquet-табличку и уже по ней гонять запросы, начиная со 2-3 запроса это окупается. Так как в этом случае вы даже сможете нормально DataFrame использоваться с его поколоночным хранением и компрессией.
Кроме как в Spark, Parquet не всегда обладает нативной поддержкой в других продуктах.
можно подробней о каких продуктах идет речь? так как у нас математики без проблем читают паркет в питоновские датафреймы, impala & hive так вообще нативно подхватывают. Читать файлы из java тоже не составляет никакого труда.
Не поддерживаются транзакции, так как это обычные файлы а не БД.
он и не должен, это формат хранения ;) к тому же immutable
На данный момент мы используем терабайтные SSD, примонтированные по NFS
Пока мы не хотим использовать HFS, так как придется обязательно тащить hadoop и YARN
подозреваю хотели написать HDFS, но не суть
почему установка HDFS сразу же подразумевает установку YARN и остальных вещей? (у самого крутиться HDFS + HBase без какого-либо YARN). HDFS — распределенное хранилище, YARN — вычислительная платформа, они достаточно неплохо разделены. Поэтому от standalone spark кластера вас никто не заставляет отказываться, можете поднять hdfs + spark standalone, проблем никаких нету (подымал такую конфигурацию, от spark yarn отличий в разворачивании на клоудере вообще нету)
к тому же перейдя от NFS на HDFS вы получаете профит в виде локальности данных, ваши spark задачи будут отправляться на ноды на которых эти данные и лежат, а это сразу решает несколько проблем:
1) затыки на дисковом IO, ради чего вы и покупали ссд (все уйдет на локальные диски, которые в сумме выдадут за те же деньги в разы большую производительность)
2) затыки на сетевом интерфейсе (прокачать каких-то 1ТБ даже с 10Гбитной сеткой занимает существенное время, тут же будет независимое чтение с разных дисков и минимум нагрузка на сеть, если все-таки промахнемся с задачей)
HDFS ведь и придумывалось не только для распределенности, но и ради локальности данных (кстати это причина почему хадуп на SAN/NAS у меня вызывает улыбку) и GlusterFS в этом плане вам ничем не поможет, так как спарк не сможет получить распределение блоков.
Колончатый вид заставляет задумываться о схеме и типах данных.
в вашем примере я не понял как парсить и обрабатывать данный json с разной структурой? каждый раз проверяем наличие нужных полей и вложен или нет?
Эффективное хранение с точки зрения занимаемого места.
тут согласен, особенно если сверху еще какой dictionary encoding для строк пройдется, то зачастую вообще копейки на выходе
В общем spark на NFS имеет смысл там же где и GPU вычисления: входных-выходных данных мало, а вычислительной математики много
ага, скоро будет =) причем отсечение 4 нулей, то есть цены уменьшаться в 10 000 раз, и введение копеек
как это в уме по быстрому переводить пока никто не объяснил
ну давайте посмотрим состояние индустрии:
1) аська никогда не хранила переписку в закрытом виде + логи на сервере
2) skype никогда не хранил переписку в закрытом виде + с недавнего времени логи на сервере
3) viber никогда не хранил переписку в закрытом виде + логи на сервере
4) whatsapp не хранит переписку в закрытом виде + логи на сервере
5) telegram не хранит переписку в закрытом виде ( habrahabr.ru/post/240521 с того момента вроде ничего не поменялось), хотя и позиционируются как защищенный мессенджер, но политика разрабов «конечные устройства защищайте сами»
поэтому я могу смело сказать: производителям начхать на безопасность конечных точек, максимум что они беспокоятся это о mitm атаках, а конечные устройства должны защищать сами пользователи (шифрованный раздел для desktop, шифрованная sd для телефонов и тд)
если у вас есть другие примеры, то с удовольствием выслушаю
да, это идеальный вариант, но тут начинаются чисто финансовые вопросы: а стоит ли делать еще один режим работы ради 0.01% пользователей или эти же ресурсы потратить на улучшение существующего функционала и увеличить аудиторию на +10%?
ответ я думаю ожидаем =( мне это самому не нравится, но бизнесу не интересны технологии ради технологий, он строится немного для другого
а вот теперь расширьте это на:
1) у меня есть компьютер и телефон
2) ноуты я периодически меняю
3) телефоны бывают меняются еще чаще
как это все ДОСТУПНО объяснить рядовому пользователю например того же viber?
да он пошлет всех в известном направлении еще на этапе установки, так как каждое лишнее действие на этапе установки-настройки это потерянная аудитория.
поэтому есть масса людей которым плевать на их приватность (соцсети как пример), а уж если тебе так дорога приватность, то ты настроишь нормальные права доступа к папкам, все это запихаешь на шифрованный раздел, ну и конечно просто не будешь пользоваться этими мессенджерами которые всю историю хранят в открытом виде на серверах компании
p.s. кстати, я что-то не уловил часть: как нам читать наши же сообщения, если ключ где-то далеко, ну или ключ шифровать текущим паролем и сохранить рядом, но тогда остается вопрос что если у тебя украли пароль, то из старых баз вытянут твой ключ?
третий вариант не сильно решает проблему:
1) есть 2 компа и история синкается
2) на одном из них поменяли пароль на вайбер
3) на втором уже этим паролем не прочитать сообщения
поэтому придется выбирать одно из 2х:
1) на историю делаем еще один пароль именно для шифрования истории
2) храним ключ шифрования на сервере и после логина высылаем его на клиент
такие споры мне напоминают холивары: twitter стал быстрее потому что переписали с ruby на scala
на самом деле: полностью сменили архитектуру на микросервисы и event processing
почти любой кто видел тормозящий i2p на java и смотревший в исходники может подтвердить:
1) одна из основных проблем это большой context switch, так как на каждый поток ввода-вывода создает thread
2) почти полное отсутсвие использования nio, большинство вещей на стандартном io
3) наличие N потоков в каждом из которых имеется личный буфер дает дополнительное давление на память и gc
4) и уже только на четвертом месте оказывается само шифрование-дешифрование
в итоге мы вместо асинхронности и вменяемого потребления под различные буфера ввода-вывода сжираем почти все что можно
почему же не использовать netty и другие сетевые фреймворки?
ответ до банальности прост: безопасность, так как текущий код до ужаса прост, то и аудит его сделать проще, ну и отсутствует зависимость на сторонних библиотеках (через которых можно что-либо пропихнуть), только голый java core.
1) делать замеры производительности на ideon само по себе глупо
2) в примере java происходит измерение в одном интервале «медленного режима интерпретатора» и «быстрого скомпилированного», общее число 500мс совсем не говорит о том какого режима было больше, а напоминает известный анекдот
вот пример с моей стороны pastebin
он еще содержит туеву хучу потенциальных ошибок измерения в разделе вырезания кода эскейп анализом, но все-таки чуть лучше чем было сразу
итого на моей системе получаем устоявшуюся скорость:
1) nodejs 100ms
2) java 200ms
3) python 400ms
зря @rossws сразу не привел примеры его java кода сразу, было бы меньше вопросов про прогрев и итерации
есть сильно разряженный граф, но достаточно большой (100млн записай)
имеется 2 вершины
сколько по времени может проверка что элементы связаны меньше чем в N переходов?
в частности насколько это возможно выкинуть на UI через какой-либо промежуточный сервис
да, немного улучшили, но главная позиция именно в «вам честный стриминг не нужен» и как результат мы имеем
http://beam.incubator.apache.org/capability-matrix/
причем для 2.0 спарка почти ничего не меняется
>> У вас есть какие-то предложения по их развитию
как минимум были предложения по https://github.com/amplab/spark-indexedrdd и которые местами мне интересны, в качестве быстрого распределенного хранилища, без необходимости тянуть сбоку imdb + получаем и локальность вычислений
>> Хм, в презентациях посвящённых Catalyst использовался, вполне себе dataframe-api и не было sql. Ну и потом, они же взаимозаменяемы и оптимизация будет одинаковой
не могут быть они полностью взаимозаменяемые, так как в dataframe как и у rdd хватает терминальных операций, а sql может состоять из нескольких слоев и проще выполнять push down для предикатов. с sql у нас на руках весь план запросов имеется. хотя для простых запросов действительно функционально одинаковы sql vs dataframe.
p.s. и самый простой вопрос который мне нравится к спарку: данные у меня приходят пускай и условно равномерно, но бывают всплески, как мне гарантировать что в какой-то момент я не захлебнусь? у того же beam/dataflow для окна есть тригеры по объему, что мне делать в этом случае со спарком, который не позволяет управлять размером очередного батча
streaming — как пилили микробатчи, так и будем пилить, ожидать честного стриминга не стоит и «он вам не нужен»
sql — как пилили кастомный Catalyst, так и будем пилить, плевать мы хотели на другие уже существующие и отлаженные инструменты (для примера https://calcite.apache.org/ )
rdd — забили на развитие, используйте dataframe
dataframe — пока юзайте, но учтите, что основные изменения у нас в sql, так что может и вам что от планировщика перепадет, но вообще лучше тоже двигайте в sql, там все оптимизации
и да, dataframe уже в разы быстрее чем rdd для питона, так как имеет схему и гонит данные в лямбды достаточно хорошо, поэтому arrow больше для общения между любыми системами интересно
я не спорю, что спарк развивается, но зачастую шумихи больше чем достижений
вот возьмите Фрунзенский район =) еще то веселье, даже в ванне запах хлорочки летом может стоять, про чай из этой воды я вообще молчу. Пока жил в Партизанском районе меня все и из под крана устраивало, а после переезда сразу начал покупать бутилированную, потом поставил фильтр с обратным осмосом.
1. sharding — у вас он ручной,
1.1 что делать если клиенты в разных шардах растут с разной скоростью и у нас на одном шарде 100млн, а на другом 1млн записей?
1.2 как делать перебалансировку в случае если нам нужно добавить +1 сервер в кластер
2. fault tolerance
2.1 мультимастер еще нужно уметь настраивать, в master-slave при выпадении master тоже веселье
если у вас 1 мастер и пачка слейвов, так как нагрузка на запись минимальная, почти все это чтение, то вам конечно повезло,
но ведь nosql любят в первую очередь за то, что у вас ключи разбиты по бакетам которых заметно больше чем серверов и эти бакеты свободно мигрируют между узлами (решаем задачу 1 с балансировкой и добавлением новых узлов), а выпавшего мастера автоматически подхватывает кто-то другой (в hbase и mongodb на основе кворума, у cassandra вообще мастера нету) (решаем задачу сложности конфигурации для задачи 2).
правда если уж начали про mysql в качестве nosql, то я бы ожидал услышать про handlersocket, чтобы проходить уже даже и мимо планировщика запросов, а сразу ломиться на получение данных
хоть и проходил опрос, но почему-то он не засчитался
подозреваю adblock может как-то весело сработал
в письме было что черновое видео будет доступно быстро, полное монтирование уже к концу мая
опрос заполнил и тишина, в итоге непонятно «опрос не засчитали или пока ничего и нету»?
1) плюс — мы не зависим от еще одной абстракции, точно управляем локальностью данных
2) минус — вопросы отказоустойчивости изобретаем повторно
наличие или отсутствие jvm зачастую сильно не решает основные вопросы: что и как храним и какие запросы делаем по данным,
так как практика показывает, что говнокод можно написать на любом языке =) хотя согласен что проект интересный и если будет опыт использования, то ждем статью ;)
Cassandra немного другая песня (сужу из опыта работы)
Scylladb пускай и заявляет скорость, но многих вещей кассандны еще не умеет
Для этого запускаются отдельные сервера-сервисы которые выступают проксей на нативный API и может оказаться, что узким местом и является этот самый прокси. Плюсом у вас клиент всегда стучится на один явный api сервер, а не на размазанный кластер, что очень хорошо позволяет сделать ограничение доступа.
Такая проблема возникла, что работа клиента представляет собой цикл: подключились к мастеру => забрали метаданные => постучались на нужный регион сервер. Сам же клиент при необходимости и метаданные у себя обновляет при миграции регионов, должен же он знать куда стучать. Накладываем на это собственный бинарный протокол и получаем, что сделать REST прокси на java оказывается проще, чем делать поддержку клиентов для разных языков. Сейчас ситуация исправляется за счет того, что протокол поменяли на protobuf и остается закодить только логику работы с серверами метаданных-данных, а не логику+бинарный протокол (который еще и меняли периодически).
Отдельно стоит упомянуть сопроцессоры (coprocessor) которые можно использовать как:
с другой стороны если у вас в кластере крутиться только spark для обработки и hive/map-reduce/etc отсутствуют, то yarn будет всего-лишь дополнительной прослойкой
говоря о плюсах-минусах YARN для SPARK мне кажется лишь стоит указать возможность использования кластера разными группами, так как YARN нам может дать гарантии по нарезанию ресурсов с лимитами и что dev задача не скушает весь prod. Но если у нас прод живет отдельно, то там YARN может оказаться оверхедом.
p.s. инструменты выбираются под задачу, а не задачи пытаются подтянуть под используемые инструменты, поэтому как и что гонять становится ясно только после полного изучения задачи и окружения ;)
HDFS НЕЛЬЗЯ поставить через YARN =) у них разные задачи
с помощью yarn можно:
1) развернуть spark
2) запустить map-reduce задачу
3) с определенными костылями запустить hbase
но вот yarn сам использует для некоторых задач hdfs, поэтому можно рассматривать что yarn работает поверх hdfs.
Думаю вы видели данную картинку, на которой видно что HDFS без YARN нормально живет и кушать не просит.
Эти задачи как раз и решает локальность данных, хотя если у вас на вход одна партиция и пару гигабайт данных, то glusterfs может и выиграет, но если имеется 2-3ТБ данных и 20 партиций которые могут локально отфильтровать-сгруппировать данные, то вы сразу проседаете в разы и локальность становится задачей номер 1. Именно поэтому те кто хотел бы использовать glusterfs в качестве замены HDFS пилят glusterfs-hadoop плагины для реализации hdfs интерфейсов по получению метаданных о том где какой блок лежит. Если уж нужен POSIX для hdfs, то FUSE драйвера для него существуют.
Примеры насколько важна локальность данных. А в вашей ссылке проверяли линейное чтение, что конечно полезно когда у вас хранилище отдельно, а обработка отдельно, но в большинстве случаев BigData это не имеет смысла, особенно когда чтение превышает в разы запись.
по поводу хранения:
не оказывается ли в итоге, что основную часть времени вы занимаетесь парсингом?
исходя из своего опыта могу сказать, что иногда проще сделать выборку, распарсить и сохранить в другую parquet-табличку и уже по ней гонять запросы, начиная со 2-3 запроса это окупается. Так как в этом случае вы даже сможете нормально DataFrame использоваться с его поколоночным хранением и компрессией.
можно подробней о каких продуктах идет речь? так как у нас математики без проблем читают паркет в питоновские датафреймы, impala & hive так вообще нативно подхватывают. Читать файлы из java тоже не составляет никакого труда.
он и не должен, это формат хранения ;) к тому же immutable
подозреваю хотели написать HDFS, но не суть
почему установка HDFS сразу же подразумевает установку YARN и остальных вещей? (у самого крутиться HDFS + HBase без какого-либо YARN). HDFS — распределенное хранилище, YARN — вычислительная платформа, они достаточно неплохо разделены. Поэтому от standalone spark кластера вас никто не заставляет отказываться, можете поднять hdfs + spark standalone, проблем никаких нету (подымал такую конфигурацию, от spark yarn отличий в разворачивании на клоудере вообще нету)
к тому же перейдя от NFS на HDFS вы получаете профит в виде локальности данных, ваши spark задачи будут отправляться на ноды на которых эти данные и лежат, а это сразу решает несколько проблем:
1) затыки на дисковом IO, ради чего вы и покупали ссд (все уйдет на локальные диски, которые в сумме выдадут за те же деньги в разы большую производительность)
2) затыки на сетевом интерфейсе (прокачать каких-то 1ТБ даже с 10Гбитной сеткой занимает существенное время, тут же будет независимое чтение с разных дисков и минимум нагрузка на сеть, если все-таки промахнемся с задачей)
HDFS ведь и придумывалось не только для распределенности, но и ради локальности данных (кстати это причина почему хадуп на SAN/NAS у меня вызывает улыбку) и GlusterFS в этом плане вам ничем не поможет, так как спарк не сможет получить распределение блоков.
в вашем примере я не понял как парсить и обрабатывать данный json с разной структурой? каждый раз проверяем наличие нужных полей и вложен или нет?
тут согласен, особенно если сверху еще какой dictionary encoding для строк пройдется, то зачастую вообще копейки на выходе
В общем spark на NFS имеет смысл там же где и GPU вычисления: входных-выходных данных мало, а вычислительной математики много
как это в уме по быстрому переводить пока никто не объяснил
1) аська никогда не хранила переписку в закрытом виде + логи на сервере
2) skype никогда не хранил переписку в закрытом виде + с недавнего времени логи на сервере
3) viber никогда не хранил переписку в закрытом виде + логи на сервере
4) whatsapp не хранит переписку в закрытом виде + логи на сервере
5) telegram не хранит переписку в закрытом виде ( habrahabr.ru/post/240521 с того момента вроде ничего не поменялось), хотя и позиционируются как защищенный мессенджер, но политика разрабов «конечные устройства защищайте сами»
поэтому я могу смело сказать: производителям начхать на безопасность конечных точек, максимум что они беспокоятся это о mitm атаках, а конечные устройства должны защищать сами пользователи (шифрованный раздел для desktop, шифрованная sd для телефонов и тд)
если у вас есть другие примеры, то с удовольствием выслушаю
ответ я думаю ожидаем =( мне это самому не нравится, но бизнесу не интересны технологии ради технологий, он строится немного для другого
1) у меня есть компьютер и телефон
2) ноуты я периодически меняю
3) телефоны бывают меняются еще чаще
как это все ДОСТУПНО объяснить рядовому пользователю например того же viber?
да он пошлет всех в известном направлении еще на этапе установки, так как каждое лишнее действие на этапе установки-настройки это потерянная аудитория.
поэтому есть масса людей которым плевать на их приватность (соцсети как пример), а уж если тебе так дорога приватность, то ты настроишь нормальные права доступа к папкам, все это запихаешь на шифрованный раздел, ну и конечно просто не будешь пользоваться этими мессенджерами которые всю историю хранят в открытом виде на серверах компании
p.s. кстати, я что-то не уловил часть: как нам читать наши же сообщения, если ключ где-то далеко, ну или ключ шифровать текущим паролем и сохранить рядом, но тогда остается вопрос что если у тебя украли пароль, то из старых баз вытянут твой ключ?
1) есть 2 компа и история синкается
2) на одном из них поменяли пароль на вайбер
3) на втором уже этим паролем не прочитать сообщения
поэтому придется выбирать одно из 2х:
1) на историю делаем еще один пароль именно для шифрования истории
2) храним ключ шифрования на сервере и после логина высылаем его на клиент
как делать правильно лично я признаюсь не знаю
на самом деле: полностью сменили архитектуру на микросервисы и event processing
почти любой кто видел тормозящий i2p на java и смотревший в исходники может подтвердить:
1) одна из основных проблем это большой context switch, так как на каждый поток ввода-вывода создает thread
2) почти полное отсутсвие использования nio, большинство вещей на стандартном io
3) наличие N потоков в каждом из которых имеется личный буфер дает дополнительное давление на память и gc
4) и уже только на четвертом месте оказывается само шифрование-дешифрование
в итоге мы вместо асинхронности и вменяемого потребления под различные буфера ввода-вывода сжираем почти все что можно
почему же не использовать netty и другие сетевые фреймворки?
ответ до банальности прост: безопасность, так как текущий код до ужаса прост, то и аудит его сделать проще, ну и отсутствует зависимость на сторонних библиотеках (через которых можно что-либо пропихнуть), только голый java core.