то 20000 записей сохраняются 3.6 секунды. Для однопоточного режима многовато, но если сделать 8 непересекающихся обработчиков (по числу ядер процессора), то будет достаточно.
Э-э-э-э… Почему распараллеливание кода решит эту проблему? Вы только больше за базу станете драться, разве нет?
Если я правильно понял, вы держите последние N хороших значений тоже в базе (в другой таблице, или типа того). Кто её чистит и как (иначе у вас диск скоро взорвется)? Скорее всего, обычного вотчдога будет достаточно, но неплохо бы замерить производительность и с ним тоже.
Да, именно для мьютексов есть задачи получше, я согласен, пример выбран так себе; но всё же и тут надо застраховаться от ситуации «вернули не самое последнее значение» — поэтому очередь и BULK WRITE — не вариант. Это не случайно написано в параграфе «Верификация». Придется писать прямо из обработчика входящего сообщения, вот там потребуется мьютекс, насколько мне кажется. Очередь нужно специально замерять, чтобы не оказаться в ситуации «курс скакнул, а мы всё еще не обработали новые значения». Кстати, вы же понимаете, да, что вот такая последовательность: (1)-1-1-1-1-2-2-2-2-2 должна приводить к (1)-2 (скачок: первые 4 раза раза мы думаем, что это выбросы, а вот на пятый уже понимаем, что это скачок), поэтому плохие значения тоже придется как-то хранить рядом с хорошими до поры до времени. И что если это не изолированная база, надо бы оставить какой-то минимальный шанс основному приложению туда ходить (это решается изоляцией, да).
Я обязательно покажу код, но пока благодаря вам (за что — искреннее человеческое спасибо) — закрываю сто лет висевшую надо мной задачу правильной генерации тестовых TimeSeries (начал генерировать данные вчера и вспомнил, что давно собирался сделать это по-человечески). Stay tuned.
Да, особенно учитывая, что даже в ситуации, когда у меня четко написано везде, где можно раздобыть мой почтовый адрес: «работу не ищу», — пару раз в неделю пробивается какой-нибудь особо одаренный HR с вопросом не хочу ни я попрограммировать на похапе в Норильске (только онсайт) за тридцать тысяч в год.
Поэтому для того, чтобы просто согласиться поговорить с потенциальным работодателем, мне нужен от них четкий ответ на вопрос: «Минимум, который меня может заинтересовать, если вы проектируете космические корабли, спасающие жизни детям — вот такой. Если это много — разговор будет бессмысленным».
Если вы используете обертку B, которая использует A, то потенциальные проблемы такие же, как если просто использовать A.
Обёртку B тестировали 40 лет на нагрузке, которой в мире больше нигде не существует, кроме приложений, использующих обертку B. Так что гарантий немного больше.
Выше вы про валюты говорили, пусть будут валюты.
Это будет не очень честно, потому что я схожую задачу уже решал. Но как хотите. Из стороннего источника приходят курсы валют (≈200 валют ⇒ ≈ 20K пар, обновления каждой примерно раз в секунду). Нужно для всех посчитать на основе последних пяти значений «примерное ожидаемое следующее» значение, сравнить с пришедшим, и если Δ больше 10% — отбросить, но сохранить в хранилище (любое), а если меньше — посчитать на основе его и предыдущих четырех — новое «усредненное значение», за которым могут по HTTP приходить клиенты (не чаще, чем 100/сек).
Со звездочкой: если курса нет больше, чем минуту — метрика должна покраснеть.
Верификация: нужны тесты, которые покажут, что последний курс — это действительно последний курс, и что значения за пределами доверенного интервала сохранены, но не попали в усреднение.
с оберткой, которую предоставляет язык или библиотека
Виртуальная машина.
Разумеется, виртуальная машина, позволяющая запустить миллион легковесных процессов на одном компьютере, в своем ядре в некоторых местах опирается на мьютексы. Разумеется, я работаю «с обёрткой», как и мьютекс с семафором — это просто обертка над хардверным интерраптом.
Цель ведь не «полностью избежать использования A», а именно что «никогда не видеть использования A», тут не олимпиадное программирование же.
Мне всё равно, какое приложение писать (готовые под NDA), но хотелось бы оговорить условия на берегу, а то я уже наелся всех этих «это не то», «это не так», «это не имелось в виду» и «это не обсуждалось». Можно хоть эквайринг из фейкового источника, который присылает по несколько тысяч реквестов в секунду (у нас много терминалов) на ну пусть миллион аккаунтов. Можно реплику хабра. Или сами предложите.
Я могу судить о кругозоре по комментариям. Вы продолжаете спорить о базе и транзакциях, хотя они прозрачно элиминируются акторной моделью, о чем я и писал.
Костылями повышать нагрузоустойчивость базы — плохой сценарий, но люди продолжают так делать, потому что про другие подходы ничего не знают.
Не, не все выполнятся на 99%, а только долгие, и они будут размазаны прозрачно по кластеру в эликсире. Метрики покраснеют, раскатится еще N нод, а коду из коробки всё равно, на какой ноде запускать процесс (для повторяемости это обычно хэшринг, но и раундробин подойдет).
За экстрасенсорику прошу прощения, просто пассаж про защиту от вайлтру — это явный признак теоретика.
вот это конкретно подпора для тех, кто боится что ктонить напишет while(true){}
Сразу видно, что ничего действительно параллельного вы никогда в жизни не писали.
Если горутин (гринтредов, эрланговских процессов) не два с половиной, как в туториале, а тысяч десять, или сто, — кооперативная многозадачность не работает в принципе, и не из-за закукливания, а просто потому, что время отклика становится непредсказуемым: 10мс для одной горутины — уже непозволительная роскошь, стотысячная получит управление через сами посчитайте сколько часов.
А в чем проблема писать все в Event Source? Я даже недавно опубликовал текст о моём фреймворке, который пишет всё в ивентсорс и на некоторых задачах кроет реляционную базу как бык овцу.
Для конца семидесятых годов прошлого века — это был бы прям прорыв.
Но после появления эликсира для тех, кого смущал синтаксис и развесистое метапрограммирование эрланга — а особенно в контексте современных мощностей, когда виртуальная машина уже никому не мешает, даже в IoT — выбирать го нет вообще никакого резона, кроме, разве что,, бо́льшей готовности LLM, да и то, с его убогой документацией — этот вопрос буквально доживает последние денёчки.
Горутины — это очень плохая абстракция, даже несмотря на то, что вытесняющая многозадачность — буквально первое, что они делают по уму. Но язык этим не спасти, надо с нуля переписывать.
Инфа сотка? А я ведь триста раз и в тексте, и в комментариях, рассказал и показал этот другой способ. В реляционной СУБД он нереализуем из-за shared resource. Но в прикладном коде он прекрасно реализуем. И в Event Source хранилищах. И еще в миллионе иных мест.
Но обязательно придёт эксперт, рассказать, что автомобиль в принципе не умеет развивать скорость выше 100 км/ч потому что его запорожец не может.
Э-э-э-э… Почему распараллеливание кода решит эту проблему? Вы только больше за базу станете драться, разве нет?
Если я правильно понял, вы держите последние N хороших значений тоже в базе (в другой таблице, или типа того). Кто её чистит и как (иначе у вас диск скоро взорвется)? Скорее всего, обычного вотчдога будет достаточно, но неплохо бы замерить производительность и с ним тоже.
Да, именно для мьютексов есть задачи получше, я согласен, пример выбран так себе; но всё же и тут надо застраховаться от ситуации «вернули не самое последнее значение» — поэтому очередь и BULK WRITE — не вариант. Это не случайно написано в параграфе «Верификация». Придется писать прямо из обработчика входящего сообщения, вот там потребуется мьютекс, насколько мне кажется. Очередь нужно специально замерять, чтобы не оказаться в ситуации «курс скакнул, а мы всё еще не обработали новые значения». Кстати, вы же понимаете, да, что вот такая последовательность:
(1)-1-1-1-1-2-2-2-2-2должна приводить к(1)-2(скачок: первые 4 раза раза мы думаем, что это выбросы, а вот на пятый уже понимаем, что это скачок), поэтому плохие значения тоже придется как-то хранить рядом с хорошими до поры до времени. И что если это не изолированная база, надо бы оставить какой-то минимальный шанс основному приложению туда ходить (это решается изоляцией, да).Я обязательно покажу код, но пока благодаря вам (за что — искреннее человеческое спасибо) — закрываю сто лет висевшую надо мной задачу правильной генерации тестовых TimeSeries (начал генерировать данные вчера и вспомнил, что давно собирался сделать это по-человечески). Stay tuned.
А откуда одна машина взялась? Я собирался кластер поднять, почему нет?
Если вас устраивает условие, код будет — я старался быть максимально честным — мне его придется написать, а не вытащить из рукава.
Насколько я помню, есть еще вариант с диспетчеризацией времени компиляции, как в плюсовых шаблонах и эрланговских многоголовых функциях.
P. S. Текст прекрасный совершенно, спасибо.
Да, особенно учитывая, что даже в ситуации, когда у меня четко написано везде, где можно раздобыть мой почтовый адрес: «работу не ищу», — пару раз в неделю пробивается какой-нибудь особо одаренный HR с вопросом не хочу ни я попрограммировать на похапе в Норильске (только онсайт) за тридцать тысяч в год.
Поэтому для того, чтобы просто согласиться поговорить с потенциальным работодателем, мне нужен от них четкий ответ на вопрос: «Минимум, который меня может заинтересовать, если вы проектируете космические корабли, спасающие жизни детям — вот такой. Если это много — разговор будет бессмысленным».
Обёртку B тестировали 40 лет на нагрузке, которой в мире больше нигде не существует, кроме приложений, использующих обертку B. Так что гарантий немного больше.
Это будет не очень честно, потому что я схожую задачу уже решал. Но как хотите. Из стороннего источника приходят курсы валют (≈200 валют ⇒ ≈ 20K пар, обновления каждой примерно раз в секунду). Нужно для всех посчитать на основе последних пяти значений «примерное ожидаемое следующее» значение, сравнить с пришедшим, и если Δ больше 10% — отбросить, но сохранить в хранилище (любое), а если меньше — посчитать на основе его и предыдущих четырех — новое «усредненное значение», за которым могут по HTTP приходить клиенты (не чаще, чем 100/сек).
Со звездочкой: если курса нет больше, чем минуту — метрика должна покраснеть.
Верификация: нужны тесты, которые покажут, что последний курс — это действительно последний курс, и что значения за пределами доверенного интервала сохранены, но не попали в усреднение.
Кроме SCADA, про которую я не очень в курсе, что это такое — да, и мне даже деньги платили за этот зоопарк в разные периоды времени.
У меня даже в профиле это написано.
Виртуальная машина.
Разумеется, виртуальная машина, позволяющая запустить миллион легковесных процессов на одном компьютере, в своем ядре в некоторых местах опирается на мьютексы. Разумеется, я работаю «с обёрткой», как и мьютекс с семафором — это просто обертка над хардверным интерраптом.
Цель ведь не «полностью избежать использования A», а именно что «никогда не видеть использования A», тут не олимпиадное программирование же.
Мне всё равно, какое приложение писать (готовые под NDA), но хотелось бы оговорить условия на берегу, а то я уже наелся всех этих «это не то», «это не так», «это не имелось в виду» и «это не обсуждалось». Можно хоть эквайринг из фейкового источника, который присылает по несколько тысяч реквестов в секунду (у нас много терминалов) на ну пусть миллион аккаунтов. Можно реплику хабра. Или сами предложите.
Наезд и клевета называются диффамацией.
Я могу судить о кругозоре по комментариям. Вы продолжаете спорить о базе и транзакциях, хотя они прозрачно элиминируются акторной моделью, о чем я и писал.
Костылями повышать нагрузоустойчивость базы — плохой сценарий, но люди продолжают так делать, потому что про другие подходы ничего не знают.
Опыт перпендикулярен кругозору.
Я ровно поэтому 10ms там и выбрал.
Не, не все выполнятся на 99%, а только долгие, и они будут размазаны прозрачно по кластеру в эликсире. Метрики покраснеют, раскатится еще N нод, а коду из коробки всё равно, на какой ноде запускать процесс (для повторяемости это обычно хэшринг, но и раундробин подойдет).
За экстрасенсорику прошу прощения, просто пассаж про защиту от вайлтру — это явный признак теоретика.
Нет, конечно. Это все было задолго до IBM придумано.
Какие еще нахрен флажки?
Я работаю в акторной модели, ивентлог тут триста раз упоминали, когда база нужна написано в тексте: хранить редкоизменяемые данные.
Вы просто в силу узости кругозора не понимаете, о чем тут идет речь. Так бывает.
Не получаем. Хватит уже рассуждать о том, в чем вы ничего не понимаете.
Любой эквайринг так работает, и половина крупных банков.
Транзакционный механизм не нужен практически никогда.
Это костыль, который больше мешает, чем помогает.
Сразу видно, что ничего действительно параллельного вы никогда в жизни не писали.
Если горутин (гринтредов, эрланговских процессов) не два с половиной, как в туториале, а тысяч десять, или сто, — кооперативная многозадачность не работает в принципе, и не из-за закукливания, а просто потому, что время отклика становится непредсказуемым: 10мс для одной горутины — уже непозволительная роскошь, стотысячная получит управление через сами посчитайте сколько часов.
Ассоциация хорошая, и после пары десятков лет стажа на механике — АКПП действительно упрощает жизнь, немного.
А в чем проблема писать все в Event Source? Я даже недавно опубликовал текст о моём фреймворке, который пишет всё в ивентсорс и на некоторых задачах кроет реляционную базу как бык овцу.
Для конца семидесятых годов прошлого века — это был бы прям прорыв.
Но после появления эликсира для тех, кого смущал синтаксис и развесистое метапрограммирование эрланга — а особенно в контексте современных мощностей, когда виртуальная машина уже никому не мешает, даже в IoT — выбирать го нет вообще никакого резона, кроме, разве что,, бо́льшей готовности LLM, да и то, с его убогой документацией — этот вопрос буквально доживает последние денёчки.
Горутины — это очень плохая абстракция, даже несмотря на то, что вытесняющая многозадачность — буквально первое, что они делают по уму. Но язык этим не спасти, надо с нуля переписывать.
Инфа сотка? А я ведь триста раз и в тексте, и в комментариях, рассказал и показал этот другой способ. В реляционной СУБД он нереализуем из-за shared resource. Но в прикладном коде он прекрасно реализуем. И в Event Source хранилищах. И еще в миллионе иных мест.
Но обязательно придёт эксперт, рассказать, что автомобиль в принципе не умеет развивать скорость выше 100 км/ч потому что его запорожец не может.