SELECT datetime, ballot.decrypted_choice[1] as choice
FROM public.decrypted_ballots as ballot
JOIN public.transactions as trans_store
ON (ballot.store_tx_hash = trans_store.hash)
WHERE ballot.decrypted_choice[1] in (217404809,136749451) ORDER BY datetime
Поправка: меняешь байт (по битово перебирать нельзя ибо перезаписывать можно только по байтово.) Вероятность угадать байт 1/256 и того за (в среднем) 1024 попытки перебирается 8 байт.
Всё относительно просто: меняешь один бит в канарейке, если приложение упало то не угадал, приложение перефокнулось и пытаешься снова. И того на каждый бит у тебя 50/50 шанс — 8 байт так перебрать можно очень быстро.
Текущий план решить эту проблему с Envoy — кеширование + проксирование в S3 (или любой другой object storage). Оно проще:
с точки зрения поддержки. Не нужно поддерживать stateful сервис: серверов раздающих статику обычно несколько так что нужно мониторить что файлы на всех серверах есть и хеши совпадают.
с точки зрения разработки. У программистов появляется API для работы со статикой (S3 API или подобный), вместо сложной интеграции с системой деплоя для пуша новой версии статики по всем серверам.
Хотелось бы чуть больше информации по эксплуатации этой системы.
По структурной целостности:
Как бекапите метаданные Андрей Бородин рассказывал в лекции "Разгоняем бэкап". Было бы интересно услышать больше про то как эти бекапы верифицируются. В QnA секции прошлись по этому немного, но только с точки зрения физической структуры (checksum'ы и index'ы), а не логической — то что бекап действительно является репликой существующей базы и способен подключиться к кластеру как слейв.
Какие verifier'ы вы запускаете на данных, например, как вы проверяете что реплики не разошлись, что данные что были записаны всё ещё доступны и тд и тп? Shameless plug: у нас кажется верификаций больше чем кода самого приложения.
По доступности:
Что за система отвечает за замену умерающих/мёртвых машин. Особенно интересен случай мееедленно умирающей машины, который очень сложно отличить от перегрева шарда.
Как боритесь с горячими шардами по IOPS/QPS?
Ну и около-админские вещи: как вы безопасно деплоите код/ОС/прошивки/железо на кластер, как мониторите всю систему, итд итп
Я не фанат SQL, поэтому если бы я проектировал эту систему, то спрятал бы S3DB за API и сделал бы всю коммуникацию RPC-based (у нас внутри gRPC, у FB Thrift) ala services.
Meta бы делал на Zookeeper/etcd, чтобы Proxy могли подписываться на изменения "топологии". S3DB "сервис" бы в случае ошибки маршрутизации просто бы говорил, что proxy ошиблась и ей нужно получить новую таблицу у Meta. Что же использует S3DB для хранения не так важно, это может быть Postgres/MySQL/RocksDB/etc.
Ну и да, если бы это делалось в Dropbox, то полный S3 API мы бы наверное не поддерживали, а в замен сделали бы свой S3-подобный API. Описали бы протобафы, а код для клиентов под все языки сгенерился бы автоматом (aka codegen).
Disclaimer: в своё время я работал над Elliptics: делал из eblob LSM и писал первые версии dnet_recovery.
На самом деле "многофазное" удаление это очень хорошая практика в любой системе хранения. Основной её плюс в том, что она позволяет легко "откатить" состояние базы данных на уровне приложения без танцев с бинлогами/бекапами/снапшотами/логамибубном.
Двухшаговое удаление ещё упрощает написание verifier'ов которые следят за нарушениями соглашений "модели данных", например о том что данные которые были "удалены" в одной базе всё ещё имеют живые ссылки в какой-либо другой базе. У нас так регулярно находятся проблемы в процедуре подчистки базы от старых ревизий файлов, не потому что она бажная, а потому что мир вокруг неё меняется.
ПС. Вау! У кого-то серьёзный батхёрт на тему высшего образования. Ну и уровней абстракций походу тоже.
ПС. Забавно, что статья думалась на русском, писалась на английском, потом американский редаткор страдал, правя сложносочинённые конструкции, а теперь результат опять на "великом и могучем".
ППС. Вы пропустили последний абзац, но я так понимаю, это плата за перевод =)
На больших нагрузках nginx может блокировать eventloop на:
Записи логов. В случае access_log'ов — может сильно помочь директива buffer=. Однако в идеале лучше писать логи напрямую в syslog.
Записи тел запросов и ответов на диск. Тут хорошо помогает костыль в виде aio threads. Однако, насколько я понимаю, он не работает для приёма файлов, только на отдачу.
(Почему костыль? Потому что в идеале aio должно работать через нативный аснихронный интерфейс к файловой системе, а не эмулироваться через thread pool, но в *nix ОС с этим всё плохо).
В худшем случае, nginx начинает блокироваться на TLS хендшейках: если вы используете RSA 2048 это примерно 2мс на handshake. В новом OpenSSL 1.1.0 появилось асинхронное API, но в nginx оно если и попадёт, то не скоро. (Патчи по интернетам ходят, но до продакшна я бы их не допускал пока).
Были ещё сложные случаи со сжатием, когда люди пытаются максимально сжать статику (например, gzip 9 и brotli 11). в таких случаях сильно лучше статику pre-сжимать в офлайне и использовать gzip_static и brotli_static. Что делать если хочется по-максимуму сжимать динамку пока не понятно, но оно обычно того не стоит. (Можно, наверное, сжимать на backend'е(или маленьком sidecar-демоне), но это значит больше нельзя применять никакие body-filter'ы).
Image Filter'ы скорее всего тоже могут блокировать eventloop, но я, если честно, код не смотрел, ибо не использовал — все конторы в которых я работал писали простенькие backend'ы для "тяжёлых" манипуляций типа resize/recompress/crop/etc.
Проблема лишь в том, что маленький ssl_buffer_size добавляет измеримый CPU-overhead. И если есть желание оптимизировать один и тот же конфиг для пропускной способности и низкой задержки, то необходимо вручную выставлять нужный размер буферов для каждого server/location блока в зависимости от гистограммы размеров ответов.
Не забывайте, что irq affinity можно навешивать не только на сетевухи, но и на storage девайсы
Новые сетевухи умеют `adaptive-rx`/`adaptive-tx`, совсем новые `rx-usecs-high`
NUMA лучше не interleave'ить, а использовать по назначению. Запустите N инстансов приложения. Каждое на своей ноде. Каждой свой CPU и память, а так же сетевуху (NUMA ноду для irq affinity через можно определить от /sys/class/net/eth*/device/numa_node) и свой набор IP'шников. Далее на вышестоящем балансере (я так пологаю IPVS) считать каждую NUMA-ноду за отдельный хост
Для файлсерверов очень опасна/proc/sys/vm/zone_reclaim_mode — важно, чтобы оно было выставленно в ноль
Уже не совсем в тему оптимизации производительности, а скорее ускореения пользователей — стоит поиграться с TCP congestion алгоритмами (Netflix написали свой оптимизированый для видео и их склиентов: cc_netflix) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)
Если бы у вас были интерактивные штуки, а не видео, то было бы интересно поиграться с buffer bloat (sch_fq, tsq, bql, etc).
# perf probe -x /bin/bash 'readline%return +0($retval):string'
Added new event:
probe_bash:readline (on readline%return in /bin/bash with +0($retval):string)
You can now use it in all perf tools, such as:
perf record -e probe_bash:readline -aR sleep 1
# perf record -e probe_bash:readline -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.259 MB perf.data (2 samples) ]
# perf script
bash 26239 [003] 283194.152199: probe_bash:readline: (48db60 <- 41e876) arg1="ls -l"
bash 26239 [003] 283195.016155: probe_bash:readline: (48db60 <- 41e876) arg1="date"
# perf probe --del probe_bash:readline
Removed event: probe_bash:readline
Из доступных рядовому юзеру кросс-платформенных open-source'ных torrent-клиентов сейчас есть, как минимум, transmission — при особом желаннии провайдеры/трекеры могут начать продвигать свои BEP'ы и контрибьютить код в апстрим.
Bitcoin в качестве proof-of-work использует количество правильно про-brute-force'иных бит sha256 хеша. То есть, жжошь CPU — получаешь деньги «из воздуха». Если придумать как делать proof-of-work на основе сремени хранения данных на диске, то можно построить экономическую систему, где новая валюта получаются путём генерации востребованного контента, а существующая получается через/тратится через скачивание/раздачу контента и аренду места/полосы у других участников сети под свои данные (тут можно замутить аукцион). Опять же, как описать всё это математически и защитить цифровыми подписями — отдельный вопрос
Фактически, всё вышеописанное, это ровно то как сейчас работают трекеры, где в качестве валюты используется «ratio» (которое отражает сколько раздач и как долго ты хранишь). Всё централизовано и в качестве регулятора валюты выстурает трекер. Разве, что в торренте нет способа пропросить кого-либо хранить и раздавать твои данные в обмен на свой ratio.
Отдельный вопрос как анонимизировать всё это. В bitcoin вся история транзакций публична, что может сильно усложнить дальнейшую «анонимизацию» пользователей такой bitcoin-style p2p системы.
В общем, дискуссия про то как скрестить p2p и bitcoin вполне потянет докторскую. Тема интересная, да.
В далёком 2007 году, когда мало кто мог представить, какая цензура будет грозить российскому интернету, мы в NNM-Club обсуждали альтернативы bittorrent'у: Share & WinNY: японские p2p
Что самое интересное все три сети Winny, Share и Perfect Dark родом из японии, где шарить в сети аниме весьма распространённое и довольно опасное занятие.
Ещё в последнее время сильно набрал популярность Freenet.
Данные сети частично используют идеи из этого поста, частично из I2P/tor, частично из bittorrent. Но в любом случае все они сильно отличаются от того, что мы на данный момент имеем в мире торрент-трекеров. Думаю преминив некоторое кол-во усилий можно написать «прокси» из bittorrent в анонимные сети (например, freenet) и сделать его плагином к торрент-клиентам, чтобы то, что было скчано/роздано через bittorrent автоматом клалось и туда. Посути такой dual-stack получится (прям как во время перехода с IPv4 на IPv6). Я делал что-то подобное когда использовал Direct Connect и Bittorrent: то что у меня скачивалось rtorrent'ом автоматически шарилось в DC++.
Я просто оставлю это здесь: https://twitter.com/HaloCrypto/status/1590417311839981569 (6 месяцев назад)
Могу подтвердить данные в ролике по 198ому округу на основе данных блокчейна (абсолютное и относительное кол-во голосов Брюхановой и Хованской)
Данные брались из официального блокчейна: (+ ручное декодирование недостающих голосов)
Поправка: меняешь байт (по битово перебирать нельзя ибо перезаписывать можно только по байтово.) Вероятность угадать байт 1/256 и того за (в среднем) 1024 попытки перебирается 8 байт.
Самое забавное, что за переход отвечали Олег из Подмосковья и Руслан из Екатеринбурга, а рядом держал свечку Питерский наркоман Алексей =)
Всё относительно просто: меняешь один бит в канарейке, если приложение упало то не угадал, приложение перефокнулось и пытаешься снова. И того на каждый бит у тебя 50/50 шанс — 8 байт так перебрать можно очень быстро.
Текущий план решить эту проблему с Envoy — кеширование + проксирование в S3 (или любой другой object storage). Оно проще:
Хотелось бы чуть больше информации по эксплуатации этой системы.
По структурной целостности:
По доступности:
Ну и около-админские вещи: как вы безопасно деплоите код/ОС/прошивки/железо на кластер, как мониторите всю систему, итд итп
Весьма практическая статья, спасибо.
Я не фанат SQL, поэтому если бы я проектировал эту систему, то спрятал бы S3DB за API и сделал бы всю коммуникацию RPC-based (у нас внутри gRPC, у FB Thrift) ala services.
Meta бы делал на Zookeeper/etcd, чтобы Proxy могли подписываться на изменения "топологии". S3DB "сервис" бы в случае ошибки маршрутизации просто бы говорил, что proxy ошиблась и ей нужно получить новую таблицу у Meta. Что же использует S3DB для хранения не так важно, это может быть Postgres/MySQL/RocksDB/etc.
Ну и да, если бы это делалось в Dropbox, то полный S3 API мы бы наверное не поддерживали, а в замен сделали бы свой S3-подобный API. Описали бы протобафы, а код для клиентов под все языки сгенерился бы автоматом (aka codegen).
Disclaimer: в своё время я работал над Elliptics: делал из
eblobLSM и писал первые версииdnet_recovery.На самом деле "многофазное" удаление это очень хорошая практика в любой системе хранения. Основной её плюс в том, что она позволяет легко "откатить" состояние базы данных на уровне приложения без танцев с
бинлогами/бекапами/снапшотами/логамибубном.Двухшаговое удаление ещё упрощает написание verifier'ов которые следят за нарушениями соглашений "модели данных", например о том что данные которые были "удалены" в одной базе всё ещё имеют живые ссылки в какой-либо другой базе. У нас так регулярно находятся проблемы в процедуре подчистки базы от старых ревизий файлов, не потому что она бажная, а потому что мир вокруг неё меняется.
ПС. Вау! У кого-то серьёзный батхёрт на тему высшего образования. Ну и уровней абстракций походу тоже.
A на ScyllaDB смотрели?
Спасибо, что проделали столь масштабную работу!
ПС. Забавно, что статья думалась на русском, писалась на английском, потом американский редаткор страдал, правя сложносочинённые конструкции, а теперь результат опять на "великом и могучем".
ППС. Вы пропустили последний абзац, но я так понимаю, это плата за перевод =)
Понимать смысл говорите умеет? А Тест Тьюринга^W^W Winograd Schema Challenge (WSC) оно уже проходит? =)
PS. ну или вот тут даже луше, чем на вики: http://commonsensereasoning.org/winograd.html
Не прошло и трёх лет, как ребята придумали как сделать адекватные
Proof-of-StorageиProof-of-Spacetime: https://filecoin.io/filecoin.pdfМы стали на один шаг ближе к миру, где майнеры ставят стороджа по всему миру, вместо того, чтобы жечь электричество впустую брутфорся sha256.
Ну, если совсем по чесноку, то не все =)
На больших нагрузках nginx может блокировать eventloop на:
access_log'ов — может сильно помочь директиваbuffer=. Однако в идеале лучше писать логи напрямую в syslog.aio threads. Однако, насколько я понимаю, он не работает для приёма файлов, только на отдачу.(Почему костыль? Потому что в идеале aio должно работать через нативный аснихронный интерфейс к файловой системе, а не эмулироваться через thread pool, но в *nix ОС с этим всё плохо).
gzip_staticиbrotli_static. Что делать если хочется по-максимуму сжимать динамку пока не понятно, но оно обычно того не стоит. (Можно, наверное, сжимать на backend'е(или маленьком sidecar-демоне), но это значит больше нельзя применять никакие body-filter'ы).Проблема лишь в том, что маленький
ssl_buffer_sizeдобавляет измеримый CPU-overhead. И если есть желание оптимизировать один и тот же конфиг для пропускной способности и низкой задержки, то необходимо вручную выставлять нужный размер буферов для каждого server/location блока в зависимости от гистограммы размеров ответов./sys/class/net/eth*/device/numa_node) и свой набор IP'шников. Далее на вышестоящем балансере (я так пологаю IPVS) считать каждую NUMA-ноду за отдельный хост/proc/sys/vm/zone_reclaim_mode— важно, чтобы оно было выставленно в нольethtool -k(tso, lro,[rt]xcsum, etc) и почти всегда надо задирать ring buffer'а вethtool -glspci -t -vvv(особо важно для 40G+)cc_netflix) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)# perf probe -x /bin/bash 'readline%return +0($retval):string' Added new event: probe_bash:readline (on readline%return in /bin/bash with +0($retval):string) You can now use it in all perf tools, such as: perf record -e probe_bash:readline -aR sleep 1 # perf record -e probe_bash:readline -a ^C[ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.259 MB perf.data (2 samples) ] # perf script bash 26239 [003] 283194.152199: probe_bash:readline: (48db60 <- 41e876) arg1="ls -l" bash 26239 [003] 283195.016155: probe_bash:readline: (48db60 <- 41e876) arg1="date" # perf probe --del probe_bash:readline Removed event: probe_bash:readlineФактически, всё вышеописанное, это ровно то как сейчас работают трекеры, где в качестве валюты используется «ratio» (которое отражает сколько раздач и как долго ты хранишь). Всё централизовано и в качестве регулятора валюты выстурает трекер. Разве, что в торренте нет способа пропросить кого-либо хранить и раздавать твои данные в обмен на свой ratio.
Отдельный вопрос как анонимизировать всё это. В bitcoin вся история транзакций публична, что может сильно усложнить дальнейшую «анонимизацию» пользователей такой bitcoin-style p2p системы.
В общем, дискуссия про то как скрестить p2p и bitcoin вполне потянет докторскую. Тема интересная, да.
Share & WinNY: японские p2p
Что самое интересное все три сети Winny, Share и Perfect Dark родом из японии, где шарить в сети аниме весьма распространённое и довольно опасное занятие.
Ещё в последнее время сильно набрал популярность Freenet.
Данные сети частично используют идеи из этого поста, частично из I2P/tor, частично из bittorrent. Но в любом случае все они сильно отличаются от того, что мы на данный момент имеем в мире торрент-трекеров. Думаю преминив некоторое кол-во усилий можно написать «прокси» из bittorrent в анонимные сети (например, freenet) и сделать его плагином к торрент-клиентам, чтобы то, что было скчано/роздано через bittorrent автоматом клалось и туда. Посути такой dual-stack получится (прям как во время перехода с IPv4 на IPv6). Я делал что-то подобное когда использовал Direct Connect и Bittorrent: то что у меня скачивалось rtorrent'ом автоматически шарилось в DC++.