inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился.
read — получить текущее глобальное значение
сервис на сервере, который пишет и читает из постгреса.
Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
Ваши предложения.
Бюджет относительно небольшой, поэтому всякие супер-космические решения не годятся.
В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
LK>Redis + Golang?
Не гарантирует сохранение в базу.
В>>Бюджет относительно небольшой
LK>Миллион rps на виртуальном серваке за 5 баксов? Что за проект-то? Счётчик экземпляров короновируса?
Речь о том, что нельзя брать Redis Enterprise (например), который стоит миллионы денег.
LK>>>Redis + Golang? В>>Не гарантирует сохранение в базу.
LK>Почему?
А если он упадёт?
В>>Речь о том, что нельзя брать Redis Enterprise (например), который стоит миллионы денег.
LK>Энтерпрайз на 100 гиг и 100k rps стоит 4k в месяц. Бюджета в 100k вполне хватит.
Где про это можно почитать? Меня уверяли совсем в других цифрах...
Для этого есть кластерная репликация. Также можно сделать отказоустойчивость на уровне REST-сервера (Golang).
LK>>Энтерпрайз на 100 гиг и 100k rps стоит 4k в месяц. Бюджета в 100k вполне хватит. В>Где про это можно почитать?
Здравствуйте, L.K., Вы писали:
В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
LK>Redis + Golang?
Здравствуйте, Ватакуси, Вы писали:
В>REST-сервис
В>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>read — получить текущее глобальное значение
В>сервис на сервере, который пишет и читает из постгреса. В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
Что-то не очень точные входные данные.
1) Предположим у нас есть бесконечно мощный веб-сервер, который сам по себе вывезет 1М rps. Тогда не нужен даже постгрес, просто пишем данные в файл на диск при inc с эксклюзивной блокировкой на запись и отдаем файл с диска при запросе read. Быстрее точно никак не получится. Это может даже для 100к сработать если соотношение чтении и записи 100:1.
2) Но в реальности сервер не выдержит 1М rps, просто очередь переполнится. То есть надо будет несколько серверов и писать надо будет в postgres. И тут быстродействие упирается в сам postgres, потому что он сам будет задыхаться даже от 1К запросов на изменение данных. Но по условию надо получить ответ от базы. Тут поможет только сервер пожирнее, потому что мастшабировать запись в одну ячейку без потери целостности невозможно.
Здравствуйте, Ватакуси, Вы писали:
В>REST-сервис
В>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>read — получить текущее глобальное значение
Зачем n? В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик. В>Ваши предложения.
Ставишь Kafka/rabbit, складируешь запросы (гарантия что все будут обработаны), и раскидываешь их по обработчикам которые пишут в базу. Схема конечно тупая т.к. в базу будут ломиться все обработчики запросов и она будет узким местом, но если баз несколько, то можно наверное. Короче, я в этом не разбираюсь, написал как нафантазировал, возможно я бред несу .
В>Бюджет относительно небольшой, поэтому всякие супер-космические решения не годятся.
амазон SQS, динамические инстансы под нагрузку, вопрос только к том, выдержит ли твоя БД 1кк update-ов в секунду.
LK>>>Энтерпрайз на 100 гиг и 100k rps стоит 4k в месяц. Бюджета в 100k вполне хватит. В>>Где про это можно почитать?
LK>На официальном сайте, разумеется:
LK>https://redislabs.com/redis-enterprise-cloud/pricing/
Я может тупой, но где там про 100k rps написано?
В>>REST-сервис
В>>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>>read — получить текущее глобальное значение
В>>сервис на сервере, который пишет и читает из постгреса. В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
G>Что-то не очень точные входные данные.
G>1) Предположим у нас есть бесконечно мощный веб-сервер, который сам по себе вывезет 1М rps. Тогда не нужен даже постгрес, просто пишем данные в файл на диск при inc с эксклюзивной блокировкой на запись и отдаем файл с диска при запросе read. Быстрее точно никак не получится. Это может даже для 100к сработать если соотношение чтении и записи 100:1. G>2) Но в реальности сервер не выдержит 1М rps, просто очередь переполнится. То есть надо будет несколько серверов и писать надо будет в postgres. И тут быстродействие упирается в сам postgres, потому что он сам будет задыхаться даже от 1К запросов на изменение данных. Но по условию надо получить ответ от базы. Тут поможет только сервер пожирнее, потому что мастшабировать запись в одну ячейку без потери целостности невозможно.
Именно в этом и заключается подвох задачи. Увеличивать мощность сервера приложений или даже сервера ДБ нельзя до бесконечности (да и деньги кончатся).
Поскольку все запросы inc будут биться за одну глобальную переменную, то они сразу станут в очередь.
В>>REST-сервис
В>>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>>read — получить текущее глобальное значение K>Зачем n?
Хочешь на 1 увеличить или на 10, например.
В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик. В>>Ваши предложения. K>Ставишь Kafka/rabbit, складируешь запросы (гарантия что все будут обработаны), и раскидываешь их по обработчикам которые пишут в базу. Схема конечно тупая т.к. в базу будут ломиться все обработчики запросов и она будет узким местом, но если баз несколько, то можно наверное. Короче, я в этом не разбираюсь, написал как нафантазировал, возможно я бред несу .
Да, всё упрётся в базу.
Но кафка (типа) часть решения, да.
В>>Бюджет относительно небольшой, поэтому всякие супер-космические решения не годятся. K>амазон SQS, динамические инстансы под нагрузку, вопрос только к том, выдержит ли твоя БД 1кк update-ов в секунду.
Одной БД не сделать, это понятно.
Здравствуйте, Ватакуси, Вы писали:
В>>>REST-сервис
В>>>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>>>read — получить текущее глобальное значение
В>>>сервис на сервере, который пишет и читает из постгреса. В>>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
G>>Что-то не очень точные входные данные.
G>>1) Предположим у нас есть бесконечно мощный веб-сервер, который сам по себе вывезет 1М rps. Тогда не нужен даже постгрес, просто пишем данные в файл на диск при inc с эксклюзивной блокировкой на запись и отдаем файл с диска при запросе read. Быстрее точно никак не получится. Это может даже для 100к сработать если соотношение чтении и записи 100:1. G>>2) Но в реальности сервер не выдержит 1М rps, просто очередь переполнится. То есть надо будет несколько серверов и писать надо будет в postgres. И тут быстродействие упирается в сам postgres, потому что он сам будет задыхаться даже от 1К запросов на изменение данных. Но по условию надо получить ответ от базы. Тут поможет только сервер пожирнее, потому что мастшабировать запись в одну ячейку без потери целостности невозможно.
В>Именно в этом и заключается подвох задачи. Увеличивать мощность сервера приложений или даже сервера ДБ нельзя до бесконечности (да и деньги кончатся). В>Поскольку все запросы inc будут биться за одну глобальную переменную, то они сразу станут в очередь.
В>Но решение (типа) есть.
Объединять несколько inc n на дополнительных серверах, а на основной отправлять inc n1+n2+n3+...? Но это только на запись и не известно быстрей ли будет.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Ватакуси, Вы писали:
В>>REST-сервис
В>>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>>read — получить текущее глобальное значение
В>>сервис на сервере, который пишет и читает из постгреса. В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
G>Что-то не очень точные входные данные.
G>1) Предположим у нас есть бесконечно мощный веб-сервер, который сам по себе вывезет 1М rps. Тогда не нужен даже постгрес, просто пишем данные в файл на диск при inc с эксклюзивной блокировкой на запись и отдаем файл с диска при запросе read. Быстрее точно никак не получится. Это может даже для 100к сработать если соотношение чтении и записи 100:1. G>2) Но в реальности сервер не выдержит 1М rps, просто очередь переполнится.
ну можно взять какую-нибудь быструю ПЗУ, типа Intel Optane,
и писать туда напрямую, а TCP/IP и Ethernet обрабатывать почти полностью
в user-space или наоборот все в kernel space включаю логику инкремента и записи optane,
тогда я думаю 100k должно выдавать без проблем, даже на относительно слабом железе.
Здравствуйте, Ватакуси, Вы писали:
В>Именно в этом и заключается подвох задачи. Увеличивать мощность сервера приложений или даже сервера ДБ нельзя до бесконечности (да и деньги кончатся). В>Поскольку все запросы inc будут биться за одну глобальную переменную, то они сразу станут в очередь. В>Но решение (типа) есть.
Если мы предполагаем что количество запросов растет бесконечно, то есть заведомо больше чем любая жеезная конфигурация может выдержать, то нет решения без дополнительных условий.
Потому что CAP-теорему (будь она неладна) обмануть нельзя. Тут или согласованностью чтения надо жертвовать, или время ответа не жестко фиксировать.
Но в реальности нет такого, что количество запросов растет бесконечно. Более того, 90% проектов не преодолеют возможности одной машины.
Здравствуйте, Ватакуси, Вы писали:
В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
держать счётчик в памяти, какие ещё могут быть решения? Гарантировать сохранение в базу будет raid-массив и дизель-генератор. Вероятность выхода из строя raid-массива с дизель-генератором считать много меньшей вероятности банкротства компании.
Здравствуйте, Ватакуси, Вы писали:
В>Хочешь на 1 увеличить или на 10, например.
Мне не понятно зачем тебе счётчик такой нужен. В>Одной БД не сделать, это понятно.
можно амазоновускую заюзать, но $$$$ отвалишь .
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, Ватакуси, Вы писали:
В>>read — получить текущее глобальное значение
L>А что такое "текущее" значение? Если у тебя дофига запросов на запись, то оно будет устаревать практически сразу после чтения.
.
