• Отследить пополнение Bitcoin кошелька?

    @serious911 Автор вопроса
    Мне нужно посчитать сумму входящей транзакции на адрес (пополнение кошелька) и зачислить на баланс.

    Насколько я понимаю для этого нужно пройтись по всем транзакциям в блоке, посмотреть их vout и если там есть нужный адрес кошелька то зачислить сумму на баланс.

    Допустим есть транзакция - https://blockchair.com/bitcoin/transaction/dc0b5e8...

    В ней 2 vout: 1) кошелек 1FULLnode6c21o3DEYyLR9xdSiWksnTRjc пополнено на 0.004 BTC; 2) на кошелек bc1q9cnuqrewgzv5z8rtgqw54kfs7w4wq0yd6thdht идет возврат 0.01599856 BTC.

    Как отличить что идет возврат, а не пополнение счета? Потому что, возврат зачислит как пополнение счета, а это отправка монет, а не пополнение.
  • Отследить пополнение Bitcoin кошелька?

    @serious911 Автор вопроса
    Вопрос в том как именно посчитать сумму входящей транзакции. Там есть поля vin, vout. В vin только хеш транзакции, в vout есть сумма и адреса кошельков.

    Если транзакция простая, то все норм - https://blockchair.com/bitcoin/transaction/dc0b5e8...

    Но есть транзакции в которых по 20 выходов - https://blockchair.com/bitcoin/transaction/59d8682...

    Еще не понятно что будет если в один блок попадут 2 транзакции на 1 кошелек. Например, 1) пополнение кошелька Х; 2) отправка монет с этого кошелька и возврат (change). А еще есть Multisig в блокэксплорере.
  • MySQL Deadlock found?

    @serious911 Автор вопроса
    EXPLAIN SELECT * FROM `common_likes` WHERE user_id = '1' AND sender_id != '1' AND status = '2';
    +------+-------------+--------------+------+-----------------------------+---------+---------+-------+------+-------------+
    | id   | select_type | table        | type | possible_keys               | key     | key_len | ref   | rows | Extra       |
    +------+-------------+--------------+------+-----------------------------+---------+---------+-------+------+-------------+
    |    1 | SIMPLE      | common_likes | ref  | PRIMARY,common_likes_status | PRIMARY | 8       | const |    1 | Using where |
    +------+-------------+--------------+------+-----------------------------+---------+---------+-------+------+-------------+
    
    EXPLAIN SELECT * FROM common_likes WHERE peer_id = '71663'; 
    +------+-------------+--------------+------+---------------+------+---------+------+------+-------------+
    | id   | select_type | table        | type | possible_keys | key  | key_len | ref  | rows | Extra       |
    +------+-------------+--------------+------+---------------+------+---------+------+------+-------------+
    |    1 | SIMPLE      | common_likes | ALL  | NULL          | NULL | NULL    | NULL | 7004 | Using where |
    +------+-------------+--------------+------+---------------+------+---------+------+------+-------------+


    In the first case PRIMARY,common_likes_status indexes are used. And in the second case no indexes are used.

    So looks like I need to create a separate index for peer_id and sender_id fields.
  • MySQL Deadlock found?

    @serious911 Автор вопроса
    Slava Rozhnev, есть уникальный индекс на 3 поля:
    ADD UNIQUE KEY `@table_user_peer_sender` (`user_id`, `peer_id`, `sender_id`)

    Сейчас заменил UNIQUE на Primary по 3 полям PRIMARY KEY (user_id, peer_id, sender_id).

    Нужно добавить еще отдельный индекс для peer_id и sender_id?
  • MySQL Deadlock found?

    @serious911 Автор вопроса
    Slava Rozhnev, смотрел эту информацию и там этот же запрос:
    ------------------------
    LATEST DETECTED DEADLOCK
    ------------------------
    2022-05-16 04:41:00 0x7f05cc3f7700
    *** (1) TRANSACTION:
    TRANSACTION 130522343, ACTIVE 0 sec starting index read
    mysql tables in use 3, locked 3
    LOCK WAIT 5 lock struct(s), heap size 1128, 4 row lock(s)
    MySQL thread id 96932, OS thread handle 139662906558208, query id 77554557 127.0.0.1 Updating
    <b>UPDATE common_likes SET `seen` = '1' WHERE user_id = '79773' AND status = '2' AND sender_id != '79773'</b>
    *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
    RECORD LOCKS space id 60 page no 10 n bits 336 index PRIMARY of table `common_likes` trx id 130522343 lock_mode X locks rec but not gap waiting
    Record lock, heap no 78 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
     0: len 8; hex 0000000000000063; asc        c;;
     1: len 6; hex 000000000000; asc       ;;
     2: len 7; hex 80000000000000; asc        ;;
     3: len 8; hex 0000000000004328; asc       C(;;
     4: len 8; hex 000000000000a496; asc         ;;
     5: len 8; hex 0000000000004328; asc       C(;;
     6: len 5; hex 99aca08e59; asc     Y;;
     7: len 1; hex 02; asc  ;;
     8: len 1; hex 00; asc  ;;
    
    *** (2) TRANSACTION:
    TRANSACTION 130522295, ACTIVE 2 sec fetching rows
    mysql tables in use 1, locked 1
    5512 lock struct(s), heap size 761976, 1371587 row lock(s)
    MySQL thread id 96931, OS thread handle 139662878275328, query id 77554513 127.0.0.1 Updating
    DELETE FROM common_likes WHERE peer_id = '71663'
    *** (2) HOLDS THE LOCK(S):
    RECORD LOCKS space id 60 page no 10 n bits 336 index PRIMARY of table `common_likes` trx id 130522295 lock_mode X
    Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
     0: len 8; hex 73757072656d756d; asc supremum;;
  • MySQL Deadlock found?

    @serious911 Автор вопроса
    mayton2019, Значений seen всего 2: 0 и 1. Индекс добавил так как есть еще запросы для определения количества непросмотренных записей:
    SELECT COUNT(`id`) AS `counter` FROM table WHERE user_id = '79773' AND sender_id != '79773' AND status = '1' AND seen = '0';
  • Минимальная версия Ubuntu Server 18.04?

    @serious911 Автор вопроса
    GUI в Ubuntu Server вроде нет...
  • Вложенные шаблоны Golang?

    @serious911 Автор вопроса
    Александр Павлюк, Да, я согласен с вами. Но у меня два разных роута("/", "/terms"), два разных шаблоны ("index.html", "terms.html") и один общий шаблон layout.html. Данные я не передаю в шаблон вообще (пустой объект). Я хочу просто выводить разный html на разных страницах, но при этом использовать общий шаблон layout.html для того, чтобы в каждом шаблон отдельно не подключать все css/js/мета теги и т.п.
  • Вложенные шаблоны Golang?

    @serious911 Автор вопроса
    Александр Павлюк, пробрасывается пустой объект: context.HTML(200, "terms.html", gin.H{}). Текст берется из шаблона - указан он в блоке content в теге h1, но он разный для каждой страницы.
  • Система личных сообщений (шардинг)?

    @serious911 Автор вопроса
    Спасибо за полезные ссылки и материалы!
  • Система личных сообщений (шардинг)?

    @serious911 Автор вопроса
    Спасибо! Очень интересно.
  • Система личных сообщений (шардинг)?

    @serious911 Автор вопроса
    Dmitry Bay, Я знаю, что не все так просто :) Поэтому и спрашиваю
  • Система личных сообщений (шардинг)?

    @serious911 Автор вопроса
    Спасибо за информацию. Опыт интересный, но у них слишком кастомное решение + свой движок сообщений. То есть использовать его из коробки скорее всего не получится или займет слишком много времени, чтобы интегрировать в приложение.
  • Привязка пользователя к IP-адресу?

    @serious911 Автор вопроса
    Привязка по IP в данном случае как раз и нужна для дополнительной безопасности. Чтобы пользователи с другим IP не могли использовать API-ключ.
  • Привязка пользователя к IP-адресу?

    @serious911 Автор вопроса
    IP выдает провайдер интернета. Как я могу выдавать пользователям IP-адреса? А нужно это для того, чтобы избежать воровства API-ключа и использования его другими пользователями с другими IP. О том, что существует NAT/динамический IP и т.п. я в курсе - нужна привязка к IP в рамках текущей сессии.
  • Шардинг MySQL и поиск по шардам?

    @serious911 Автор вопроса
    Спасибо за конструктивные советы. Согласен, что в принципе имеет смысл вынести сообщения юзеров в отдельную Монгу/Кассандру.

    >Полная копия базы юзеров (типа шардированной) в эластике
    здесь я имел в виду не полную базу юзеров, а только самую необходимую информацию о всех юзерах (например, имя, пол, возраст, аватар и т.п.), а переписку 2-х пользователей с разных шардов дублировать одновременно на 2-х шардах.

    > Шардинг - последний вариант, когда другие уже не возможны.
    Возможно, но именно к шардингу в итоге пришли все более-менее крупные приложения типа Вконтакте, Instagram, различные мессенджеры и т.п. Именно так, судя по их докладам, они хранят данные в реляционной базе типа MySQL и это работает. Мне до них ооооочень далеко, но все же хочется узнать как это делают большие приложения и заложить такую возможность в архитектуру своего приложения на данном этапе (250 000 юзеров), чтобы иметь возможность быстрого роста за счет простого добавления нового сервера (шарда) и избежать проблем в будущем.
  • Шардинг MySQL и поиск по шардам?

    @serious911 Автор вопроса
    Спасибо за ответ. Да, теоретически 6 млрд пользователей в базе займут пару терабайт, но если в приложении есть еще и другой функционал, то скорее всего это может не поместится в пару терабайт. Например, в системе личных сообщений 6 млрд пользователей будут общаться между собой и генерировать при этом большой объем данных. Кроме того, скорее всего будет сложно делать/восстанавливать бэкапы базы в несколько терабайт.

    На данный момент все-таки думаю хранить данные на нескольких шардах MySQL и одновременно работать только с шардом текущего пользователя, а необходимые данные о пользователях с других шардов хранить в каком-то поисковом движке/кеше типа ElasticSearch/Sphinx.
  • Шардинг MySQL и поиск по шардам?

    @serious911 Автор вопроса
    Мне кажется, что у Вас великий талант - гадать на кофейной гуще, высвечивать все в негативном свете и оскорблять. Обычно я очень быстро прекращаю общение с такими людьми, но все же решил ответить.

    > Юноша, конструктивный совет я тебе дал: учись работать с БД
    Я Вам не "юноша" и "липких подростковых фантазий" у меня нет. Работать с различными базами (MySQL, MongoDB) я умею на достаточном уровне.

    > понятное дело что учиться - это скучно и совсем не так романтично
    Ну вот я пытаюсь разобраться с тем как правильно распределить пользовательские данные на несколько серверов БД и как делать в этом случае поиск. Вместо каких-то советов / решений меня обвиняют в "личной неграмотности", "влажных эротических мечтаниях" и "подростковых фантазиях". Похоже, что здесь осталось мало адекватных людей.

    > любители "конкретных ответов" сами задать конкретный вопрос не в состоянии
    Я задал 3 конкретных вопроса, с которыми пока не смог разобраться:
    1) Как работать из Node.js приложения одновременно с десятками шардов (серверов БД)?
    2) Как осуществлять поиск / извлечение данных из разных шардов?
    3) На какие подводные камни стоит обратить внимание на начальном этапе, чтобы избежать проблем в будущем?

    > ты не смог дать ни одной конкретной цифры, а только мутные страдания про то что данные не поместятся
    Все дело в том, что Вы поспешно делаете выводы и сразу же высвечиваете все в негативном свете.

    > данных у тебя нет и не предвидится, а есть только липкие подростковые фантазии
    Сейчас у меня примерно 250 000 зарегистрированных пользователей. В приложении есть система личных сообщений между пользователями и уже этого достаточно для того, чтобы понять, что нужно как-то распределить / вынести данные на несколько серверов БД. Вариант мастер-слейв или мастер-мастер репликации я не рассматриваю потому, что это поможет распределить нагрузку только первое время. Бесконечно плодить реплики большой базы особо смысла не вижу. Здесь и ответ на Ваш вопрос - "Попробуй объяснить, хотя бы самому себе, каким боком здесь шардинг свалился".

    > Каковые знания и надо прокачивать, вместо влажных эротических мечтаний про шардинг
    Спасибо. Вы мне в этом вопросе очень помогли.
  • Шардинг MySQL и поиск по шардам?

    @serious911 Автор вопроса
    Спасибо за ответ. Не вижу смысла дальше обсуждать все вышесказанное в этом ответе потому, что вместо каких-то конструктивных советов и решений дискуссия переходит в русло личный оскорблений. Поэтому остановлюсь на своей личной неграмотности и влажных эротических мечтаниях про шардинг.
  • Шардинг MySQL и поиск по шардам?

    @serious911 Автор вопроса
    Спасибо за ответ.

    > я не знаю что мне надо, но вообразил что мне нужен шардинг, поэтому расскажите как им пользоваться
    Я знаю, что мне надо. Мне нужно распределенное хранилище пользовательских данных с возможностью добавления новых серверов (при необходимости).

    > Нет, бояться миллиона записей не надо.
    Я боюсь не миллиона записей в БД, а того что все пользовательские данные (профили, переписка и т.п.) не поместятся физически на одном сервере и в одной БД. Возможно и поместятся, но все будет ужасно тормозить + нужно будет покупать какой-то супер-навороченный сервер. Кроме того, это будет единственная точка отказа и в этом случае придется делать бекапы на десятки/сотни гигабайт. Сколько времени при этом будет занимать создание индексов?

    Что плохого в том, что я хочу добавить возможность распределения данных на несколько серверов? Да, я не понимаю некоторые моменты, поэтому и задал вопрос для более опытных ребят.