в четвертой задаче (The Midnight Masquerade Murder) ответ находится корректно, но как будто решение получается короче, чем описано в итоге.
в общем, идея интересная, мне игра понравилась, но всё какое-то "сырое". и есть ощущение, что автор на гитхабе сам не до конца разобрался в теме. возможно, ему помогали с sql-данными и подготовкой задач.
позволяет включать неагрегированные столбцы в SELECT, который использует предложение GROUP BY
кстати, такое поведение зависит от настройки sql_mode и отсутствия в ней режима ONLY_FULL_GROUP_BY. причем в 8-ой версии mysql этот режим включен по умолчанию, поэтому движок будет ругаться на "nonaggregated column" в списке столбцов запроса.
по-моему, легендарная статья : ) одно время она была первой в выдаче поисковиков по теме уровней изолированности в Mysql, и потому смутила многие неокрепшие умы... но как уже отметили много лет назад, в тексте есть критические ошибки в описании режима READ COMMITTED (не считая более мелких неточностей).
я думаю, на текущей стадии оба продукта уже решают разные задачи и преследуют разные цели. сфинкс остался верен себе и заточен именно под текстовый поиск с очень широкими возможностями калибровки. сейчас это закрытая разработка, концы ведут куда-то в Авито. мантикора, судя по их постам здесь на хабре, не скрывает, что нацелена на замену эластику (поиск плюс аналитика данных).
SET SESSION cte_max_recursion_depth = 10000;
WITH RECURSIVE
counter (i) AS (
SELECT 0 UNION ALL SELECT i + 1 FROM counter WHERE i < 1800
),
pixels (x, y) AS (
SELECT i % 60 * 0.5, TRUNCATE(i / 60, 0) FROM counter LIMIT 1800
),
sdf (x, y, d) AS (
SELECT x, y, (y-15)*(y-15) + (x-15)*(x-15) FROM pixels
)
SELECT
group_concat(substr('█▓▒░:- ', least(greatest(d / 30, 1), 7), 1) SEPARATOR '')
FROM sdf
GROUP BY y;
отметился в первой части, и здесь тоже повторюсь. агрегацию нужно сразу делать на AggregatingMergeTree(в отдельных случаях SummingMergeTree) без лишних "плясок с бубном" и борьбой с дубликатами.
для тех, кто читает комменты, - не повторяйте написанное в статье : ) не вижу практического смысла пытаться реализовать агрегацию через ReplacingMergeTree, он не для того нужен.
как уже было сказано в предыдущем комментарии, типовую агрегацию данных следует делать на специальном движке AggregatingMergeTree в связке со -State-функциями в матпредставлении (эти функции хранят промежуточное агрегатное значение). для выборки использовать AggregateFunction() (см. документацию). такой подход избавит от проблем дубликатов и других "костылей" (вроде вспомогательных cron-скриптов с дополнительной логикой). в сети достаточно гайдов для построения различных метрик на агрегатах (включая официальные от Clickhouse или Altinity). или, вот например, свежая статья здесь на хабре: https://habr.com/ru/articles/736518/
в новой версии. в старой раздела "Посты" нет. перелогинился, теперь почему-то сразу пишет "Только авторизованные пользователи с правами Read&Comment и выше могут писать посты."
картинка Ларри Элмора (с битвой героев и дракона на снежном поле под стенами замка) была на обложке пиратского диска M&M6 в конце 90-х. это был мой первый игровой cd-диск в принципе. ух, флэшбэк из прошлого! : ))
офтоп. прошу прощения, может, уже озвучивали. у вас на скриншоте 3 колонки мини (с часами) и 1 лайт в разных комнатах. чем вызван именно такой набор устройств? есть ли разница между мини и лайт для ваших целей? спасибо!
я думаю, тут описано другое разделение типов. "логические" бэкапы - это когда восстановление происходит через выполнение sql-команд из текстовых дампов. а "физические" - это бэкапы на уровне бинарных файлов. ваш способ (mysqldump+select into outfile) относится к "логическому".
при этом авторский вариант инкрементальных бэкапов - это некий гибрид. главный бэкап через mysqldump, а дельта-инкременты - через файлы бинарного журнала (хотя в конце концов их придется преобразовать в sql-команды перед восстановлением).
похоже на опечатку. в оригинале "Graceful primary failover workflow", и собственно далее уже у вас правильный перевод "primary" как "первичный узел".
соглашусь со сказанным выше.
в третьей задаче (The Miami Marina Murder) сейчас наблюдается баг с айдишниками, здесь связи персонажей нарушены. и авторским решением выйти на преступника не получится. об этом уже и баги заведены:
https://github.com/hristo2612/SQLNoir/issues/17
https://github.com/hristo2612/SQLNoir/issues/29
в четвертой задаче (The Midnight Masquerade Murder) ответ находится корректно, но как будто решение получается короче, чем описано в итоге.
в общем, идея интересная, мне игра понравилась, но всё какое-то "сырое". и есть ощущение, что автор на гитхабе сам не до конца разобрался в теме. возможно, ему помогали с sql-данными и подготовкой задач.
нужно сделать акцент, что это движок для уровня базы данных, а не конечной таблицы, т.к. возможна путаница названий (см. ниже).
здесь опечатка, должно быть ReplicatedMergeTree.
и у вас разные ссылки на официальную документацию почему-то с разными языками.
кстати, такое поведение зависит от настройки sql_mode и отсутствия в ней режима
ONLY_FULL_GROUP_BY. причем в 8-ой версии mysql этот режим включен по умолчанию, поэтому движок будет ругаться на "nonaggregated column" в списке столбцов запроса.по-моему, легендарная статья : ) одно время она была первой в выдаче поисковиков по теме уровней изолированности в Mysql, и потому смутила многие неокрепшие умы...
но как уже отметили много лет назад, в тексте есть критические ошибки в описании режима READ COMMITTED (не считая более мелких неточностей).
я думаю, на текущей стадии оба продукта уже решают разные задачи и преследуют разные цели. сфинкс остался верен себе и заточен именно под текстовый поиск с очень широкими возможностями калибровки. сейчас это закрытая разработка, концы ведут куда-то в Авито.
мантикора, судя по их постам здесь на хабре, не скрывает, что нацелена на замену эластику (поиск плюс аналитика данных).
спасибо! посмотрел, что еще было на тему агрегации в кликхаусе на хабре. у вас получилось лучше, чем у https://habr.com/ru/articles/657579/
спасибо за пример! адаптировал под mysql 8:
отметился в первой части, и здесь тоже повторюсь.
агрегацию нужно сразу делать на
AggregatingMergeTree(в отдельных случаяхSummingMergeTree) без лишних "плясок с бубном" и борьбой с дубликатами.для тех, кто читает комменты, - не повторяйте написанное в статье : ) не вижу практического смысла пытаться реализовать агрегацию через ReplacingMergeTree, он не для того нужен.
как уже было сказано в предыдущем комментарии, типовую агрегацию данных следует делать на специальном движке
AggregatingMergeTreeв связке со -State-функциями в матпредставлении (эти функции хранят промежуточное агрегатное значение). для выборки использовать AggregateFunction() (см. документацию). такой подход избавит от проблем дубликатов и других "костылей" (вроде вспомогательных cron-скриптов с дополнительной логикой).в сети достаточно гайдов для построения различных метрик на агрегатах (включая официальные от Clickhouse или Altinity). или, вот например, свежая статья здесь на хабре:
https://habr.com/ru/articles/736518/
@Boomburumтут не появилось ясности? у меня прав нет, или это баг какой-то?
в новой версии. в старой раздела "Посты" нет. перелогинился, теперь почему-то сразу пишет "Только авторизованные пользователи с правами Read&Comment и выше могут писать посты."
скриншот
@Boomburum так все таки это баг или фича? : ) не получается сделать пост с правами Read&Comment.
пробую опубликовать пост, ввожу текст, но при нажатии на кнопку ошибка "Only for normal users". почему так? есть еще какие-то ограничения? спасибо!
картинка Ларри Элмора (с битвой героев и дракона на снежном поле под стенами замка) была на обложке пиратского диска M&M6 в конце 90-х. это был мой первый игровой cd-диск в принципе.
ух, флэшбэк из прошлого! : ))
офтоп. а по другим продуктам что-нибудь аналогичное появилось? в частности по субд Oracle или даже Mysql?
офтоп. прошу прощения, может, уже озвучивали. у вас на скриншоте 3 колонки мини (с часами) и 1 лайт в разных комнатах. чем вызван именно такой набор устройств? есть ли разница между мини и лайт для ваших целей? спасибо!
вы серьезно никогда не слышали название столицы Малайзии?
и из них половина случаев - это поддержка легаси : )
я думаю, тут описано другое разделение типов. "логические" бэкапы - это когда восстановление происходит через выполнение sql-команд из текстовых дампов. а "физические" - это бэкапы на уровне бинарных файлов.
ваш способ (mysqldump+select into outfile) относится к "логическому".
при этом авторский вариант инкрементальных бэкапов - это некий гибрид. главный бэкап через mysqldump, а дельта-инкременты - через файлы бинарного журнала (хотя в конце концов их придется преобразовать в sql-команды перед восстановлением).