nnn Xion, чел. Масштабирование - это не вынос логики в Redis.
Если ты хочешь реального масштабирования то ты должен писать задачу так чтоб она работала
в кластере на одно-ранговых узлах (нодах) и ее внешняя бизнес логика выглядела бы так будто
это работает 1 физический хост. И если ты правильно все сделал - то чтоб ускорять (масштабировать)
такое приложение тебе ничего не надо больше. Только добавляй новые ноды в кластер.
А Редис - вообще не про это. Редис решает другие задачи хотя он может что-то ускорять.
А каким образом мы проверим вообще из какого города? По IP адресу? По пользовательскому профилю?
Вы говорите о кукисах, но это просто один из способов ведения сессионных переменных на стороне
клиента. И когда проектируется надежная система то в первую очередь нужно проверять кукисы и не
доверять. Иначе чел с ноутбуком будет ездить везде и толкать данные все равно в одну и ту-же базу.
Вот эту механику с городами нужно прояснить на уровне ТЗ или User Story.
Vincent1, на segmentation fault у меня нет ответа. Нужно смотреть глазами этот дамп. Но вряд-ли
кто-то в хабре согласится забезплатно тебе такую услугу оказать.
Попробуй скачать исходники скальпеля и пересобрать его под свой ubuntu22.
Вы зря спорите. Потому что торрент-клиенты используют 4 или 5 разных протоколов одновременно.
Есть централизованные которые требуют наличия трекера. И есть те, которые основаны на
разспределенном хранении информации (DHT, PEX ...e.t.c). И сами Торрент клиенты могут
расширять и дополнять свои протоколы (Vuze). Нет единого стандарта и контроля за разработкой
подобных клиентов. Нет консорциума которые что-то регулирует.
Под динамическием соединением - непонятно что автор имеет в виду. Во первых открытие порта
нужно только для инициации соединения извне. Если твой клиент инициирует - то это почти всегда
разрешено. Вот так и происходит соединение.
Для комфортной работы всех протоколов в клиенте есть self-test который проверяет доступность портов
снаружи. Пускай автор проверит что у него открыто.- Это наверное и будет ответ а вопрос.
Пропускная способность - это вообще прикладной уровень и рассматривать его здесь не интересно.
Как написано приложение - так и регулирует.
В криптовалютах нет арбитра. И любые ошибочные операции обычно безвозвратны. И не к кому
пойти чтоб отменить транзакцию.
Крипта также сильно подвержена спекуляциям, и очень сложно договариваться об оплате по курсу.
Твой кошелек прозрачен для постороннего наблюдателя. С одной стороны это крипто. С другой стороны
- стена на которой все пишут и читают что хотят. Возможно есть боты которые коллектят бигдату
по кошелькам и ты и твой баланс будет объектом наблюдения посторонних людей с неизвестными
целями и явно не очень хорошими по отношению к тебе.
Иерокопус Таманский, предложите ваш вариант. Я писал что это - восстановление с вероятностью. Для фоток - хорошо пойдет. Для видео - можно получить битые файлы.
Беря во внимание что был сделан дамп - можно экспериментировать бесконечно, проверяя разные
опции восстановления. И только владелец может сказать достаточно ли восстановлено или нет.
pfg21, когда делают бекапы. Есть разные хитрости и стратегии. Например делают перидические копии.
Еженедельно например. В случае стримера у тебя есть пул касет. Ты их меняешь по кругу. И если одна кассета повреждается то у тебя есть двухнедельная копия.
Техники инкрементального копирования позволят тебе копировать не все а только то что изменилось.
Для повышения надежности копий я добавляю дополнительны коды восстановления. Есть утилиты типа par2.
Мне кажется что проблема применения нейросетей в бизнесе и хозяйстве очень похожа на поиск
готовых Delphi-компонентов в 90х которые коробочно решали какую-то узкую задачу.
Беря во внимание что постановок можно придумать - миллиионы, особенно с машинным зрением,
то и также будут нужны миллиоды инженеров по ML чтоб закрывать эти потребности.
Dahock, я не помню чтоб я читал какую-то книгу про это. Поищи по ключевым словам vector database,
text search, word2vec, tf-idf, HNSW .
Из программных продуктов. Postgres, Redis, Apache Spark, Apache Lucene, Sphinx . Они могут поддерживать
какие-то алгоритмы или принципы поиска документов по подобию.
#, это все домыслы. Никто не знает кто и с кем сотрудничает. А если-бы знал - то в хабре не писал-бы.
Мне уже интересно чем таким секретным автор занят.
rootnoroot, я не знаю. Я не специалист в телеграм API. По идее телеграм предоставляет только id пользователя.
Но если представить что у тебя есть друг. Который тебя добавил к себе в ТГ. Переименовал тебя чтоб было ФИО.
Добавил телефон. И потом спалился на вирусах которые собирают информацию. И тогда, косвенным образом
друг передал сведенья о тебе.
Cуществуют телеграм-каналы которые соединяют различные базы пользователей (Vk, Telegram, Телефоны,
Автономера, Налоговая, Предпренимательство, Суды, Прописки) в единую базу и таким обазом позволяют
что-то находить. Обычно они отстают от реального положения дел и если пользователь
только вчера зарегистрировался, то скорее всего его пробить нельзя.
Есть такой блуждающий и постоянно закрываемый канал Глаз Бога (GodEye) и его ссылка
меняется но последний раз когдая туда заходил услуги были уже платные. Он делает примерно такое
как я описал выше.
В 2018 году я просто в интернете находил сведения самого себя по прописке но они оказались старее на
10 лет. Вот делайте выводы о качестве выдачи такого пробива.
Мне кажется что самые свежие базы могут быть у ментов и особистов. У них н надо спрашивать.
Если ты хочешь реального масштабирования то ты должен писать задачу так чтоб она работала
в кластере на одно-ранговых узлах (нодах) и ее внешняя бизнес логика выглядела бы так будто
это работает 1 физический хост. И если ты правильно все сделал - то чтоб ускорять (масштабировать)
такое приложение тебе ничего не надо больше. Только добавляй новые ноды в кластер.
А Редис - вообще не про это. Редис решает другие задачи хотя он может что-то ускорять.