АВ
привет, есть тут кто из немеции? у нас появилась работа https://www.heyjobs.co/de-de/jobs/7fd9cdce-64f1-4d1b-ba27-d402689849b7?utm_campaign=google_jobs_apply&utm_source=google_jobs_apply&utm_medium=organic, ремот думаю возможен
Size: a a a
2021 March 03
IK
Андрей Вилинский
привет, есть тут кто из немеции? у нас появилась работа https://www.heyjobs.co/de-de/jobs/7fd9cdce-64f1-4d1b-ba27-d402689849b7?utm_campaign=google_jobs_apply&utm_source=google_jobs_apply&utm_medium=organic, ремот думаю возможен
В Берлине все растовики заняты)
АВ
мы растем! я не хр если что, у нас вообще .net шоп, просто офигел что набирают на раст 😍, смысл есть, сенсоры фигенсоры
ну и просто хотелось бы побольше русскоязычных коллег
ну и просто хотелось бы побольше русскоязычных коллег
DS
Андрей Вилинский
мы растем! я не хр если что, у нас вообще .net шоп, просто офигел что набирают на раст 😍, смысл есть, сенсоры фигенсоры
ну и просто хотелось бы побольше русскоязычных коллег
ну и просто хотелось бы побольше русскоязычных коллег
Почему именно для сенсоров Rust актуален?
K
звучит так, будто для всего остального не актуален
язык общего назначения может быть уместен в разных сферах
язык общего назначения может быть уместен в разных сферах
АВ
да я ж только за!
я сам не сварщик, но у нас есть фирмвари, на сях, думаю тут раст была б отличная замена
а еще есть две дюжины .net core говносервисов с проблемами по перфу, должны все разом работать на небольших компуктерах, честно говоря тут тоже бы был раст самое то
еще есть проектик на вебассембли - тоже самое ж!
извиняюсь за непрофильную дискуссию
я сам не сварщик, но у нас есть фирмвари, на сях, думаю тут раст была б отличная замена
а еще есть две дюжины .net core говносервисов с проблемами по перфу, должны все разом работать на небольших компуктерах, честно говоря тут тоже бы был раст самое то
еще есть проектик на вебассембли - тоже самое ж!
извиняюсь за непрофильную дискуссию
AP
Ожидают, что ты расскажешь, что будешь делать, когда упрёшься в производительность базы. Это хайлоад, детка.
Можно сделать реплики БД и кэш в памяти сервиса для GET запросов. Очень большого потока запросов на запись скорее всего не будет, поэтому пока можно не заморачиваться. Я сеньор?
IB
Можно сделать реплики БД и кэш в памяти сервиса для GET запросов. Очень большого потока запросов на запись скорее всего не будет, поэтому пока можно не заморачиваться. Я сеньор?
Что будет, когда база перестаёт вмещаться на один диск? Что будет, когда кто-то захочет создать кучу ссылок, и поток на запись таки будет?
IB
Да, и это, реплики у вас в нескольких ДЦ, или всё в одном?
AP
Что будет, когда база перестаёт вмещаться на один диск? Что будет, когда кто-то захочет создать кучу ссылок, и поток на запись таки будет?
Можно шардировать, например, но я всё же сомневаюсь, что такое понадобиться.
Можно ещё ссылки, которые ни разу не запросили с момента создания за пару месяцев перекинуть в холодное хранилище и доставать оттуда асинхронно (используя какую-нибудь очередь вроде RabbitMQ), показывая какую-нибудь анимацию на JS на временной странице, пока подгружается.
Можно ещё ссылки, которые ни разу не запросили с момента создания за пару месяцев перекинуть в холодное хранилище и доставать оттуда асинхронно (используя какую-нибудь очередь вроде RabbitMQ), показывая какую-нибудь анимацию на JS на временной странице, пока подгружается.
IB
Можно шардировать, например, но я всё же сомневаюсь, что такое понадобиться.
Можно ещё ссылки, которые ни разу не запросили с момента создания за пару месяцев перекинуть в холодное хранилище и доставать оттуда асинхронно (используя какую-нибудь очередь вроде RabbitMQ), показывая какую-нибудь анимацию на JS на временной странице, пока подгружается.
Можно ещё ссылки, которые ни разу не запросили с момента создания за пару месяцев перекинуть в холодное хранилище и доставать оттуда асинхронно (используя какую-нибудь очередь вроде RabbitMQ), показывая какую-нибудь анимацию на JS на временной странице, пока подгружается.
Для FAANG -- обязательно понадобится. Но вряд ли устроит простой ответ "давайте шардировать, да и всё", потому что в шардировании редко бывают простые решения :)
AP
Кажется, данный сервис идеален для шардирования. Мы генерим случайные идентификаторы урлов, их можно как раз в качестве ключа использовать.
AP
То есть, не будет таких вещей как то, что все записи попали в один шард и т.п.
AV
а они случайные?
IB
Какой длины будут эти случайные идентификаторы?
AV
полагаю лучше их делать не случайными и зависимыми от первоначального URL'a
AV
грубо говоря - хеш от URL который сокращаем
IB
Я смотрю на первую попавшуюся ссылку на bit.ly, и там всего 7-8 алфавитно-цифровых символов. Можно, конечно, и такой хэш сделать, но, кажется, будет много коллизий.
AP
Для FAANG -- обязательно понадобится. Но вряд ли устроит простой ответ "давайте шардировать, да и всё", потому что в шардировании редко бывают простые решения :)
Вот у bit.ly порядка 240 запросов в секунду на сокращение. Postgres такое спокойно на одном шарде выдержит (и даже больше в 5-6 раз).
http://highscalability.com/blog/2014/7/14/bitly-lessons-learned-building-a-distributed-system-that-han.html
http://highscalability.com/blog/2014/7/14/bitly-lessons-learned-building-a-distributed-system-that-han.html
AV
если хэш-функция хорошая, то коллизий будет не сильно больше чем при рандоме