• Отложенное сохранение большого объема статистики?

    terrier
    @terrier
    Ivan Palamarchuk,
    Понимаете, в чем дело, у вас тут все спрашивают конкретные цифры rps, потому что это определяющая информация для выбора решения. И, похоже вы сами их не очень представляете. Но видно, что нагрузка небольшая и если вы ради сервиса с 1000 rps построите кластер на 15-ти машинах с кафкой, кассандрой и хадупом - это будет печальный исход. Postgres + redis, нормальная система, почему бы нет. Так что на вашем месте я бы:
    - померил реальную нагрузку на сервис, на redis, на postgres и уяснил бы, где реально узкое место
    - починил код, работающий с redis. Вы с ним что-то принципиально не так делаете, если он у вас "не успевает сохранить строку"
    - настроил существующие системы по-нормальному

    Если бы у вас было 100х от текущей нагрузки, то было бы разумно сначала быстро в некую очередь сообщений, а на другом конце разгребать ее уже не задерживая прием/передачу, но пока у вас 1000 rps и, насколько я понимаю, в пределах полугигабайта данных в день, повторюсь, нужно настроить существующие системы.
  • Отложенное сохранение большого объема статистики?

    terrier
    @terrier
    Ivan Palamarchuk,
    То есть в идеальном случае до базы доходит 1 rps, но, поскольку ваш самодельный кэш с редисом неидеален, то получаем попыток записи в 2-3 раза больше, т.е. 2-3 rps. Так еще раз, а чем проблема?
    Отдельный вопрос, конечно, что вы такое делаете с редисом, что он "не успевает сохранить строку".
  • Отложенное сохранение большого объема статистики?

    terrier
    @terrier
    Ivan Palamarchuk,
    1 тысяча запросов в секунду к одному сервису, ... 99.9% запись в базу делать не нужно

    То есть отсылается информация о пользователе, отсылаются 1000 rps к сервису в секунду, но писать из них нужно только 1 из тысячи, потому что остальные дублируются?
  • Можете объяснить данный фрагмент кода?

    terrier
    @terrier
    Антон Жилин,
    Ну, во-первых, сама по себе идея, что "А в продакшне пусть падает" она подозрительная мягко говоря.
    Во-вторых ассерты нужны для тех случаев, которые разработчик считает "невозможными" и после которых восстановиться нельзя ( ну и для отладки).
    Ситуация, когда я прошу показать мне 17-го кота из 5-ти возможных нормальная ( если нет дополнительного контекста) и я бы ожидал ответ "Нет такого кота" в условленном формате, а все-таки не краш.
  • Можете объяснить данный фрагмент кода?

    terrier
    @terrier
    Антон Жилин
    При использовании беззнаковых и выполнении --0, в итоге получим Access Violation

    Ммм, не могли бы вы пояснить: вы полагаете, что код
    unsigned int x = 0;
    --x;

    вызовет Access Violation?
  • Как исключить одинаковые записи?

    terrier
    @terrier
    4ainik, Сейчас я бы сформулировал так - если вы начинаете новый проект, вам нужна бесплатная и/или открытая RDBMS и у вас нет
    - Команды энтузиастов какой-то другой системы
    - Обязанности поддерживать версию для Windows
    - Явной завязки на другую систему
    , то очень логично выбирать postgres - он очень функциональный и хорошо развивающийся.
  • Как исключить одинаковые записи?

    terrier
    @terrier
    4ainik, Ну, собственно, во всех вменяемых СУБД, кроме MySQL
    Вот, например, postgresql
    https://www.postgresql.org/docs/current/static/que...
  • Как исключить одинаковые записи?

    terrier
    @terrier
    А, да, тут MySQL в тегах. Ну, тогда тем более антиджойн выигрывает.
  • Оптимален ли такой JOIN запрос?

    terrier
    @terrier
    Не совсем.
    EXPLAIN читается в некотором смысле "снизу вверх", то есть результаты операций с бОльшим отступом подаются на вход операциям с меньшим отступом.
    Здесь у вас две "нижние" операции - это Seq Scan по таблице offers c фильтром по user_id = 12 и Materialize ( то есть как бы "загрузка в память" таблицы jobs).
    После этого на них делается JOIN ( с применением алгоритма Nested Loop, как мы видим в верхней строке).

    И, да, для того чтобы исполнить запрос и узнать что реально получилось нужно применять EXPLAIN ANALYZE - оптимизатор может и ошибаться по поводу оптимального плана
  • Волшебные сокеты через LD_PRELOAD?

    terrier
    @terrier
    liks, Не, ну все-таки требуется
    Preconditions:
    ...
    Physical installation of Mellanox Card in your machines
    Verify by "lspici | grep Mellanox" that your system recognized Mellanox HCA

    https://github.com/Mellanox/libvma/wiki/A---VMA-Ba...
  • Почему может быть раздута БД postgres?

    terrier
    @terrier
    А нет ли в постгресе какой-то команды или скрипта для проверки консистентности и автоматического исправления конфликтов между файлами и таблицами?

    Нет, это все-таки ненормальная ситуация и самый лучший совет для того, чтобы не появлялись такие файлы - это "не падать".

    И в какую сторону копать, дабы разобраться с крашами?

    Ну, в логи, понятно дело:
    - В системные. Никто там процесс постгреса не прибивает? Ограничения на память для процесса? OOM killer?
    - В постгресовые. Включите максимальное разумный уровень записи в логи, и смотрим там.
    - Настройки постгреса разумные? Проверьте здесь pgtune.leopard.in.ua
    - Можно попросить постгрес генерировать крэш дампы - разобраться, может и не получится, но в гугл строчки из бэктрейса в конце концов можно засунуть.
    - Железо. Обидно биться неделю об отладку только для того, чтобы узнать, что диск или память порченные. Бывает простое решение "перенести базу на другой сервер" самое лучшее ;)
  • Почему может быть раздута БД postgres?

    terrier
    @terrier
    Как я понял каждый relfilenode пересоздается после полного вакуума

    Да
    Могли ли обращения сторонних программ к залоченным таблицам во время вакуума привести к этому?

    Да, нет, ну залоченные они на то и залоченные что к ним просто так не обратишься. Но у вас, очевидно, произошел некий сбой.

    И как теперь можно намекнуть постгресу, что часть файлов уже не нужна, чтобы ничего не сломать?

    В принципе, если вы уверены, что для этого файла точно нет соответствия в базе, то его можно удалять, но это, конечно, ковбойский способ. Я бы, повторюсь, разобрался бы с крашами и пересоздал кластер. Сколько там эти 12 Гб будут заливаться - несколько минут?
  • Почему может быть раздута БД postgres?

    terrier
    @terrier
    Ну вот осталось выяснить, что скрывается за relfilenode 915532, 872720 и т.д.
    Можно глянуть
    select name, relkind from pg_class where relfilenode = ...

    Ну и на крайняк утилитка oid2name (oid и relfilenode могут, хотя и не обязаны совпадать)
    Также посмотрите на даты этих файлов через ls - может навести на мысль, откуда они появились.

    Если найти не удается, то, видимо, увы эти orphan файлы результаты сбоев вышей бд. Тогда нужно разобраться со сбоями и перезаписать кластер
  • Почему может быть раздута БД postgres?

    terrier
    @terrier
    x67, Ну, вот, собственно вы видите своими глазами, что таблиц у вас все-таки на 24 Гб.
    (/var/lib/postgresql/9.5/main/base/16384/915894.{1,2,3} - это сегменты, в которых хранится объект с relfilenode
    равным 915894 - видимо это одна из таблиц. Как видите, сегменты нарезаются по гигабайту).
    А почему вы решили, что у вас на 12 Гб таблиц?
  • Почему может быть раздута БД postgres?

    terrier
    @terrier
    9.5/main/base/12345 - папка бд

    Ну, да, собственно и вопрос - на какие конкретно файлы приходятся "лишние" 12G
    Гляньте что-нибудь типа
    du --max-depth=1 9.5/main/* | sort-nr
  • Критично ли если база заполняется пустыми столбцами?

    terrier
    @terrier
    Это не MySQL, где нужно следить за SELECT'ом. В PostgreSQL порой это наоборот занимает больше времени.

    Можно пруф на это утверждение?
  • На сколько плоха идея хранить данные о платежах в MongoDB?

    terrier
    @terrier
    heducose: Ну, смотрите - для финансовых операций вам как минимум нужны полноценные транзакции и какая-нибудь жесткая модель консистентности ( eventual consistency вас расстроит для этой задачи ). Сходу не могу припомнить NOSQL-решение, которое бы это обеспечивало и при этом было бы достаточно взрослым и распространенным, чтобы внедрять его в реальный продакшн в наших реалиях.
    Между тем, в "традиционных" RDBMS это более-менее тривиально.
  • Вопросы по статьям на хабре и википедии про уровни изоляции транзаций - почему так написано?

    terrier
    @terrier
    даже одиночные запросы оборачиваются в автотранзакции, поэтому этот сценарий потери апдейта в ms sql - чисто теоретический?

    Этот сценарий потери апдейта чисто теоретический, потому что запрещен стандартом.

    но при этом я почему-то хочу, чтобы при выполнении моих запросов существовало «грязное» чтение

    Мне сложно представить себе ситуацию, когда вы именно хотите грязное чтение. На более слабых уровнях изоляции применяются меньше локов, а следовательно производительность может быть больше. Именно это может быть мотивацией, чтобы их применять. В реляционных БД как правило ставить ниже READ COMMITED неразумно, а вот, например, в mongodb - READ UNCOMMITED - дефолтный уровень изоляции.
  • Вопросы по статьям на хабре и википедии про уровни изоляции транзаций - почему так написано?

    terrier
    @terrier
    Я понимаю, что он невозможен при уровне изоляции READ UNCOMMITED. Вопрос был в том, что тогда когда он возможен? Когда транзакции вообще нет?

    Когда изоляции транзакций нет. Отвлекаясь от баз данных, в любом языке программирования один поток делает a = a + 1 и другой поток делает a = a + 1. Если синхронизации ( т.е. изоляции ) нет, то на сколько увеличится значение переменной a? Вполне возможно, что на 1 - у нас потерянный апдейт. Однако, в системах, удовлетворяющих стандарту ANSI/ISO SQL такая ситуация запрещена, то есть хотя какая-нибудь изоляция есть всегда. Таким образом именно этот сценарий потери апдейта - чисто теоретический.