Вопрос «в лоб»: а как при таком подходе контролировать ratelimit в условиях, когда сервис api одновременно запущен в 2..n экземплярах? Отказ от масштабируемости?)
Слушайте, но я солидарен с этим комментарием и не очень понимаю минусы за него. Что за статья? Какой профит из неё можно получить? Какую пользу? И, самое важное, какие технические знания она несёт тут, на хабре? Минусуйте меня тоже)
Шикарный комментарий! Предлагаю привлечь к ответственности компании Sony, lg и всех остальных производителей техники для воспроизведения dvd, например. Ведь они не просто перенаправляет на ресурс, а имеют возможность (возмущённо!) воспроизводить пиратский контент!
проблема высосанная из пальца. с одной стороны статья явно из разряда «Я пиарюсь», даже про utm-разметку в ссылках не позабыли ;) с другой стороны соглашусь с предыдущими комментариями — забота о покупателях — это не заставлять их бегать к информ.киоску (в не зависимости от их наличия), а дать достаточно информацию сразу на ценнике, в т.ч. и цену за кг весового товара. в общем, мое мнение статья не Хабра достойна.
очень странная задача… не могу себе вообще представить ситуацию, когда вообще может потребоваться в таблице на 500М строк удалять больше половины… это явно продакшн, 500М строк — видимо, активно работающий продакшн, удаление большей части таблицы явно связано с изменением логики… ну а если меняется логика, то под новую логику иногда лучше новую архитектуру использовать… на мой взгляд правильное решение в подобной ситуации, это подготовка новой таблицы, вставка в нее тех строк, которые в примере недо было не удалить, а оставить, в этом случае вставлять можно не сразу, а партиями… ну а потом замена одной таблицы на другую… а вообще очень странная задача
ну а за что вы ее заминусовали-то?)) предполагаю, что «заплюсить, пока, не могу» — это недостаток прав у нее на хабре, а не отсутствие желания) вот так… люди недопоняли, а человек минусов ни за что нахватал) плюсаните хоть, кто вчитался в коммент ;)
дополню свою мысль маленьким отступлением. моя парадигма проста: категорически нельзя хранить на клиенте те данные, которые могут повлиять на то, что, чем не предназначено управлять клиенту. и тем более на эти данные ориентироваться серверу. это я понял еще со времен лицея, где мне повезло и в лицее (как части ВУЗа) была сеть на Novell Netware, было одно приложение (еще под DOS), которое использовалось для публикации свои работ по информатике (маленький невзрачный прототип GitHub'а). я тогда любил и изучал ассемблер и это приложение мне было интересно. выяснилось, что флаг доступа «IsRoot» устанавливался внутри приложения и сервер после подключения ему «верил», нетрудно догадаться, чего можно добиться, если, например, в приложении «Сбербанк онлайн» будет подобное))
достаточно интересная ситуация, молодцы все: и те, кто умудрился внедрить такой обман (молодцы — в хорошем смысле, т.к. такое еще надо было придумать и более того, смочь реализовать) и тем более вы, т.к. смогли это расследовать, т.к. это явно было очень не просто…
ну а если конструктивно: проблема в том, что заинтересованным лицам доступен контроль над данными, влияющими на ход тестирования, а именно идентификатор сегмента, это и есть узкое место и в корне не правильно.
моя мысль следующая: если мы допускаем, что сегментатор — это неподвластная истина, то назначать сегменты может только он, решается это следующим образом: у пользователя при первом заходе (если в куках еще нет) генерируется guid, обычный такой случайный гуид, далее, например, суммируется со счетчиком из GA и отправляется на сервер. если по этой паре не назначен сегмент — сервер его назначает и хранит у себя, никому не говоря, а по этому сегменту уже сам направляет на обработку в необходимый экзепляр…
в случае умышленной подмены guid-а мы просто получаем нового пользователя со снова рандомным сегментом, подтасовать в этом случае (опять-таки я учитываю «честный» сегментатор) невозможно.
ну а если конструктивно: проблема в том, что заинтересованным лицам доступен контроль над данными, влияющими на ход тестирования, а именно идентификатор сегмента, это и есть узкое место и в корне не правильно.
моя мысль следующая: если мы допускаем, что сегментатор — это неподвластная истина, то назначать сегменты может только он, решается это следующим образом: у пользователя при первом заходе (если в куках еще нет) генерируется guid, обычный такой случайный гуид, далее, например, суммируется со счетчиком из GA и отправляется на сервер. если по этой паре не назначен сегмент — сервер его назначает и хранит у себя, никому не говоря, а по этому сегменту уже сам направляет на обработку в необходимый экзепляр…
в случае умышленной подмены guid-а мы просто получаем нового пользователя со снова рандомным сегментом, подтасовать в этом случае (опять-таки я учитываю «честный» сегментатор) невозможно.