Рубрика «база данных»

Всем привет. На связи Владислав Родин. В настоящее время я преподаю на портале OTUS курсы, посвященные архитектуре ПО и архитектуре ПО, подверженного высокой нагрузке. В преддверии старта нового потока курса «Архитектор высоких нагрузок» я решил написать небольшой авторский материал, которым хочу поделиться с вами.

Почему может понадобится полусинхронная репликация? - 1


Введение

Из-за того, что на HDD может выполняться лишь порядка 400-700 операций в секунду (что несравнимо с типичными rps'ами, приходящимися на высоконагруженную систему), классическая дисковая база данных является узким горлышком архитектуры. Поэтому необходимо уделить отдельное внимание паттернам масштабирования данного хранилища.

На текущий момент имеются 2 паттерна масштабирования базы: репликация и шардирование. Шардирование позволяет масштабировать операцию записи, и, как следствие, снижать rps на запись, приходящийся на один сервер вашего кластера. Репликация позволяет делать тоже самое, но с операциями чтения. Именно этому паттерну и посвящена данная статья.Читать полностью »

Обезл***вание д***ных — это не просто рандомизация - 1

В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.

Казалось бы, достаточно просто поменять всё на какие-нибудь несимметричные хеши, и всё будет хорошо.

Так вот, не будет.

Дело в том, что база данных банка — это множество связанных между собой таблиц. Где-то они связаны по ФИО и номеру счёта клиента. Где-то по его уникальному идентификатору. Где-то (тут начинается боль) через хранимую процедуру, которая вычисляет сквозной идентификатор на основе этой и соседней таблицы. И так далее.

Обычная ситуация, что разработчик первой версии системы уже десять лет как умер или уехал, а системы ядра, запущенные в старом гипервизоре внутри нового гипервизора (чтобы обеспечить совместимость) ещё в проде.

То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных. Читать полностью »

В Сбербанке снова утечка данных — новая информация о клиентах банка выставлена на продажу - 1

Согласно информации издания «Известия», с 12 февраля 2020 года в даркнете появились новые объявления о продаже базы данных, в каждой строке содержащих такую информацию о клиентах Сбербанка: название банковского подразделения, полное ФИО, номер счета, паспортные данные, дата рождения и номер телефона.
Читать полностью »

Глава Сбербанка назвал себя виноватым в утечке данных клиентов - 1

Президент, председатель правления Сбербанка Герман Греф, Фото: Сергей Фадеичев/ТАСС

Согласно информации агенства «ТАСС», на ежегодной встрече с клиентами премиального сегмента «Сбербанк первый» глава Сбербанка Герман Греф заявил, что считает личной виной утечку данных клиентов Сбербанка.
Читать полностью »

По информации издания «Коммерсантъ», на одном из теневых ресурсов 13 октября 2019 года появилось объявление о продаже персональных данных клиентов Сбербанка на миллион строк, накопленных с 2015 года. В объявлении утверждалось, что база содержит полные данные клиентов банка, имеющих кредиты или кредитные карты: паспорт, прописка, адреса проживания, телефоны, счета, сумма остатка или задолженности. Правда теперь, помимо данных о кредитных картах, к продаже предлагалась еще дополнительная информация о клиентах — выгрузка последнего звонка клиента в банк, причем продавец предлагает покупателю именно запись разговора клиентов с колл-центром финансового учреждения.
Читать полностью »

Сбербанк совместно с правоохранительными органами завершил внутреннее расследование по выявлению канала утечки данных учетных записей по кредитным картам клиентов. Расследование было начато 2 октября, а закончено 4 октября 2019 года. Банк утверждает, что виновный — сотрудник кредитной организации, который руководил сектором в одном из бизнес-подразделений банка и имел доступ к базам данных.

Обновление [на 6.10.19]: добавлена информация о ходе расследования в Сбербанке.
Читать полностью »

Криптовалюты — движущая сила новой золотой лихорадки. Автор предлагает использовать анализ данных для лучшего понимания этого развивающегося рынка.

В последнее время возникает ощущение, будто деньги растут на деревьях.

image

Объемы биржевой торговли достигают миллионов долларов, а рыночная капитализация — миллиардов. Впору говорить о золотой лихорадке, подогреваемой появлением все большего количества новых криптовалют.

Мы живем в эпоху цифровых валют. Появившись менее 10 лет тому назад, концепция криптовалют уже сегодня получила широкое распространение. Несмотря на столь малый срок, на рынке уже существует более тысячи разных криптовалют, а ICO происходят чуть ли не каждый день.
Читать полностью »

Репозитории правил для бизнеса и соответствующих блоков кода, которые встраиваются в продакшн - 1

Вкратце напомню: BRMS, или Business Rule Management System, — это «тяжёлые» системы для крупных и очень крупных компаний, которые содержат все те вещи, которые часто меняются в ИТ. Например, в банке в BRMS лежат чаще всего правила оценки по кредиту и параметры вкладов, в сотовом операторе — тарифы и нюансы вычисления всех списаний, в страховой компании — коэффициенты страхования, поправочные коэффициенты, параметры новых продуктов.

Разница между «вобьём руками» и «вобьём через BRMS» примерно такая: парни из одной страховой компании, где мы внедряли BRMS, оказались одними из немногих по итогам прошлого года, кто показал возможность работать очень гибко и быстро. Обычно внедрение коэффициента со всеми проверками занимает в среднем 2 недели. Здесь же это делается максимум за 2 дня, минимум — за считанные часы. У них есть данные статистики, на которые крайне быстро можно реагировать и перепроверять разные показатели сотни и тысячи раз. В страховании это означает возможность очень детально подстраиваться под текущую ситуацию (регион, банки) и получать куда больше прибыли.

Мы используем BRMS для оценки стоимости ИТ-проекта — она рассчитывается на основе правил вроде «работают сетевики либо программисты» и десятков переменных вроде стоимости часа специалиста.Читать полностью »

Представьте себе компанию «Ингосстрах» с продуктивной базой 30 Тб. Она лежит на большой такой железной хранилке, её обслуживает очень-очень тяжёлый сервер. Всё красиво. Теперь представьте, что вы написали фичу или кусок функционала, и вам нужно протестировать её на боевой базе. Кусочек базы отщипнуть нельзя по ряду причин.

Что вы сделаете? Ну, традиционный путь — взять ещё одну хранилку на 30–35 Тб (но подешевле раз в пять, помедленнее, попроще, без резервирования) и отреплицировать базу на неё. А затем работать с копией. Хороший план?

Нет. Дело в том, что когда у вас несколько команд разработки (а в нашем случае их количество выросло от 4 до 10), нужно, соответственно, от 4 до 10 тестовых площадок. Или даже больше. Покупать такое железом просто нереально, поэтому нужно решение, которое позволит один раз реплицировать боевую базу, а затем «показывать» её каждому серверу как отдельную тестовую, но храня все изменения тестовой площадки. Вот так:

«Пьяная» база данных: как на 1 базе мы сделали 7 тестовых площадок, причём у каждой — свой собственный инкремент и дифф - 1

Расскажу, как на одном узле с физической базой мы развернули 7 тестовых площадок, изолированных друг от друга. Читать полностью »

Надо “SELECT * WHERE a=b FROM c” или “SELECT WHERE a=b FROM c ON *” ?

Если вы похожи на меня, то согласитесь: SQL — это одна из тех штук, которые на первый взгляд кажутся легкими (читается как будто по-английски!), но почему-то приходится гуглить каждый простой запрос, чтобы найти правильный синтаксис.

А потом начинаются джойны, агрегирование, подзапросы, и получается совсем белиберда. Вроде такой:

SELECT members.firstname || ' ' || members.lastname
AS "Full Name"
FROM borrowings
INNER JOIN members
ON members.memberid=borrowings.memberid
INNER JOIN books
ON books.bookid=borrowings.bookid
WHERE borrowings.bookid IN (SELECT bookid
  FROM books
  WHERE stock>(SELECT avg(stock)
    FROM books))
GROUP BY members.firstname, members.lastname;

Буэ! Такое спугнет любого новичка, или даже разработчика среднего уровня, если он видит SQL впервые. Но не все так плохо.

Легко запомнить то, что интуитивно понятно, и с помощью этого руководства я надеюсь снизить порог входа в SQL для новичков, а уже опытным предложить по-новому взглянуть на SQL.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js