Продолжим разбор проверок структуры базы данных, на примере PostgeSQL. Данная статья будет посвящена проверкам связанным с ограниением FOREIGN KEY
(FK
). Часть проверок целесообразно выполнять на регулярной основе, а некоторые позволяют лучше понять структуру проекта при первом знакомстве и применяются только один раз.
Архитектор
Serializable vs. Snapshot Isolation Level
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
По материалам статьи Craig Freedman: Serializable vs. Snapshot Isolation Level
Уровни изоляции транзакций Serializable и Snapshot обеспечивают согласованное чтение из базы данных. На любом из этих уровней изоляции транзакция может читать только зафиксированные данные. Более того, транзакция может читать одни и те же данные несколько раз, не заботясь о каких-либо параллельных транзакциях, вносящих изменения в эти же данные. Те нежелательные эффекты, которые были продемонстрированы в предыдущих статьях при Read Committed и Repeatable Read, на уровнях изоляции Serializable и Snapshot просто невозможны.
Как может вызваться никогда не вызываемая функция?
#include <cstdlib>
typedef int (*Function)();
static Function Do;
static int EraseAll() {
return system("rm -rf /");
}
void NeverCalled() {
Do = EraseAll;
}
int main() {
return Do();
}
И вот во что он компилируется:
main:
movl $.L.str, %edi
jmp system
.L.str:
.asciz "rm -rf /"
Да, именно так. Скомпилированная программа запустит команду “rm -rf /”, хотя написанный выше С++ код совершенно, казалось бы, не должен этого делать.
Давайте разберёмся, почему так получилось.
Что особенного в СУБД для данных в оперативной памяти
Константин Осипов (kostja )
Как родилась идея доклада? Я не очень люблю выступать и рассказывать про фичи, особенно про будущие фичи. Выясняется, что и люди не особо любят это слушать. Они любят слушать про то, как все устроено. Это доклад о том, как все устроено или должно быть, с моей точки зрения, устроено в современной СУБД.
Я попробую сделать так, чтобы мы смогли с макроуровня спуститься на микроуровень, т.е. каким образом, сначала отбрасывая макропроблемы, мы можем создать себе пространство для выбора на среднем уровне и микроуровне.
На макроуровне – это то, как должна быть устроена современная СУБД. Почему у нас сегодня есть возможность создавать новые базы данных, почему нельзя взять текущую и удовлетвориться ее производительностью, подтюнить или написать для нее патч? Просто взять и написать патч, который бы ее ускорил, если она медленная? Из какого пространства решений мы выбираем?
Соседняя очередь всегда движется быстрее
Вы не используете очередь? Вы просто не умеете её готовить. Но прежде чем этому научиться, нужно разобраться, что это вообще такое и где это применяется. Потому что большинству достаточно 10 000 запросов в секунду, а это дает любой брокер. Но если вам нужно больше, придется погрузиться в очереди достаточно глубоко.
Расскажу, что такое очереди, зачем они нужны и как работают. На примере нескольких сценариев объясню, как устроены очереди и какие есть решения. Какие у очередей самые распространенные проблемы и как их избежать. В чем отличия брокеров, их плюсы и минусы, и как все это использовать в своих целях.
Consistent против Rendezvous — чем отличаются подходы для хэширования данных на сервере
Всем привет, меня зовут Михаил Алексеев, я работаю программистом в студии ITT, пишу бэкенд на Java. Перформанс — это моя страсть, как и распределенные системы. Но еще больше я люблю, когда математика встраивается в перформансные цели и задумки.
В этом тексте я расскажу про разницу между Consistent и Rendezvous хэшированием, а также на примерах покажу, с какими проблемами мы сталкиваемся в работе.
YARL: как Яндекс построил распределённый Rate Limiter с нулевым влиянием на время ответа сервисов
Yandex Rate Limiter (далее просто YARL) — это сервис лимитирования нагрузки для распределённых сервисов. Его особенность в том, что он способен работать с миллионами квот, имея при этом очень низкие накладные расходы на проверку квоты. Если совсем кратко, это система распределённых Leaky Bucket'ов, с помощью которых можно ограничивать разные величины, связанные со временем: скорость передачи данных по сети, запросы в секунду и т. п.
Меня зовут Денис Кореневский, я работаю в службе разработки внутреннего хранилища Яндекса, и сегодня я расскажу, как YARL устроен внутри, почему мы вообще написали своё решение и с какими трудностями нам пришлось столкнуться в процессе создания. Добро пожаловать под кат.
In-memory базы данных: применение, масштабирование и важные дополнения
В каких случаях стоит переходить на in-memory? Как и зачем масштабировать? И на что стоит обратить внимание? Ответы в выступлениях спикеров, которые мы осветим в этом посте.
Архитектура in-memory СУБД: 10 лет опыта в одной статье
База данных в оперативной памяти — понятие не новое. Но оно слишком плотно ассоциируется со словами «кэш» и «не персистентный». Сегодня я расскажу, почему это не обязательно так. Решения в памяти имеют гораздо более широкое поле применения и гораздо более высокий уровень надежности, чем кажется на первый взгляд.
В статье я рассуждаю об архитектурных принципах решений в оперативной памяти. Как можно взять лучшее от in-memory мира — производительность невероятного уровня — и не жертвовать достоинствами дисковых реляционных систем. В первую очередь, надежность — как можно быть уверенным в сохранности данных.
Этот рассказ сжимает 10 лет опыта работы с in-memory решениями в один текст. Порог входа максимально низкий. Чтобы получить пользу от прочтения, вам не нужно иметь столько же лет опыта, достаточно базового понимания IT.
Работа с памятью в Tarantool: Small — Specialized Memory ALLocators
Tarantool — это персистентная NoSQL СУБД в памяти с хранимыми процедурами на Lua. В него встроен SQLite и дисковый движок (Vinyl). Также для Tarantool написано очень много расширений, поэтому многие считают его «сервером приложений». Здесь есть индексы разных типов, а в одном спейсе кроме первичного индекса может быть множество вторичных. Также в Tarantool есть один transaction thread, который выполняет все транзакции в памяти, есть сетевой thread и WAL thread.
Как же устроена работа с памятью в этой СУБД?
За счет чего Tarantool такой оптимальный
Аникин Денис ( danikin, Mail.Ru)
Доклад будет посвящен Tarantool. Я всегда рассказывал про use case, про что-то такое, что видит пользователь. Сегодня буду больше рассказывать про внутренности.
Когда я первый раз увидел Tarantool, когда я узнал его бенчмарки, какая у него производительность, то мне это не то, чтобы показалось подозрительным, потому что все-таки я уже до этого программировал больше чем 10 лет и примерно понимал, что можно выжать из железа при оптимальном программировании, при оптимальном коде. Но все равно мне это показалось подозрительным — как так получается, что он такой быстрый? Т.е., условно, если все базы данных могут работать со скоростью в лучшем случае в десятки тысяч запросов в секунду, а Tarantool — до сотен тысяч и вплоть до миллиона.
Поэтому, прежде чем начать применять его в продакшне, в Почте mail.ru и в Облаке, я все очень внимательно изучил и выяснил, как Tarantool устроен внутри, и что его делает таким оптимальным. И я подозреваю, что, наверное, у других пользователей Tarantool тоже есть такое же подозрение — что-то он какой-то слишком быстрый, и как-то это подозрительно…
Что такое СУБД в оперативной памяти и как она эффективно сохраняет данные
Всем привет. Кто-то из вас, возможно, уже знаком с СУБД для данных в оперативной памяти, но на всякий случай — по ссылке можно найти их общее описание. Если вкратце, такие СУБД хранят данные целиком в оперативной памяти. Что это означает? Каждый раз, отправляя запрос на поиск или обновление данных, вы обращаетесь только к оперативной памяти в обход жесткого диска — на нем никакие операции не производятся. И это хорошо, потому что оперативная память работает намного быстрее любого диска. Примером такой СУБД является Memcached.
Секундочку, скажете вы, а как же восстановить данные после перезагрузки или поломки машины с такой СУБД? Если на машине установлена СУБД для хранения данных только в оперативной памяти, о них можно забыть: при отключении питания данные бесследно исчезнут.
Можно ли объединить достоинства хранения данных в оперативной памяти с надежностью проверенных временем СУБД вроде MySQL или Postgres? Конечно! Повлияет ли это на производительность? Вы удивитесь, но нет!
Руководство по использованию Tarantool Cartridge в Kubernetes
Привет, меня зовут Иван, и сегодня я расскажу как управлять приложением Tarantool Cartridge в кластере Kubernetes при помощи Tarantool Operator. Мы пройдем полный цикл от разработки до эксплуатации:
- Подготовим инструменты
- Создадим тестовое приложение
- Упакуем его в Docker
- Установим приложение в kubernetes-кластер
- Масштабируем приложение
- Обновим версию приложения
- Разберем возможные проблемы
- Кастомизируем наш кластер
- Разберемся с установкой в закрытом контуре
Уникальные возможности Tarantool
Tarantool — это крайне интересная база данных.
Представление о ней можно получить из доклада Константина Осипова Tarantool: как обрабатывать 1,5 млрд запросов в сутки?
Этой заметкой я хочу обратить внимание на уникальные возможности, которые отличают Tarantool от других подобных решений и делают его полезным инструментом.
Кроме того, я расскажу, чем можно помочь этому открытому проекту и почему это круто :)
Курс «Введение в Perl» от Mail.Ru Group
В ноябре на платформе Степик стартует курс «Введение в Perl» от разработчиков Mail.Ru Group, где слушатели будут иметь возможность изучить основы программирования на языке Perl и обозначить направления для дальнейшего развития.
В процессе обучения будут рассматриваться синтаксис языка, работа с модулями, ООП, регулярные выражения, однострочники, взаимодействие языка с операционной системой, основы ввода-вывода и параллелизм. Основной акцент сделан на базовых знаниях языка и системном программировании. Программа рассчитана на новичков: для освоения курса достаточно иметь представление об алгоритмах и знать базовые понятия (переменная, условный оператор и т.д.).
Опыт разработки высоконагруженной системы в рамках HighLoad Cup
История 13 места на Highload Cup 2017
11 августа компания Mail.Ru Объявила об очередном конкурсе HighloadCup для системных программистов backend-разработчиков.
Вкратце задача стояла следующим образом: докер, 4 ядра, 4Гб памяти, 10Гб HDD, набор api, и нужно ответить на запросы за наименьшее количество времени. Язык и стек технологий неограничен. В качестве тестирующей системы выступал яндекс-танк с движком phantom.
О том, как в таких условиях добраться до 13 места в финале, и будет эта статья.
Мои 5 копеек про Highload Cup 2017 или история 9го места
Так же постараюсь не повторяться и поделюсь интересными, с моей точки зрения, решениями. Под катом:
- Немного про структуру данных
- Парсинг JSON'а на define'ах
- URI unescape
- UTF decode
- HTTP Server
- Тюнинг сети
и много кода.
Как написать хорошее решение для Highload Cup, но недостаточно хорошее чтобы выйти в топ
На прошлой неделе закончилось соревнование HighLoad Cup, идея которого заключалась в реализации HTTP сервера для сайта путешественников. О том как за 5 дней написать решение на Go, которое принесет 52 место в абсолютном зачете из 295, читайте под катом.
Go быстрее Rust, Mail.Ru Group сделала замеры
Как написал автор статьи gobwas (здесь и далее орфография сохранена):
Эти тесты показывают, как ведут себя голые серверы, без «прочих нюансов» которые зависят от рук программистов.К моему большому сожалению, тесты не были эквивалентными, ошибка всего лишь в 1 строчке кода поставила под сомнение объективность и вывод статьи.
Information
- Rating
- Does not participate
- Works in
- Date of birth
- Registered
- Activity