мы тут ведь обсуждаем не то, как сделать плохо? Плохо и без всего этого можно, плохо можно и в гарнитуру говорить и во встроенный микрофон. Подключение електретного микрофончика если и улучшит что-то, то весьма немного. С другой стороны, самый незамысловатый samson go mic ($29.97 на амазоне) который как раз по USB, будет звучать несравненно лучше.
Это откуда? Я привел из официального спека, т.е. это не я так называю, это apple так называет. Повторю — в маках никогда (последние 15 лет как минумум) не было микрофонного входа. То, что было совмещенным в 2012 (кажется) году было linein уровня. Туда нельзя втыкать микрофон хотя размер джека и подходит.
снобизм? Мне и в голову не могло прийти что «аналоговый микрофон» предлагается втыкать в микрофоный вход (если такой есть) в компьютере. У меня, например, такого нигде нет.
Но это совсем плохая идея, будет плохо. Тут, конечно, вопрос — насколько это хуже usb микрофона за те-же деньги, но я думаю что будет хуже.
Поделюсь своим, косвенным опытом. В мои открытые проекты приходят разные люди и, регулярно, приходят такие, кто без особого опыта и только с базовым знанием/навыком. Бывают совсем разного возраста, 35 никакого удивления у меня не вызывает.
Конечно, сложилось не со всеми, но с кем-то очень даже получилось. Работает это так — я, обычно сразу, поясняю, что на подробное менторство у меня нет времени и нам надо научится работать вместе так, чтоб обоим сторонам был интерес — для меня это решение задачи/починка/тикет/фича, для них — тренировка в условиях, близким к боевым и знания/умения. Совместная работа выглядит так, что я ставлю задачу примерно на уровне, как это происходит в реальной жизни, иногда поясняя дополнительно «куда коней запрягать» но без особых деталей, а на уровне «посмотри вон там», «почитай во это». Человек начинает копать задачу, в меру своего понимания, выдавая на гора PRs которые я, как правило, жестоко критикую. По началу неадекватно придирчиво, пока не сложится некий баланс, а потом примерно так, как я делаю в рабочих проектах, т.е. дотошно, но без особого терроризирования. В этих review я старюсь не предлагать своих решений, но наводить человека не правильный курс.
Такие совместные проекты на практике полезны обоим сторонам. У меня было несколько случаев, когда пришедшие почти с нуля оставляли наши совместные проекты от того, что находили работу. Вообще, завершение проекта происходит примерно в половине случаев, но я не в обиде. Даже недоделанный проект потом можно отдать следующему подопечному и, в результате, он будет завершен. Другая выгода для меня в том, что это помогает свежим взглядом посмотреть на то, чего люди не понимают и как им это пояснить максимально эффективно. Такой навык полезен и для своих проектов и для работы.
Я бы рекомендовал тем, кто уже умеет, устраивать подобное в своих личных проектах. Оно занимает не так много времени и не вызывает ощущение потраченных впустую усилий.
нет, мы решительно не понимаем друг друга. Как можно отметать бенчмарки и «оценивать субьективно» в чем-то, где есть требования по производительности и чем-то больше чем хобби проект на выходной — это никак не поддается моему пониманию.
Как это «просто append. Я те слово даю» на фоне того, что уже вроде выяснили, что вокруг этого навороченно скриптов с кронами и прочим — тоже. Видимо мы говорим совсем об очень разном видении организации систем. В моем понимании все, что я услышал это любопытный способ доступа к данным, обещающий скорость и простоту. Однако по поводу скорости никаких данных (кроме «пойди потыкай в страничку»), по поводу простоты — я пытался понять есть ли она, и не убедился в этом.
Ну так ты просто открой две биржи и сравни отзывчивость интерфейса.
я понятия не имею какие проблемы у конкурентов, какая у них отзывчивость и какой отзывчивости ожидают кленты. Кроме того, я не знаю что за конкуренты. Если тут приводится решения которое должно быть быстрым, я бы ожидал адекватных замеров скорости и собственно самих требований по времени отклика, скорости загрузки и прочее в этом роде. Посылать меня тыкать в конкурентов это неконструктивное предложение.
Эта модель уже год работает на нашей бирже. Никаких требований на горизонте еще 1 год на изменение нет.
это хорошо что нет. если есть такая уверенность в стабильности требований (в моей области такое практически не встречается) то это приятно.
Очевидным является то, что мы не можем влиять на кэш браузера.
эээ… что? С каких это пор? Мы очень даже можем влиять на то, что в этот кеш попадет и как оно там будет себя вести.
Можешь привести требования к развертыванию такой инфраструктуры? К компетенции персонала? Давай сравним.
Я выше уже привел пример. Какие еще требования нужны? И как сравнивать относительно стандартную инфраструктуру с набором самописных инфраструктурных кусков типа "будем просто по крону запускать на ноде скрипт ...". Мне трудно что-то пояснить в таком ключе если тебе кажется что это просто и вообще вся система это "просто append в файл очередной свечи". Даже из твоих не очень подробных пояснений видно, что нет — это не просто append, но ты почему-то отделяешь ту часть, что зовешь девопс в нечто, что к системе не относится.
Так можно и балансер уже к backend отнести. Что уж мелочиться то…
Можно, особенно если он с разным партизанством внутри. Вообще бекенды разными бывают, например вся твоя подготовкa свечек это вполне себе backend processor. Вместо некорретного "избавится от бэкенда" я бы сказал, что решение пыталось избавится от реализации своего rest/rpc/whatever части бэкенда.
Как же я на них посмотрю, если даже на описанное тобой решение посмотреть невозможно т.к. "Код, естественно, не будет опубликован."
Это будущее меняется по 40 раз на дню.
Вот именно. А эта модель из всех, что мне приходят в голову, наименне гибкая и категорически не готовая к самым минимальным изменениям.
В варианте с content-range, второй запрос не будет выполняться к серверу. Этот кусок браузер возьмет из своего кэша. Не профит ли это?
Возможно профит, а возможно и нет, все зависит от того по каким параметрам мы оптимизируем решение и для чего это делаем. Если цель это экономить размер кеша на серверной стороне, то вполне себе профит. Если на клиенте — то нет. Другой вопрос а надо ли его вообще эконномить в этом конкретном случае? Т.е. что именно было/предполагалось не так при попытке использования традиционных подходов к кешированию? И насколько это важно в данном случае.
CDN это, Content Delivery Net, ничего нового.
Ох, опять. Мои вопросы ничего общего с CDN не имееют. Выброси на минуту CDN из этой картины, логику работы CDN перед твоими нодами никак не меняет.
Но не кажется ли тебе, что это не относится вообще к рассматриваемой сути технологии? Это лишь классическая проблема синхронизации файловой системы которой уже 100 лет. не уж-то есть сомнения в том, что подобные задачи успешно решаются и нужно тут ее вообще рассматривать?
Конечно есть сомнения и конечно относится к сути технологии. То что "запрос возьмет готовые данные по смещению" переводит ту часть, что эти данные готовит и распределяет по нодам краеугольным камнем предложенной техники. Ну а что касается "классическая проблема синхронизации файловой системы" то эта проблема решается не сама, но десятком способов. Твой вариант с симлинками вовсе не единственный, да и вообще это не такая простая задача если ее решать аккуратно.
В случае если хартбит одной из нод «протух», что контролируется балансером ...
Все, что LB может понять в контектсе "протух" это недоступность определенного файла на nginx или timeout запроса, т.к. кроме статики тут ничего нет. Т.е. все что можно отловить это ситуацию полной потери ноды. При традиционном подходе вместо всей этой "включается скрипт, который переключает на прод сервере симлинк на «живую» папку", нода смогла бы отдать статус "временно недоступен" сама исходя из проверок целостности и актуальности данных, состояния ноды и прочее что недоступно из голого nginx. Ну и кроме того, вся эта техника с включением скриптов она несомненно часть того, что я бы назвал backend и который тут никуда не делся. Он просто стал… нетрадиционным.
Единая точка отказа в сервисах? Ну неужели есть шанс, что криптобиржа создает сервисы без дублирования?
Да откуда мне знать, как именно в вашей компании пишут системы. Это был первый ответ из всех комментов, который хоть что-то сказал по этому поводу.
Как я уже сказал, я ничего не имею против упрощния и движения в строну "все отдадим файлами или их частями". Я даже это горячо приветствую и сам подобный подход применяю, где он мне кажется адекватным. Например, в построении сайтов где можно обойтись исключительно статикой. Скажу больше — мы даже как-то в подкасте обсуждали возможность пре-генерации комментариев (в статику на s3) в моей системе remark42 и я вокруг этой идеи эксперементировал пока не убедился, что потеря гибкости не оправдывает подобного изменения.
Возращаясь к сути — если бы моя цель в подобном проекте была бы в категорическом отказе от своего бэкенда, т.е. то, что сейчас называют serverless, то я бы копал в сторону хранения данных вне ноды (s3, dynamo, aurora, elastic cache ...) и элементарной лямбды с "контроллером". Перед этим всем был бы ALB и, при необходимости географической близости к клиенту, CDN. При этом я бы хранил только один набор свечек с минимальной дискретностью и строил бы свечки другого размера на лету (или отдавал бы из кеша/редиса, если они уже там). Скорее всего я бы не завязывался на такой суровый бинарный формат и отдавал чем-то более гибким. При том, что подобная инфраструктура кажется более сложной с одной стороны, она позволяет избежать большую часть того, что сейчас приходится делать в batch режиме и не городить свои скрипты для обеспечения адекватной надежности и, в сухом остатке, вполне может оказаться даже проще чем предложенная техника надежного построения и отдачи свечей.
Как ты, возможно, заметил, я не упоминал свою особую компетенность и задавал, как мне кажется, вполне резонные технические вопросы исходя из описанного решения и его заявленных целей, которые может задать любой читатель этой статьи, вне особого опыта с конкретной бизнесс областью. Я вполне ценю желание сделать проще и приветствую инициативу не вводить лишних сущностей сверх необходимого, однако в описанном случае мне это простота видится кажущейся, перекладывающей сложость «на потом» и игнорирующей проблемы, которыми надо заниматься если речь идет о продашен системе, которая больше чем POC, MVP или демо.
В этом разрезе вопросы о том, что может пойти не так (попроченные файлы, упавший процесс подготовки, потеря сервера подготовки данных, потенциальная синхронизация и/или share диски, варианты с необходимость пере-аграгации свечей ...) — это все не из желания написать «грязный комментарий» (что бы оно для автора не означало) но от вполне резонных сомнений в качестве этого решения. А ответы «это не случится… маловероятно… что может пойти не так ...» мне видятся плохими и неприемлимыми в любом серьезном проекте.
Вся эта тема меня затронула от того, что много лет назад я и сам внедрил нечто подобное, когда market data (для обычных бирж) сохранялась в бинарных файлах (в моем случае это были записи сериализованные protobuf) и доступалась очень тонким слоем backend. Именно негативный опыт и трудность поддержки такого решения и вызвали мои вопросы к предложенному способу.
Я не просто так задавал вопросы о том, что это решение оптимизирует и какую проблему оно решает, т.к. это корень в понимании того, насколько принятые trade-offs адекватны, а не попытка поймать собеседника на противоречиях.
Ну и вообще, я не понимаю при чем тут моя личность и профили. Тут, в этой статье, речь шла о техническом решеннии и, как мне казалось, обуждать стоило именно это решение а не личную историю участников дискуссии. Попытка послать несогласных с решением… «погуглить что таке CDN» и прочие «учить современные WEB технологии» мне видится негодным способом ведения технических дискуссий.
сайт я вижу, но вопрос про код. Очевидно, не про тот код, что со стороны клиента, но тот код о котором мы говорили, т.е. подготовки данных. Иначе я просто не понимаю что именно я могу увидеть и/или проверить.
Если собеседник (я) не согласен с предложенным решением и/или пытается понять, как и насколько это решение адкватно и, самое главное, что именно оно пытается оптимизировать — это вовсе не значит что собеседник не в теме и у него «просто нет достаточного опыта». Это, например, может означать что решение ему кажется неадкеватным задаче, или что решение описано таким образом, когда понять его трудно.
Посылать меня изучать «что такое CDN» в надежде, что это добавить ясности как ваш внутренний процесс доставки через rsync, который «решает ее легко и непринужденно» вместо ответа на вполне резонные технические вопросы тоже не добавляет уверенности и, даже, вызывает определенные опасения.
> При всем уважении, комментировать нет смысла. Если вы backend и nginx ставите на один уровень.
эээ… а что тут не так? оба варианта требуют управления этими процессами. Никакой мистической сложности в таком бекенде (в его разработке) не будет и основное, чем надо будет заниматься в операционном плане (логи, мониторинг, метрики, дистибуция ...) будет отличаться мало чем. Вот если из этого варианта вообще исключить свой server side и обойтить без nginx, то тогда это было бы разного уровня.
т.е. это не про оптимизацию вовсе, но про желание избежать написание backend сервера. Во всяком случае такое мое понимание из текста и ответов, т.к. никаких намеков на что именно тут оптимизировалось еще, я не нашел.
А из чего следует, что «полностью решили вопрос высокой нагрузки при обращении к маркет-дата»? Что такое, в этом контексте, «высокая нагрузка» и как это решение масштабируется горизонтально? Как, в такой схеме, достигается надежность и отсутствие единой точки отказа? Куда кладутся все это файлы вообще, если не на локальную FS? В тексте упоминается «классическая проблема синхронизации файловой системы. Команда DevOps решает ее легко и непринужденно. Например используя rsync.», т.е. видимо таки локальная FS. Однако сказать, что задача «решается лего» это сильное упрощение, ну а при чем тут devops я вообще не понял.
На мой взгляд, это решние непонятной мне проблемы «как приготовить и распределить данные так, чтоб от бэкенда остался только nginx». Оно, как мне кажется, неопраданно усложняет процесс подготовки данных, прибивает реализацию к nginx гвоздями и критично к любым проблемам на этапе этой подготовки, типа rsync не смог доставить данных, процесс подготовки файлов на мастере завис/упал, да и вообще этот мастер, что файлы строит — это единая точка отказа. Работа с двумя/несколькими мастерами требует каких-то дополнительных решений. Попытки решить все эти проблемы (если они для вас являются проблемами) усложнят систему еще более, возможно до такого уровня, что уже станет понятно — с традиционным бэкендом было бы проще. Ну, например, как этот кластер заставить выбрасывать серверы, на которые не смогли доставить свежие файлы и/или на которых оказались поврежденные файлы? Видимо для этого нужны еще какие контрольные файлы чтоб их использовать для проверок здоровья. И так далее…
Она решается разными способами. Однако, ее решение, в общем случае, плохо совместимо с предложенной схемой хранения и доступа. Я вполне могу представть случай, когда свечи хранятся за долгий период в какой-то оптимизированной форме, а данные для аналитики хранятся другим образом (за меньший период) и доступаются через другой бэкенд. У меня все примерно так и делается, однако идея хранить десятки тысяч candle файлов за каждый день (количество инструментов * на количество видов свечей) не вызывает оптимизма в мире, где торгуются множественные сущности. Кроме того, становится непонятным главный вопрос — а зачем это было надо? Ответ про меньше размер сам по себе недостаточен (можно не менее эффективно хранить в нормальном сторе) остается только часть «не будет бэкенда», что тоже лукаво, т.к. вместо разработки своего сервиса по отдаче будет настройка nginx на такую отдачу, т.е. nginx будет вполне себе бэкендом который где-то бежит и кем-то мониторится/контролирруется.
Тут выше спрашивали про бечмарки, которые могли бы хоть намекнуть какую проблему это решение пыталось покрыть. Я с трудом себе представляю суровые трбебования для забора даже минутных свечек, т.е. их просто надо показать так, чтоб было достаточно быстро на стороне UI. С этой задачей справится что угодно, практический любой стор сможет их вернуть быстро хоть в виде бинарных данных, хоть в виде json/proto/bson/msgpack/…
Но это совсем плохая идея, будет плохо. Тут, конечно, вопрос — насколько это хуже usb микрофона за те-же деньги, но я думаю что будет хуже.
И совсем не все недорогие usb микрофоны так уж плохи, Samson Q2U за $50-$70 вполне нормально будет.
Конечно, сложилось не со всеми, но с кем-то очень даже получилось. Работает это так — я, обычно сразу, поясняю, что на подробное менторство у меня нет времени и нам надо научится работать вместе так, чтоб обоим сторонам был интерес — для меня это решение задачи/починка/тикет/фича, для них — тренировка в условиях, близким к боевым и знания/умения. Совместная работа выглядит так, что я ставлю задачу примерно на уровне, как это происходит в реальной жизни, иногда поясняя дополнительно «куда коней запрягать» но без особых деталей, а на уровне «посмотри вон там», «почитай во это». Человек начинает копать задачу, в меру своего понимания, выдавая на гора PRs которые я, как правило, жестоко критикую. По началу неадекватно придирчиво, пока не сложится некий баланс, а потом примерно так, как я делаю в рабочих проектах, т.е. дотошно, но без особого терроризирования. В этих review я старюсь не предлагать своих решений, но наводить человека не правильный курс.
Такие совместные проекты на практике полезны обоим сторонам. У меня было несколько случаев, когда пришедшие почти с нуля оставляли наши совместные проекты от того, что находили работу. Вообще, завершение проекта происходит примерно в половине случаев, но я не в обиде. Даже недоделанный проект потом можно отдать следующему подопечному и, в результате, он будет завершен. Другая выгода для меня в том, что это помогает свежим взглядом посмотреть на то, чего люди не понимают и как им это пояснить максимально эффективно. Такой навык полезен и для своих проектов и для работы.
Я бы рекомендовал тем, кто уже умеет, устраивать подобное в своих личных проектах. Оно занимает не так много времени и не вызывает ощущение потраченных впустую усилий.
Какой-то детский сад. Да, я такого рода «технические дискуссии» вести не умею. Не важно — вот и славно, мне больше спрашивать тут нечего.
Как это «просто append. Я те слово даю» на фоне того, что уже вроде выяснили, что вокруг этого навороченно скриптов с кронами и прочим — тоже. Видимо мы говорим совсем об очень разном видении организации систем. В моем понимании все, что я услышал это любопытный способ доступа к данным, обещающий скорость и простоту. Однако по поводу скорости никаких данных (кроме «пойди потыкай в страничку»), по поводу простоты — я пытался понять есть ли она, и не убедился в этом.
я понятия не имею какие проблемы у конкурентов, какая у них отзывчивость и какой отзывчивости ожидают кленты. Кроме того, я не знаю что за конкуренты. Если тут приводится решения которое должно быть быстрым, я бы ожидал адекватных замеров скорости и собственно самих требований по времени отклика, скорости загрузки и прочее в этом роде. Посылать меня тыкать в конкурентов это неконструктивное предложение.
это хорошо что нет. если есть такая уверенность в стабильности требований (в моей области такое практически не встречается) то это приятно.
эээ… что? С каких это пор? Мы очень даже можем влиять на то, что в этот кеш попадет и как оно там будет себя вести.
Я выше уже привел пример. Какие еще требования нужны? И как сравнивать относительно стандартную инфраструктуру с набором самописных инфраструктурных кусков типа "будем просто по крону запускать на ноде скрипт ...". Мне трудно что-то пояснить в таком ключе если тебе кажется что это просто и вообще вся система это "просто append в файл очередной свечи". Даже из твоих не очень подробных пояснений видно, что нет — это не просто append, но ты почему-то отделяешь ту часть, что зовешь девопс в нечто, что к системе не относится.
Можно, особенно если он с разным партизанством внутри. Вообще бекенды разными бывают, например вся твоя подготовкa свечек это вполне себе backend processor. Вместо некорретного "избавится от бэкенда" я бы сказал, что решение пыталось избавится от реализации своего rest/rpc/whatever части бэкенда.
Как же я на них посмотрю, если даже на описанное тобой решение посмотреть невозможно т.к. "Код, естественно, не будет опубликован."
Вот именно. А эта модель из всех, что мне приходят в голову, наименне гибкая и категорически не готовая к самым минимальным изменениям.
Возможно профит, а возможно и нет, все зависит от того по каким параметрам мы оптимизируем решение и для чего это делаем. Если цель это экономить размер кеша на серверной стороне, то вполне себе профит. Если на клиенте — то нет. Другой вопрос а надо ли его вообще эконномить в этом конкретном случае? Т.е. что именно было/предполагалось не так при попытке использования традиционных подходов к кешированию? И насколько это важно в данном случае.
Конечно есть сомнения и конечно относится к сути технологии. То что "запрос возьмет готовые данные по смещению" переводит ту часть, что эти данные готовит и распределяет по нодам краеугольным камнем предложенной техники. Ну а что касается "классическая проблема синхронизации файловой системы" то эта проблема решается не сама, но десятком способов. Твой вариант с симлинками вовсе не единственный, да и вообще это не такая простая задача если ее решать аккуратно.
Все, что LB может понять в контектсе "протух" это недоступность определенного файла на nginx или timeout запроса, т.к. кроме статики тут ничего нет. Т.е. все что можно отловить это ситуацию полной потери ноды. При традиционном подходе вместо всей этой "включается скрипт, который переключает на прод сервере симлинк на «живую» папку", нода смогла бы отдать статус "временно недоступен" сама исходя из проверок целостности и актуальности данных, состояния ноды и прочее что недоступно из голого nginx. Ну и кроме того, вся эта техника с включением скриптов она несомненно часть того, что я бы назвал backend и который тут никуда не делся. Он просто стал… нетрадиционным.
Да откуда мне знать, как именно в вашей компании пишут системы. Это был первый ответ из всех комментов, который хоть что-то сказал по этому поводу.
Как я уже сказал, я ничего не имею против упрощния и движения в строну "все отдадим файлами или их частями". Я даже это горячо приветствую и сам подобный подход применяю, где он мне кажется адекватным. Например, в построении сайтов где можно обойтись исключительно статикой. Скажу больше — мы даже как-то в подкасте обсуждали возможность пре-генерации комментариев (в статику на s3) в моей системе remark42 и я вокруг этой идеи эксперементировал пока не убедился, что потеря гибкости не оправдывает подобного изменения.
Возращаясь к сути — если бы моя цель в подобном проекте была бы в категорическом отказе от своего бэкенда, т.е. то, что сейчас называют serverless, то я бы копал в сторону хранения данных вне ноды (s3, dynamo, aurora, elastic cache ...) и элементарной лямбды с "контроллером". Перед этим всем был бы ALB и, при необходимости географической близости к клиенту, CDN. При этом я бы хранил только один набор свечек с минимальной дискретностью и строил бы свечки другого размера на лету (или отдавал бы из кеша/редиса, если они уже там). Скорее всего я бы не завязывался на такой суровый бинарный формат и отдавал чем-то более гибким. При том, что подобная инфраструктура кажется более сложной с одной стороны, она позволяет избежать большую часть того, что сейчас приходится делать в batch режиме и не городить свои скрипты для обеспечения адекватной надежности и, в сухом остатке, вполне может оказаться даже проще чем предложенная техника надежного построения и отдачи свечей.
В этом разрезе вопросы о том, что может пойти не так (попроченные файлы, упавший процесс подготовки, потеря сервера подготовки данных, потенциальная синхронизация и/или share диски, варианты с необходимость пере-аграгации свечей ...) — это все не из желания написать «грязный комментарий» (что бы оно для автора не означало) но от вполне резонных сомнений в качестве этого решения. А ответы «это не случится… маловероятно… что может пойти не так ...» мне видятся плохими и неприемлимыми в любом серьезном проекте.
Вся эта тема меня затронула от того, что много лет назад я и сам внедрил нечто подобное, когда market data (для обычных бирж) сохранялась в бинарных файлах (в моем случае это были записи сериализованные protobuf) и доступалась очень тонким слоем backend. Именно негативный опыт и трудность поддержки такого решения и вызвали мои вопросы к предложенному способу.
Я не просто так задавал вопросы о том, что это решение оптимизирует и какую проблему оно решает, т.к. это корень в понимании того, насколько принятые trade-offs адекватны, а не попытка поймать собеседника на противоречиях.
Ну и вообще, я не понимаю при чем тут моя личность и профили. Тут, в этой статье, речь шла о техническом решеннии и, как мне казалось, обуждать стоило именно это решение а не личную историю участников дискуссии. Попытка послать несогласных с решением… «погуглить что таке CDN» и прочие «учить современные WEB технологии» мне видится негодным способом ведения технических дискуссий.
Посылать меня изучать «что такое CDN» в надежде, что это добавить ясности как ваш внутренний процесс доставки через rsync, который «решает ее легко и непринужденно» вместо ответа на вполне резонные технические вопросы тоже не добавляет уверенности и, даже, вызывает определенные опасения.
эээ… а что тут не так? оба варианта требуют управления этими процессами. Никакой мистической сложности в таком бекенде (в его разработке) не будет и основное, чем надо будет заниматься в операционном плане (логи, мониторинг, метрики, дистибуция ...) будет отличаться мало чем. Вот если из этого варианта вообще исключить свой server side и обойтить без nginx, то тогда это было бы разного уровня.
А из чего следует, что «полностью решили вопрос высокой нагрузки при обращении к маркет-дата»? Что такое, в этом контексте, «высокая нагрузка» и как это решение масштабируется горизонтально? Как, в такой схеме, достигается надежность и отсутствие единой точки отказа? Куда кладутся все это файлы вообще, если не на локальную FS? В тексте упоминается «классическая проблема синхронизации файловой системы. Команда DevOps решает ее легко и непринужденно. Например используя rsync.», т.е. видимо таки локальная FS. Однако сказать, что задача «решается лего» это сильное упрощение, ну а при чем тут devops я вообще не понял.
На мой взгляд, это решние непонятной мне проблемы «как приготовить и распределить данные так, чтоб от бэкенда остался только nginx». Оно, как мне кажется, неопраданно усложняет процесс подготовки данных, прибивает реализацию к nginx гвоздями и критично к любым проблемам на этапе этой подготовки, типа rsync не смог доставить данных, процесс подготовки файлов на мастере завис/упал, да и вообще этот мастер, что файлы строит — это единая точка отказа. Работа с двумя/несколькими мастерами требует каких-то дополнительных решений. Попытки решить все эти проблемы (если они для вас являются проблемами) усложнят систему еще более, возможно до такого уровня, что уже станет понятно — с традиционным бэкендом было бы проще. Ну, например, как этот кластер заставить выбрасывать серверы, на которые не смогли доставить свежие файлы и/или на которых оказались поврежденные файлы? Видимо для этого нужны еще какие контрольные файлы чтоб их использовать для проверок здоровья. И так далее…
Она решается разными способами. Однако, ее решение, в общем случае, плохо совместимо с предложенной схемой хранения и доступа. Я вполне могу представть случай, когда свечи хранятся за долгий период в какой-то оптимизированной форме, а данные для аналитики хранятся другим образом (за меньший период) и доступаются через другой бэкенд. У меня все примерно так и делается, однако идея хранить десятки тысяч candle файлов за каждый день (количество инструментов * на количество видов свечей) не вызывает оптимизма в мире, где торгуются множественные сущности. Кроме того, становится непонятным главный вопрос — а зачем это было надо? Ответ про меньше размер сам по себе недостаточен (можно не менее эффективно хранить в нормальном сторе) остается только часть «не будет бэкенда», что тоже лукаво, т.к. вместо разработки своего сервиса по отдаче будет настройка nginx на такую отдачу, т.е. nginx будет вполне себе бэкендом который где-то бежит и кем-то мониторится/контролирруется.
Тут выше спрашивали про бечмарки, которые могли бы хоть намекнуть какую проблему это решение пыталось покрыть. Я с трудом себе представляю суровые трбебования для забора даже минутных свечек, т.е. их просто надо показать так, чтоб было достаточно быстро на стороне UI. С этой задачей справится что угодно, практический любой стор сможет их вернуть быстро хоть в виде бинарных данных, хоть в виде json/proto/bson/msgpack/…