#игра дня
Такого я ещё точно не встречал. Вам предлагается найти убийцу, изучая улики, фотографии и рапорты с места преступления. Чтобы собственно все это прочесть и связать воедино — придётся вводить SQL-запросы к имитированной базе данных.
Дикая штука :) Есть примеры, есть и прохождение. Но попробуйте, особенно если изучаете базы данных прямо сейчас.
https://mystery.knightlab.com/
#db #sql
Такого я ещё точно не встречал. Вам предлагается найти убийцу, изучая улики, фотографии и рапорты с места преступления. Чтобы собственно все это прочесть и связать воедино — придётся вводить SQL-запросы к имитированной базе данных.
Дикая штука :) Есть примеры, есть и прохождение. Но попробуйте, особенно если изучаете базы данных прямо сейчас.
https://mystery.knightlab.com/
#db #sql
🔥18👎2🤯2👍1
#подкаст дня
Немного оффтопа про электрокары. Первый электрический автомобиль появился далеко не с выходом Tesla, а полтора века назад — в 1841 году.
В 1899 году электромобиль поставил рекорд в 105 километров в час и проехал 130 километров на одной зарядке.
Но на 100 лет вперёд распространение получили двигатели внутреннего сгорания. И получается, что сейчас Илон Маск развивает давно забытую технологию.
Та же аналогия прослеживается и с базами данных.
Объектно-ориентированные БД появились в 80-х годах прошлого века, а распространение получили только с приходом концепции NoSQL.
В этом подкасте узнал почему так произошло, какова внутренняя логика в развитии БД, движков хранения, языков запросов.
Интересно было послушать про перспективы развития и о том, какими инструментами пользуются разработчики. И вам рекомендую, котаны.
#podcast #db #nosql
Немного оффтопа про электрокары. Первый электрический автомобиль появился далеко не с выходом Tesla, а полтора века назад — в 1841 году.
В 1899 году электромобиль поставил рекорд в 105 километров в час и проехал 130 километров на одной зарядке.
Но на 100 лет вперёд распространение получили двигатели внутреннего сгорания. И получается, что сейчас Илон Маск развивает давно забытую технологию.
Та же аналогия прослеживается и с базами данных.
Объектно-ориентированные БД появились в 80-х годах прошлого века, а распространение получили только с приходом концепции NoSQL.
В этом подкасте узнал почему так произошло, какова внутренняя логика в развитии БД, движков хранения, языков запросов.
Интересно было послушать про перспективы развития и о том, какими инструментами пользуются разработчики. И вам рекомендую, котаны.
#podcast #db #nosql
❤5
This media is not supported in your browser
VIEW IN TELEGRAM
#статья дня
Я устал сидеть с покерфейсом на собеседованиях фуллстак- и бакенд-лидов, когда коллега начинает спрашивать про работу индексов в системах баз данных и их оптимизации.
Поэтому я решил найти хоть что-то визуальное, чтобы начать вхождение в тему.
И, не поверите, таки нашёл!
Итак, встречайте. Деревья поиска aka B-деревья и их использование в индексах баз данных: https://planetscale.com/blog/btrees-and-database-indexes
Насыщена интерактивными примерами, можно собственноручно подобавлять ключи и увидеть, как именно принимается решение в какую ветку полетит та или иная пара ключ-значение.
Объясняются принципы работы деревьев, принципы их хранения на диске и алгоритмы поиска, например, упорядоченных значений.
Это для многих (включая меня) немножко хард-левел, поэтому на данный момент пост на правах закладки и читаю я его параллельно с Виртом и Википедией.
Но как же красиво, ну.
#algorithms #db #index
Я устал сидеть с покерфейсом на собеседованиях фуллстак- и бакенд-лидов, когда коллега начинает спрашивать про работу индексов в системах баз данных и их оптимизации.
Поэтому я решил найти хоть что-то визуальное, чтобы начать вхождение в тему.
И, не поверите, таки нашёл!
Итак, встречайте. Деревья поиска aka B-деревья и их использование в индексах баз данных: https://planetscale.com/blog/btrees-and-database-indexes
Насыщена интерактивными примерами, можно собственноручно подобавлять ключи и увидеть, как именно принимается решение в какую ветку полетит та или иная пара ключ-значение.
Объясняются принципы работы деревьев, принципы их хранения на диске и алгоритмы поиска, например, упорядоченных значений.
Это для многих (включая меня) немножко хард-левел, поэтому на данный момент пост на правах закладки и читаю я его параллельно с Виртом и Википедией.
Но как же красиво, ну.
#algorithms #db #index
👍27❤1
#статья дня
Все, наверное, знают о том, что существует поведенческий таргетинг — который определяет, какая реклама вам больше интересна.
И под капотом такой системы — полноценная big data-инфраструктура: события пишутся в логи, проходят обработку и попадают в key-value хранилище, откуда их читает рантайм показа рекламы.
Причем система должна работать так надежно, чтобы каждое событие обработалось ровно один раз (exactly-once), и так быстро, чтобы уложиться в миллисекунды на весь цикл.
Как этого добиться — рассказал в статье Руслан Савченко, разработчик динамических таблиц YTsaurus: https://habr.com/ru/companies/yandex/articles/939078/
Из интересного:
— События шардируются по хешу идентификатора. Это гарантирует, что все события одного пользователя обрабатываются одним воркером в рамках локальной транзакции.
— Дошли до низкоуровневой оптимизации аллокатора памяти и работы с ядром Linux, чтобы убрать провалы на высоких перцентилях.
— Вместо перезаписи всего protobuf-профиля система пишет бинарные дельты (через xdelta). Агрегатные колонки накладывают все накопившиеся дельты на оригинальный protobuf — получаем актуальную версию объекта
Все решения, на самом деле, можно применять не только к профилям. Прикольно, что в статье куча графиков — помогают разобраться. Советую почитать на досуге
#highload #db #database
Все, наверное, знают о том, что существует поведенческий таргетинг — который определяет, какая реклама вам больше интересна.
И под капотом такой системы — полноценная big data-инфраструктура: события пишутся в логи, проходят обработку и попадают в key-value хранилище, откуда их читает рантайм показа рекламы.
Причем система должна работать так надежно, чтобы каждое событие обработалось ровно один раз (exactly-once), и так быстро, чтобы уложиться в миллисекунды на весь цикл.
Как этого добиться — рассказал в статье Руслан Савченко, разработчик динамических таблиц YTsaurus: https://habr.com/ru/companies/yandex/articles/939078/
Из интересного:
— События шардируются по хешу идентификатора. Это гарантирует, что все события одного пользователя обрабатываются одним воркером в рамках локальной транзакции.
— Дошли до низкоуровневой оптимизации аллокатора памяти и работы с ядром Linux, чтобы убрать провалы на высоких перцентилях.
— Вместо перезаписи всего protobuf-профиля система пишет бинарные дельты (через xdelta). Агрегатные колонки накладывают все накопившиеся дельты на оригинальный protobuf — получаем актуальную версию объекта
Все решения, на самом деле, можно применять не только к профилям. Прикольно, что в статье куча графиков — помогают разобраться. Советую почитать на досуге
#highload #db #database
❤4👍4🫡3