А к столь экстремальной производительности прилагаются экстремальные зарплаты? Может х10 от рынка и выше, например. Потому что я не представляю, зачем отказываться от семьи, хобби, да и по здоровью долгосрочные риски надо закладывать.
А что мешает прокрутить немного вниз результаты поиска и посмотреть отели без агрегатора?
Неудобно, когда фильтровать приходится глазами каждую позицию. И это еще хорошо, если агрегатор общеизвестен (как букинг), потому что в противном случае придется проваливаться в каждую ссылку и только там узнавать, что это посредник. Все же хотелось бы инструмент, построенный на запросе. Не зря же все воюют за первые места в поисковой выдаче - тут каждый элемент дискомфорта снижает прошедшую дальше аудиторию.
Или просто открыть гуглокарту и поискать отели там?
Вот тут я не в курсе, но беглый поиск говорит, что и сюда букинг может транслировать объявления (при каких-то настройках интеграции да, при каких-то нет). Так что исключить его со стороны покупателя не факт, что получится.
Понимаю. И все же мне кажется неправильным, что мы отдаем весь трафик агрегатору. Который затем отжимает по условиям отели. А отели сами не могут получить свой трафик и вынуждены идти в более дорогую контекстную рекламу. Мы как будто специально вставили принудительное звено между покупателем и продавцом - не удивительно, что это звено теперь хочет откусить свою долю, а остальных выкинуть с рынка. Я вот задаюсь вопросом - могу ли я гугл спросить "покажи мне отели в г. таком-то без посредников"? Думаю, нет. Думаю, агрегатор на первых страницах теперь навсегда и кроме как специальными масками, исключающими сайты из поиска, его не убрать, даже несмотря на желание пользователя в запросе. А выбор был бы неплох: хочу я видеть посредников или нет.
Несомненно, любой классифайд добавляет более умный параметризованный поиск. Но стоит ли из-за этого понижать первоисточники и ставить их в поиске ниже? Если да, то мы быстро получаем моно/олигополии и потом мучительно их пытаемся регулировать.
Тут, кмк, поисковые системы ухудшают ситуацию. Им нравятся огромные сайты, вроде booking с долгим удержанием внимания пользователя. Хотя букинг по сути является "пересказывальщиком". Т.е. по-хорошему в естественном поиске должны идти сначала персональные сайты отелей (как самые авторитетные источники информации об их же услуге), а уже ниже агрегаторы вроде букинга. В противном случае мы даем неоправданный бонус неавторитетным источникам, позволяя им своим объемом захватывать рынок и становится монополистом. Это примерно как если бы в блогосфере появился пересказывальщик нескольких блогеров (не привнося ничего нового в контент) и он бы всегда был на первом месте, вытеснив как раз исходных блогеров. В такой модели выгоднее быть пересказывальщиком, чем источником.
дык просто "самый популярный с поддержкой групп/каналов и ботов". Учитывая, что Макс слизан с идеологии телеги - как только наберет достаточное количество пользователей - будем задаваться вопросом "Почему Макс?" Более того, в случае с Максом будет даже хуже - т.к. есть некий ореол поддержки государством вокруг него => люди более охотно будут доверяться мошенникам. Нет ничего хуже, чем ложное ощущение безопасности.
или же product_id:category_id и параллелить еще глубже
а вот это не выйдет. Т.к. категория - это более сводный классификатор над продуктом. Поэтому он не добавит никакого дополнительного разделения. Полезно лишь добавление таких сущностей, которые более детально делят остатки товаров.
Вот если мы отойдем от идеи склада как "кучи товара" и перейдем к "ячеистому складу", то каждую ячейку можно адресовать независимо - и это тоже отличный разделитель для параллельной обработки. Но в этом случае надо как-то еще обрабатывать ситуацию, когда в каждой ячейке осталось по 1шт товара и надо бы их переложить в одну.
Можно. Но когда возникнет необходимость транзакции между одной из 2х сущностей тут и одной из 98 сущностей во втором редисе - добро пожаловать обратно в микросервисы, распределенную транзакцию и ее сложный откат. Даже ограничение блокировки по сущностям все равно это много, это как блокировка всей таблицы в классической СУБД. Ниже вон правильно предлагают - блокировать конкретные товары. Потому что они являются разделителями, мало кому нужен резерв на другой товар вместо этого (оговорюсь, товары-заменители сознательно я в сторону откладываю). Да, в этих системах возможны взаимные блокировки, но это хорошо снижается эвристикой заранее: заказы с непересекающимися товарами мы можем резервировать параллельно, заказы с пересекающимися лучше организовать в очередь. Первая часть системы отлично масштабируется горизонтально (неперсекающиеся товары), вторая часть - будет аналогична табличной блокировке.
Добавлю, что кроме эвристик "не каждый с каждым" и огромного времени, что уже обсуждали в ветках, есть еще
Генетические алгоритмы и градиентный спуск - они были созданы как упрощенная модель, срисованная с природы. И они очень сильно сокращают число возможных комбинаций. Поэтому оценивать число комбинаций в лоб не очень полезно. P.S. Да, у этого метода есть недостатки (как прилипание к локальным экстремумам). Сложно сказать, недостатки ли это нашей упрощенной модели или всего подхода в целом и будут ли они также проявляться в природе.
Они исполняются атомарно, то есть никто не сможет обратиться к Redis в процессе выполнения скрипта — сервер заблокирован до конца выполнения: либо вся операция выполнена, либо ничего не произошло
Сомнительная архитектура блокировки в редисе. Если мы в него сложили 100 разных типов сущностей, а для "транзакции" нам нужны только 2, то блокируем мы все равно 100, т.е. в 50 раз больше нужного. Т.е. делаем один глобальный мьютекс с неоправданно большим охватом.
Да и беспилотники не являются причиной, чего их откладывать. Там скорее обратная связь: т.е. ухудшение навигации приводит к тому, что они больше попадают в гражданские объекты. Тот самый случай, когда сразу приносится в жертву и комфорт, и безопасность граждан - а вовсе не противопоставляются друг другу.
Это решение для маленьких баз. Я как-то 60гиговую выгружал между 2 и 3 часами. Для теста даже загрузил ее обратно: ~8 часов. Двоичные бекапы - меньше, чем за 30 минут справляются.
большая часть задач, которые "срочные", не такие уж и срочные, да и не особо нужные в данный момент
Вот это прям в точку. Более того, из моего опыта: если задача не представляет из себя фикс бага, то чем "срочнее" задача, тем меньше стоит ожидать от нее продуманности. Ну не успевают люди сфокусироваться на ней и продумать, "срочная" задача это часто эскиз какой-то идеи, а вовсе не что-то готовое к выполнению. И это для меня (со стороны исполнителя) обычно означает, что требования к задаче будут докидываться в процессе ее исполнения, иногда меняя ее чуть ли не на противоположную.
Отсюда, имхо, и рождается
больше половины того, что мы делали, в реальности было бессмысленной работой
Это еще и ухудшает само планирование. В сущности "срочность" это часто попытка обойти нормальные процессы планирования, анализа и проектирования. Это вот очередь "я только спросить" к доктору, которые, забежав, там на полноценный прием остаются, да еще и пришедшие без всех анализов (а их на лету надо сделать).
"pg_basebackup is used to take a base backup of a running PostgreSQL database cluster. The backup is taken without affecting other clients of the database, and can be used both for point-in-time recovery (see Section 25.3) and as the starting point for a log-shipping or streaming-replication standby server"
Вот "...of a running PostgreSQL database cluster" и отсутствие опций в нем по выбору конкретной базы.
Так и сделается бэкап всего инстанса со всеми базами, тут, если я правильно помню, проблем нет. Если Вам нужно восстановить из него только 1 базу, то это, опять же, насколько я помню, несколько обходным путём сделано, восстанавливаются все базы, просто не нужные восстанавливаются пустыми.
Хорошо, вот кейс: на сервере 5 рабочих разных баз, только одну конкретную из них надо откатить из бекапа "на вчера". Как это сделать в вашей схеме, желательно недолго?
А зачем? Обычно в идеологии постгреса стоит делать 1 БД = 1 инстанс. Иначе вы потеряете возможность двоичных бекапов (они делаются целиком на инстанс). Вы пытаетесь таки несколько БД развернуть в одном инстансе и каждой своего пользователя сделать?
Речь идет о Законе Cloud Act, который дает американскому правительству право требовать цифровые данные от американских технологических компаний, вне зависимости от того, где эти данные физически находятся.
А это большая проблема?. Критическая часть данных еврозоны выносится к европейскому регулятору и он уже выдает данные персонально по каждому запросу MS (проверяя относительно небольшие объемы. обычно то в нормальной работе просят небольшие участки оперативных данных, а при розыске нужны большие участки за большие периоды). MS больше ничего особого выдать не может и будет полностью сотрудничать с органами, не подставляя европейских клиентов.
У меня вопрос другой: почему v/mc/ppl должны решать за 3 другие рандомные платежные системы, что и они не должны продавать через себя nsfw игры? А именно так получается из-за настроек "на аккаунт" и из-за глобального скрытия из поиска. Потому что у этих ПС слишком большой процент рынка? Но именно такими случаями и занимаются антимонопольные ведомства. Это залезание своими "правилами" в бизнес партнера, а через него еще и в бизнесы партнеров партнера - выглядит как-то чересчур.
А к столь экстремальной производительности прилагаются экстремальные зарплаты? Может х10 от рынка и выше, например. Потому что я не представляю, зачем отказываться от семьи, хобби, да и по здоровью долгосрочные риски надо закладывать.
Неудобно, когда фильтровать приходится глазами каждую позицию. И это еще хорошо, если агрегатор общеизвестен (как букинг), потому что в противном случае придется проваливаться в каждую ссылку и только там узнавать, что это посредник.
Все же хотелось бы инструмент, построенный на запросе. Не зря же все воюют за первые места в поисковой выдаче - тут каждый элемент дискомфорта снижает прошедшую дальше аудиторию.
Вот тут я не в курсе, но беглый поиск говорит, что и сюда букинг может транслировать объявления (при каких-то настройках интеграции да, при каких-то нет). Так что исключить его со стороны покупателя не факт, что получится.
Понимаю. И все же мне кажется неправильным, что мы отдаем весь трафик агрегатору. Который затем отжимает по условиям отели. А отели сами не могут получить свой трафик и вынуждены идти в более дорогую контекстную рекламу. Мы как будто специально вставили принудительное звено между покупателем и продавцом - не удивительно, что это звено теперь хочет откусить свою долю, а остальных выкинуть с рынка.
Я вот задаюсь вопросом - могу ли я гугл спросить "покажи мне отели в г. таком-то без посредников"? Думаю, нет. Думаю, агрегатор на первых страницах теперь навсегда и кроме как специальными масками, исключающими сайты из поиска, его не убрать, даже несмотря на желание пользователя в запросе. А выбор был бы неплох: хочу я видеть посредников или нет.
Несомненно, любой классифайд добавляет более умный параметризованный поиск. Но стоит ли из-за этого понижать первоисточники и ставить их в поиске ниже? Если да, то мы быстро получаем моно/олигополии и потом мучительно их пытаемся регулировать.
Тут, кмк, поисковые системы ухудшают ситуацию. Им нравятся огромные сайты, вроде booking с долгим удержанием внимания пользователя. Хотя букинг по сути является "пересказывальщиком". Т.е. по-хорошему в естественном поиске должны идти сначала персональные сайты отелей (как самые авторитетные источники информации об их же услуге), а уже ниже агрегаторы вроде букинга.
В противном случае мы даем неоправданный бонус неавторитетным источникам, позволяя им своим объемом захватывать рынок и становится монополистом. Это примерно как если бы в блогосфере появился пересказывальщик нескольких блогеров (не привнося ничего нового в контент) и он бы всегда был на первом месте, вытеснив как раз исходных блогеров. В такой модели выгоднее быть пересказывальщиком, чем источником.
дык просто "самый популярный с поддержкой групп/каналов и ботов". Учитывая, что Макс слизан с идеологии телеги - как только наберет достаточное количество пользователей - будем задаваться вопросом "Почему Макс?"
Более того, в случае с Максом будет даже хуже - т.к. есть некий ореол поддержки государством вокруг него => люди более охотно будут доверяться мошенникам. Нет ничего хуже, чем ложное ощущение безопасности.
а вот это не выйдет. Т.к. категория - это более сводный классификатор над продуктом. Поэтому он не добавит никакого дополнительного разделения. Полезно лишь добавление таких сущностей, которые более детально делят остатки товаров.
Вот если мы отойдем от идеи склада как "кучи товара" и перейдем к "ячеистому складу", то каждую ячейку можно адресовать независимо - и это тоже отличный разделитель для параллельной обработки. Но в этом случае надо как-то еще обрабатывать ситуацию, когда в каждой ячейке осталось по 1шт товара и надо бы их переложить в одну.
Интересное такое "доверие" нынче, звучит как угроза расправы. И термины он выбрал соответствующие - с уклоном в преступления - "допрос".
Думаю, внимание пришло "по анонимному доносу". Но это мало меняет ситуацию.
Можно. Но когда возникнет необходимость транзакции между одной из 2х сущностей тут и одной из 98 сущностей во втором редисе - добро пожаловать обратно в микросервисы, распределенную транзакцию и ее сложный откат.
Даже ограничение блокировки по сущностям все равно это много, это как блокировка всей таблицы в классической СУБД. Ниже вон правильно предлагают - блокировать конкретные товары. Потому что они являются разделителями, мало кому нужен резерв на другой товар вместо этого (оговорюсь, товары-заменители сознательно я в сторону откладываю).
Да, в этих системах возможны взаимные блокировки, но это хорошо снижается эвристикой заранее: заказы с непересекающимися товарами мы можем резервировать параллельно, заказы с пересекающимися лучше организовать в очередь.
Первая часть системы отлично масштабируется горизонтально (неперсекающиеся товары), вторая часть - будет аналогична табличной блокировке.
Добавлю, что кроме эвристик "не каждый с каждым" и огромного времени, что уже обсуждали в ветках, есть еще
Генетические алгоритмы и градиентный спуск - они были созданы как упрощенная модель, срисованная с природы. И они очень сильно сокращают число возможных комбинаций. Поэтому оценивать число комбинаций в лоб не очень полезно.
P.S. Да, у этого метода есть недостатки (как прилипание к локальным экстремумам). Сложно сказать, недостатки ли это нашей упрощенной модели или всего подхода в целом и будут ли они также проявляться в природе.
Сомнительная архитектура блокировки в редисе. Если мы в него сложили 100 разных типов сущностей, а для "транзакции" нам нужны только 2, то блокируем мы все равно 100, т.е. в 50 раз больше нужного. Т.е. делаем один глобальный мьютекс с неоправданно большим охватом.
Да и беспилотники не являются причиной, чего их откладывать. Там скорее обратная связь: т.е. ухудшение навигации приводит к тому, что они больше попадают в гражданские объекты. Тот самый случай, когда сразу приносится в жертву и комфорт, и безопасность граждан - а вовсе не противопоставляются друг другу.
Это решение для маленьких баз. Я как-то 60гиговую выгружал между 2 и 3 часами. Для теста даже загрузил ее обратно: ~8 часов. Двоичные бекапы - меньше, чем за 30 минут справляются.
А с 1 бд = 1 инстанс работает любой из инструментов и можно восстанавливаться без промежуточного места.
В письме есть слово "прошу", а формат письма - требование с угрозами расправы. Как-то они не соответствуют друг другу.
Вот это прям в точку. Более того, из моего опыта: если задача не представляет из себя фикс бага, то чем "срочнее" задача, тем меньше стоит ожидать от нее продуманности. Ну не успевают люди сфокусироваться на ней и продумать, "срочная" задача это часто эскиз какой-то идеи, а вовсе не что-то готовое к выполнению. И это для меня (со стороны исполнителя) обычно означает, что требования к задаче будут докидываться в процессе ее исполнения, иногда меняя ее чуть ли не на противоположную.
Отсюда, имхо, и рождается
Это еще и ухудшает само планирование. В сущности "срочность" это часто попытка обойти нормальные процессы планирования, анализа и проектирования. Это вот очередь "я только спросить" к доктору, которые, забежав, там на полноценный прием остаются, да еще и пришедшие без всех анализов (а их на лету надо сделать).
https://www.postgresql.org/docs/current/app-pgbasebackup.html
"pg_basebackup is used to take a base backup of a running PostgreSQL database cluster. The backup is taken without affecting other clients of the database, and can be used both for point-in-time recovery (see Section 25.3) and as the starting point for a log-shipping or streaming-replication standby server"
Вот "...of a running PostgreSQL database cluster" и отсутствие опций в нем по выбору конкретной базы.
Хорошо, вот кейс: на сервере 5 рабочих разных баз, только одну конкретную из них надо откатить из бекапа "на вчера". Как это сделать в вашей схеме, желательно недолго?
А зачем? Обычно в идеологии постгреса стоит делать 1 БД = 1 инстанс. Иначе вы потеряете возможность двоичных бекапов (они делаются целиком на инстанс). Вы пытаетесь таки несколько БД развернуть в одном инстансе и каждой своего пользователя сделать?
А это большая проблема?. Критическая часть данных еврозоны выносится к европейскому регулятору и он уже выдает данные персонально по каждому запросу MS (проверяя относительно небольшие объемы. обычно то в нормальной работе просят небольшие участки оперативных данных, а при розыске нужны большие участки за большие периоды). MS больше ничего особого выдать не может и будет полностью сотрудничать с органами, не подставляя европейских клиентов.
У меня вопрос другой: почему v/mc/ppl должны решать за 3 другие рандомные платежные системы, что и они не должны продавать через себя nsfw игры? А именно так получается из-за настроек "на аккаунт" и из-за глобального скрытия из поиска.
Потому что у этих ПС слишком большой процент рынка? Но именно такими случаями и занимаются антимонопольные ведомства. Это залезание своими "правилами" в бизнес партнера, а через него еще и в бизнесы партнеров партнера - выглядит как-то чересчур.