PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи

Страниц (789): « 1 2 3 4 [5] 6 7 8 9 ... » В конец

> Найдено сообщений: 11826
Мелкий Отправлено: 19 Июня, 2019 - 18:52:23 • Тема: Как написать запрос с подзапросом • Форум: SQL и Архитектура БД

Ответов: 2
Просмотров: 260
ninzzo пишет:
у пользователя 1 есть общий чат например с 5 ?

something like...
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT chat_id FROM chats WHERE user_id IN (1,5) GROUP BY chat_id HAVING count(*) = 2


или
CODE (SQL):
скопировать код в буфер обмена
  1. (SELECT chat_id FROM chats WHERE user_id = 1)
  2. intersect
  3. (SELECT chat_id FROM chats WHERE user_id = 5)


ну или
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT chat_id FROM chats c1 WHERE user_id = 1 AND EXISTS (SELECT FROM chats c2 WHERE c2.user_id = 5 AND c2.chat_id = c1.chat_id)
Мелкий Отправлено: 08 Июня, 2019 - 12:49:37 • Тема: Вытащить данные из второй таблицы при наличии совпадения • Форум: SQL и Архитектура БД

Ответов: 4
Просмотров: 141
Gerd пишет:
Не работает, показывает результат тогда, когда есть совпадение в обеих таблицах.

Значит вы сами превратили его в неявный inner join. Например, условиями в where
Мелкий Отправлено: 21 Мая, 2019 - 13:02:30 • Тема: Логирование определенных запросов mysql • Форум: SQL и Архитектура БД

Ответов: 13
Просмотров: 351
LIME пишет:
хайлоад теперь это шардинг, репликации, и сверху

Угу-угу, видел. 30к rps, заложено 12 шардов, рост баз в сумме под полтеррабайта в месяц. Для чатика со 100 сообщениями. В сутки.
Так что охотно верю что "иначе пишется". И порой это просто мастер-класс на тему как устроить хайлоад там где не надо.

Так что не надо мне тут всяких "фи, это не хайлоад". Один фиг определения этого сугубо маркетингового словечка нет. Никакого. Всяк кулик своё болото хвалит и я достаточно знаком с твоим стилем чтобы заранее ожидать натягивание мнимого понимания ярлыка хайдоада только к тому, что оно такое есть только у вас.
Отлично, давай продолжим натягивать сову дальше - у вас тоже не хайлоад, ведь вы не гугл.
Мелкий Отправлено: 20 Мая, 2019 - 13:57:54 • Тема: Логирование определенных запросов mysql • Форум: SQL и Архитектура БД

Ответов: 13
Просмотров: 351
Аааа! 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?
Мелкий Отправлено: 18 Мая, 2019 - 21:38:15 • Тема: Логирование определенных запросов mysql • Форум: SQL и Архитектура БД

Ответов: 13
Просмотров: 351
LIME пишет:
эээх не юзал ты решения по 10к rps

кого я там могу открыто называть с кем работаем?.. Lamoda, HH, uchi, coub. Ну раз не видел всего-то 10к rps - спорить мне что ли и показывать графики? Не могу показывать. Так что ладно, это число - что-то большое. Наверное.

LIME пишет:
как ты думаешь насчет uuid?

Люди его почему-то любят. За что - не знаю. Ещё почему-то любят писать его в varchar или text. Получается совершенно по дурацки пишется в btree, так и со статистикой значений каша.

LIME пишет:
вариант бинлог + clickhouse

бинлог != general log.
Бинлог это скорее про репликацию в mysql.

LIME пишет:
какой же ты стал самоофигенный))))
Сергей...есть многое что и не снилось нашим мудрецам
понял о чем я?

Нет, не понял. Могу догадываться
Мелкий Отправлено: 18 Мая, 2019 - 18:33:48 • Тема: Логирование определенных запросов mysql • Форум: SQL и Архитектура БД

Ответов: 13
Просмотров: 351
LIME пишет:
мелкий слово за тобой

По администрированию mysql меня спрашивать в общем случае бесполезно. В определённых чертах знаю как он работает и как работать с ним с точки зрения разработчика, но не как его обслуживать.

Из коробки некоего log_statement=dml насколько знаю нет.

Есть general log со всеми запросами (не только DML)
Есть API для модулей аудита. Возможно есть подходящие готовые плагины.
Есть statement-based репликация - возможно можно так получать запросы.
Впрочем, в enterprise есть audit log (что, собственно, одновременно отвечает, почему такого нет в community-edition)
Мелкий Отправлено: 16 Мая, 2019 - 19:44:19 • Тема: Авторизация пользователя • Форум: Вопросы новичков

Ответов: 6
Просмотров: 147
Только определитесь, вы count считаете на базе или num_rows проверяете в PHP.
Потому что count без явной группировки будет возвращать всегда 1 строку независимо от данных, что мигом лишает смысла всю проверку.

ну и привет sql инъекциям.
Мелкий Отправлено: 14 Мая, 2019 - 20:55:42 • Тема: Проблемы с работой бота. • Форум: Вопросы новичков

Ответов: 4
Просмотров: 120
ghjkdk пишет:
$vk->sendMessage

Смотрю я на ключевые слова и думаю про пункты 1.6 и 1.7 правил.
Ну а затем про правила самого vk, а так же ограничения их собственного сервиса.
Мелкий Отправлено: 08 Мая, 2019 - 12:42:00 • Тема: как переписать мой код чтобы снизить количество запросов к БД ? • Форум: Вопросы новичков

Ответов: 1
Просмотров: 47
Понять, что вы хотите сделать. Затем уже по разному бывает
Или переписать запросы в цикле в один запрос вне цикла.
Или неожиданно понять, что эти запросы вовсе не нужны и пересмотреть схему данных
Мелкий Отправлено: 08 Мая, 2019 - 12:36:59 • Тема: Проблема с отправкой двойных запросов к Базе Данных при заходе на страницу • Форум: Вопросы новичков

Ответов: 2
Просмотров: 52
Обычный race condition. Обычно и решается. То есть раз об этом не думали сразу -то серебряной пули нет.
Раз говорите про СУБД - значит неверное сериализуете транзакции. Разберите что вы должны сделать в транзакции, какие локи вы для этого берёте и какие локи необходимо добавить до стабильной сериализации вносимых изменений.
Мелкий Отправлено: 02 Мая, 2019 - 12:43:59 • Тема: Как задать рандомное имя для загружаемого файла? • Форум: Вопросы новичков

Ответов: 17
Просмотров: 294

Спойлер (Отобразить)
Мелкий Отправлено: 28 Апреля, 2019 - 21:52:59 • Тема: почему не работает case? • Форум: Вопросы новичков

Ответов: 8
Просмотров: 143
Неуместен, да. switch используется для проверки на равенство.

Логически корректно, впрочем, будет
PHP:
скопировать код в буфер обмена
  1. switch (true) {
  2.     case ($result<0):

Но обычно такой вариант не используется.
Мелкий Отправлено: 28 Апреля, 2019 - 19:22:20 • Тема: почему не работает case? • Форум: Вопросы новичков

Ответов: 8
Просмотров: 143
Perun пишет:
switch($result){
    case ($result<0) : {

Здесь замысловато написано:

Работает соответственно этому корректно.
Мелкий Отправлено: 27 Апреля, 2019 - 23:41:56 • Тема: Исключающее ИЛИ • Форум: Вопросы новичков

Ответов: 2
Просмотров: 78
PHP:
скопировать код в буфер обмена
  1. $x = (true xor true);
  2. // или
  3. ($x = true) xor true;

Что предполагаете вы, а что выполняет PHP?
Ответ: https://www.php.net/manual/en/la...s.precedence.php
Мелкий Отправлено: 24 Апреля, 2019 - 23:27:37 • Тема: Оптимизировать MySQL запрос? • Форум: SQL и Архитектура БД

Ответов: 8
Просмотров: 284
LIME пишет:
100 тыс не понадобится в выборке
Такое пагинируют

То-то и оно, что пагинируют как? Навскидку условие "пользователь проявлял активность недавно" как раз весьма селективно относительно множества всех пользователей.
Обрати внимание: к множеству активных пользователей есть ещё фильтры. В частности (неверно написанный) 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 минут ок?"
Или ещё как поизвращаться. Но чтобы извращаться - надо знать свои данные.
А для бизнеса задача как раз вполне осмысленно выглядит.

Страниц (789): « 1 2 3 4 [5] 6 7 8 9 ... » В конец
Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB