Угу-угу, видел. 30к rps, заложено 12 шардов, рост баз в сумме под полтеррабайта в месяц. Для чатика со 100 сообщениями. В сутки.
Так что охотно верю что "иначе пишется". И порой это просто мастер-класс на тему как устроить хайлоад там где не надо.
Так что не надо мне тут всяких "фи, это не хайлоад". Один фиг определения этого сугубо маркетингового словечка нет. Никакого. Всяк кулик своё болото хвалит и я достаточно знаком с твоим стилем чтобы заранее ожидать натягивание мнимого понимания ярлыка хайдоада только к тому, что оно такое есть только у вас.
Отлично, давай продолжим натягивать сову дальше - у вас тоже не хайлоад, ведь вы не гугл.
Аааа! 10к rps - это ведь охрененно много! Царь и повелитель, никто из нас не смеет стоять подле вас! Помилуйте недостойного раба вашего! Я внял вашим речам и снизошло откровение ваше на меня! Теперь я вижу, что никто не смеет назваться разработчиком не поработав с такой нагрузкой!
Всё, отстань, несчастная жертва хайпа. Я этим уже переболел.
LIME пишет:
а суть разница? логи в мускуле вообще больная тема...сам понимаешь
я тут скорее намекнул о возможности применить новые решения отчетов
Это разные вещи. Сваливать в кучу репликацию и general log - некорректно.
И давно кликхаус научился читать бинлог репликации mysql? Каких версий? Что он оттуда может достать? Из stmt-based? Из row-based? из mixed? Что из этого ответит на задачу автора?
Да в общем-то даже интересно зачем кликхаус этому учить, на сколько помню яндекс на postgresql и оракле, не было там mysql, это не mailru с тарантулом. А если не умеет - то причём тут он?
Цитата:
Сказка о Грепке: посадил старик скрипт аналитики на сайт, выросла аналитика большая-пребольшая. Парсит старик Хадупом, парсит, падает Хадуп по out of memory. Зовёт старик Кафку. Парсит Кафка за Хадуп, Хадуп за аналитику, падает. Зовёт старик Грепку. Грепка за 2 минуты всё парсит
LIME пишет:
каждое новое в uuid это переиндексация
Нет. Ну или используй нормальную терминологию. Типичная вставка в дерево. Только всё немного портит характер случайности эталонной реализации uuid, дёргаем постоянно разные части дерева, пачкаем разные части дерева. Дальше просто отправлю читать статью Томаса: https://www[dot]2ndquadrant[dot]com/en/b[dot][dot][dot]uuid-generators/
LIME пишет:
нууу...давай такой зашквар вообще не рассматривать
Каждый третий. И не такое творят. И все называют себя хайлоадом. Вот прям как некоторый LIME.
LIME пишет:
ты узко направлен на реляционную и транзакционную бд
И?
Транзакционники старше меня и никуда не денутся после меня. Это может быть другая база, это может быть не REDO или UNDO recovery из-за подешевевших reram или PCM, это может быть изменённое до неузнаваемости что-то из современного мира. Что остаётся - СУБД будут нужны всегда, гарантии транзакционности будут нужны всегда. И контрибьютор СУБД (если мне не наскучит ковырять код базы) понадобится всё так же. А наскучит - сменить специализацию можно. Я пробовал менять специальность, получилось. IT огромен. Какой смысл заниматься тем что насаждает маркетинг и хайп, вместо того что интересно конкретному индивиду?
LIME пишет:
это не есть пуля
А с какого перепугу веришь в насаждаемую мысль, что хайлоад - серебрянная пуля и единственный вариант развития?
Два факта из биографии:
- уменьшил число обращений к redis вдвое на проекте с 1к rps (и ничего не сломал)
- сломал существовавший уже второе десятилетие recovery.conf в postgresql
Угадай, что из этого было гораздо сложнее, более волнительно и интересно, но при этом не имеет ровно никакого отношения к метрикам rps?
Как странно, неужели вот эта фраза призванная разбить меня:
LIME пишет:
реально сложные задачи сложны по определению...приходится думать
смотри шире
Не имеет к хайлоаду ровным счётом никакого отношения? Удивительное рядом. Смотри шире (с) LIME
И ох уж это высокомерие социалочников. Пара сотен тысяч транзакций в секунду долетает до кластера базы после кешей. Тянем? Тянем. Это рентабельно? Да. Ну и ок, работаем спокойно. Мне даже не интересно, сколько rps на какой из систем. 10к? 40к? Есть. И да, это всё про один из 4 примеров, что ты так высокомерно отмёл.
Ну и святая уверенность что много rps нужны всем и каждому - это печально. Взрослей, мне казалось ты уже достаточно времени провёл в хайлоаде чтобы понимать такую очевидную вещь. Есть куча мест, где более чем достаточно условных 1к rps с простыми работающими подходами, не отвлекающими от других интересных задач. И где все эти заморочки из нагрузок побольше не только бессмысленны и бесполезны, но дико вредны и опасны.
Вот с чего ты безапелляционно решил, что автор темы озадачен не исследованием на локалхосте, какие именно dml запросы выполняет приложение? Да, в засилье всякого orm это действительно может быть удобнее спрашивать именно у базы. Или может быть речь о настройке аудита действий людей (не приложения) на продовом сервере? Или ещё что? При чём тут тысячи rps?
кого я там могу открыто называть с кем работаем?.. Lamoda, HH, uchi, coub. Ну раз не видел всего-то 10к rps - спорить мне что ли и показывать графики? Не могу показывать. Так что ладно, это число - что-то большое. Наверное.
LIME пишет:
как ты думаешь насчет uuid?
Люди его почему-то любят. За что - не знаю. Ещё почему-то любят писать его в varchar или text. Получается совершенно по дурацки пишется в btree, так и со статистикой значений каша.
LIME пишет:
вариант бинлог + clickhouse
бинлог != general log.
Бинлог это скорее про репликацию в mysql.
LIME пишет:
какой же ты стал самоофигенный))))
Сергей...есть многое что и не снилось нашим мудрецам
понял о чем я?
По администрированию mysql меня спрашивать в общем случае бесполезно. В определённых чертах знаю как он работает и как работать с ним с точки зрения разработчика, но не как его обслуживать.
Из коробки некоего log_statement=dml насколько знаю нет.
Есть general log со всеми запросами (не только DML)
Есть API для модулей аудита. Возможно есть подходящие готовые плагины.
Есть statement-based репликация - возможно можно так получать запросы.
Впрочем, в enterprise есть audit log (что, собственно, одновременно отвечает, почему такого нет в community-edition)
Только определитесь, вы count считаете на базе или num_rows проверяете в PHP.
Потому что count без явной группировки будет возвращать всегда 1 строку независимо от данных, что мигом лишает смысла всю проверку.
Понять, что вы хотите сделать. Затем уже по разному бывает
Или переписать запросы в цикле в один запрос вне цикла.
Или неожиданно понять, что эти запросы вовсе не нужны и пересмотреть схему данных
Обычный race condition. Обычно и решается. То есть раз об этом не думали сразу -то серебряной пули нет.
Раз говорите про СУБД - значит неверное сериализуете транзакции. Разберите что вы должны сделать в транзакции, какие локи вы для этого берёте и какие локи необходимо добавить до стабильной сериализации вносимых изменений.
Хахаха! Нее, вот как раз "тормозить на нынешней работе" - это неплохое описание для большой части моей истории
есть невесёлая загадка "чем больше узнаешь - тем лучше понимаешь сколь мало знаешь" и как при этом не пропустить нюанс, что это нормально и, более того, иначе быть не может. И вправить самооценку на положенное место
То-то и оно, что пагинируют как? Навскидку условие "пользователь проявлял активность недавно" как раз весьма селективно относительно множества всех пользователей.
Обрати внимание: к множеству активных пользователей есть ещё фильтры. В частности (неверно написанный) inner join к shipping. И по этому условию возможно будет обрезано неопределённое число пользователей. Как это пагинировать?
Ситуацию, впрочем, чуть улучшает явная сортировка по независимому критерию. Так что вторую страницу можно сделать нормально передав последний id с прошлой страницы. Но всё равно: мы не можем затребовать topN записей и приклеить к ним недостающие данные со второй базы. Потому что там есть свои фильтры и вместо N рискуем получить вплоть до 0 в результате.
Кстати, проблему никак не облегчает и то, когда это разные таблицы в одной базе. Всё тот же напрасный перебор в join filter. Накопали пользователей на страницу быстро - повезло. А можно и миллионы строк перебрать в поисках тех 10 нужных. Пересечение больших множеств так просто не считается.
LIME пишет:
Вакуум не устанет?
Найдёшь его в mysql? Хинт: нет его.
LIME пишет:
Я вот думаю как себя будет таблица юзеров чувствовать если на каждый запрос новая версия mvcc?
Ну а касательно postgresql - на каждый запрос всегда прокручиваются колёса mvcc машинерии. Даже index only scan - лишь возможность пропустить проверку видимости, если visibility map сказал что можно. А в пределе это может быть неотличимо от index scan. Проверяем, видна ли эа эта версия строки текущей транзакции. А перебираем строки те же самые, из прошлого, будущего (относительно этой транзакции), редкие из настоящего. Потому и вопрос - какова сущность данных в activity? append only лог и постоянный update неких счётчиков будут вести себя весьма различно.
Для innodb логика mvcc тоже прокручивается, но со своими тараканами. В листьях primary key всегда самая последняя версия строки, даже если не закоммичена ещё. Читатели в поисках видимой им версии лезут в журнал записи и достают оттуда предыдущие версии строки если им надо.
LIME пишет:
я только одно могу придумать
сортировать таблицу юзеров по последней активности
Не сортировать, а фильтровать. Нормальная бизнесхотелка вывести каких-то пользователей, исключая неактивных.
Реалтайм для этого не нужен, да. Но это вопрос именно разработки подойти и спросить у бизнеса: "какая задержка будет не важной для попадания пользователя в этот список? 15 минут ок?"
Или ещё как поизвращаться. Но чтобы извращаться - надо знать свои данные.
А для бизнеса задача как раз вполне осмысленно выглядит.
Вот как дба у меня и нет желания думать в этой теме.
Ок, activity выкинули куда-то. Дальше что? where U.id in (100 тысяч чисел на несколько мегабайт размером запрос)? Хрень это будет, а не оптимизация. Изобретать inner join на приложении и сделать 100 тысяч походов в редис чтобы отсечь некоторое количество из них? Опять хрень получилась.
А какое реальное распределение данных? Что такое activity? append-only лог или постоянный update одних и тех же счётчиков?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 11869
