Базы данных *

В продолжении предыдущего поста. Получены интересные результаты значений коэффициента корреляции между:

1. Количество событий ожидания и показателем производительности СУБД

2. Количество соединений с конкретного ip и показателем производительности СУБД

Отрицательная корреляция между количеством событий ожидания и показателем производительности СУБД в результате оказалась очень слабая:

IO ControlFileSyncUpdate -0,155750768

Client ClientWrite -0,132699875

LWLock XactSLRU -0,123296926

...

Отрицательная корреляция между количеством соединений с конкретного ip и показателем производительности СУБД - умеренная:

XX.XXX.XXX.1 -0,43280346

XX.XXX.XXX.2 -0,41262827

XX.XXX.XXX.3 -0,409033529

XX.XXX.XXX.4 -0,388472

XX.XXX.XXX.4 -0,376145747

...

Теперь начинается самое интересно - сбор статистики наблюдений и интерпретация результатов корреляционного анализа .

SQL vs NoSQL: как выбрать архитектуру БД для мобильного приложения

SQL (Structured Query Language) — это язык запросов, которые мы используем для работы с реляционными базами данных. У таких БД жесткая структура в виде таблиц. Вся информация там хранится в столбцах и строках. Структурированность — одно из главных преимуществ SQL баз данных.

NoSQL — нереляционные БД, у них нет жесткой структуры. Скажем, у нас есть класс — пользователи. У каждого из них есть ID, имя, фамилия и проч. Эти данные помещаются в отдельный файл (а не в таблицу), и взаимодействие происходит только с этим файлом. Вы уже не можете забрать какое-то одно поле и работаете только с этим классом.

Чтобы выбрать между SQL и NoSQL, нужно исходить из задач бизнеса.

• Если вы делаете маленькое приложение на узкую аудиторию или MVP, можно смело выбирать NoSQL. Такие базы быстрые, с ними проще работать, они легко масштабируются. А если проект растет как на дрожжах — NoSQL можно быстро переписать на SQL.

• Если вы делаете средний по объему проект, лучше SQL. Хотя, если очень хочется, можно и NoSQL. Но тут есть особенности: выбирайте NoSQL, только если у вас есть налаженные ивенты, налаженная имплементация баз данных и опыт работы с NoSQL.

• Если вы делаете энтерпрайз, лучше выбрать SQL. Представим, что в каком-то крупном маркетплейсе 10 тысяч человек оплатили покупки, но не получили товары, потому что транзакция данных прошла некорректно. Цена ошибки тут слишком высока — поэтому SQL.

Больше подробностей — в нашем блоге.

ГАС Правосудие взломали. В Багдаде всё спокойно.

На моей практике возникла весьма интересная ситуация, связанная с тем, как дело в районном суде могут отдать нужному судье, а затем просто "потерять" из статистики и учёта в апелляции и кассации. И всё это связано с работой в АИС, ГАС или тем, что объединено под названием ГАС "Правосудие".

И так. Решив всё же описать ситуацию, я с огромной долей вероятности предполагаю, что подобные технические манипуляции с ГАС Правосудие, АМИРС, МРД и прочими многочисленными и таинственными составляющими электронного правосудия в России, позволяют успешно "решать вопросы" по заказу (по звонку или как там ещё было когда-то принято).

Связано это с уникальным идентификатором дела (УИД), который был введён в 2019 для привязки всех производств к единому номеру, с целью контроля и учёта.

В районном суде делу в 2021-м году был присвоен "УИД 0". Дело с номером "2-...". Модулем автораспределения (МРД) не пользовались. Протокола распределения нет. Клиент не заметил этого, прошёл апелляцию и кассацию (безуспешно и очень удивительно, что там не заметили нарушение).

Но! Самое интересное. В ВС РФ (Верховный Суд Российской Федерации) жалобе присвоили УИД от другого дела, не имеющий к нашему делу никакого отношения. Как?

Видимо это нормальная практика, когда Верховный Суд РФ, не имея возможности просто проставить "0" в системе в поле УИД, присваивает производству какой-то левый номер?

Сталкивались ли вы с такими казусами, и есть ли в таких трюках состав 274 УК РФ?

Или я плохо ищу или действительно , тема корреляционного анализа производительности СУБД , еще не исследовалась.

Например было бы очень интересно установить - какой из факторов оказывает максимальное влияние на производительность СУБД или наоборот - как производительность СУБД влияет на показатели СУБД и инфраструктуры :

• Количество соединений

• Утилизация CPU

• Утилизация RAM

• Утилизация I/O

• Количество ожиданий СУБД

• Показатели CPU (iowait и т.п)

• Показатель Cache Hit Ratio

• Объем обработанных блоков shared_buffer

• Что-то еще из огромного списка метрик

Google Firebase сдался и добавил в свои сервисы SQL базу данных (облачную PostgreSQL) в форме Firebase Data Connect.

Пока в виде preview сервис можно попробовать бесплатно. Потом собираются брать плату и за саму базу, и за API доступа к ней.

Вряд ли Google с такими политиками сможет конкурировать с Supabase.На данный момент это две основные площадки, с которыми фронтендер или мобильный разработчик может без излишних усилий сделать удобный облачный бэкенд, как без логики (просто CRUD доступ), так и с ней (Functions), и оставаясь в рамках стандартов (не сильно привязываясь к проприетарным решениям сервисов).

Всем привет! Мы продолжаем обзор Redis — системы хранения данных в виде структур. 

Новая статья Петра, нашего DevOps-инженера, — это детальное руководство по базовой репликации Redis. Благодаря ему вы сможете настроить эту СУБД на высокий уровень отказоустойчивости. 

Если суперкратко:

• Репликация в Redis ассинхронна. 

• Репликация не блокируется на стороне мастера. 

• Репликация (почти) не блокируется на стороне слейвов. 

• У мастера может быть любое количество реплик.

• Каждый слейв может выступать мастером для другого инстанса.

А ещё в конце вас ждёт приятный бонус в виде разбора атаки на Redis через H2Miner, из-за которой можно полностью потерять данные на инстансе Redis

Нажмите сюда, что начать читать.

Команда проекта MariaDB сообщила, что MariaDB Server 11.4 будет выпускаться с долгосрочной поддержкой (LTS).

В начале февраля разработчики объявили, что корректируют модель выпуска MariaDB Server. В рамках этого мероприятия они запланировали выпуск в рамках LTS MariaDB Server 11.7, которая планируется к выпуску в январе 2025 года.

«Чтобы наши текущие функции раньше стали широко использоваться, мы решили добавить MariaDB Server 11.4 в LTS, чтобы удовлетворить потребности пользователей MariaDB 11, ожидающих полных пяти лет исправлений ошибок в выпуске с заблокированным набором функций», — пояснили разработчики проекта.

Скидка 20% на комплект сервисов ⚡

Managed Kubernetes, облачные базы данных и объектное хранилище S3.

Запускайте и развивайте веб-проекты любой сложности с помощью отказоустойчивых и масштабируемых сервисов Selectel. До 30 июня подключите три сервиса: Managed Kubernetes, облачные базы данных и объектное хранилище S3 — и пользуйтесь ими со скидкой 20%.

Оплачивайте Managed Kubernetes, базы данных и хранилище по модели pay-as-you-go. Скидка действует в течение всего времени, пока вы используете комплект сервисов.

Как получить скидку?

1️⃣Зарегистрируйтесь в панели управления.

2️⃣Подключите Managed Kubernetes, облачные базы данных и объектное хранилище в подходящих вам конфигурациях.

3️⃣Оставьте заявку в тикет-системе. Напишите, что участвуете в этой акции, и укажите примерную сумму, которую планируете тратить на каждый сервис

4️⃣Дождитесь ответа от поддержки и пользуйтесь сервисами с ежемесячной скидкой 20%.

Подключайте сервисы со скидкой →

Состоялся релиз мажорной версии открытого масштабируемого решения для кластеризации баз данных MySQL — Vitess 19. Исходный код проекта опубликован на GitHub под лицензией Apache License 2.0.

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

Изменения и дополнения в Vitess 19:

• прекращение поддержки MySQL 5.7. Разработчики советуют пользователям выполнить обновление до MySQL 8.0, используя Vitess 18, прежде чем переходить на Vitess 19. Однако Vitess 19 по-прежнему будет поддерживать импорт из MySQL 5.7;

• добавлены новые метрики для консолидации потоков и версия сборки в /debug/vars, чтобы обеспечить более глубокое понимание и отслеживаемость;

• улучшена совместимость запросов, реализована поддержка операций удаления из нескольких таблиц, новый запрос SHOW VSCHEMA KEYSPACES и несколько других улучшений синтаксиса SQL, которые расширяют совместимость Vitess с MySQL;

• поддержка отсрочки попыток переключения в случае блокировки. Поддержка принудительного отключения;

• улучшение процесса инкрементного резервного копирования: поддержка имён резервных копий и пустых резервных копий.

«Следуя тенденции последних трёх лет, новая версия Vitess быстрее предыдущей во всех тестах, которые мы отслеживаем в Arewefastyet. Мы исправили несколько проблем с производительностью, доработали интерфейс и код», — пояснили разработчики, порекомендовав изучить документацию проекта и список исправлений.

Сегодня DataBanksy побывал на онлайн мероприятии ребят из Analytics Workspace. По сути это компания из портфеля проектов Барс, там же, кстати, и альфа BI. Цель онлайн встречи - подвести итоги хакатона и рассказать о своей дорожной карте. В жюри позвали ребят из тусовки Russian BI Chat.

Если сделать короткое заключение, то:

1. Дорожная карта есть, она краткосрочная. Все, что в долгосроке находится под грифом секретно со слов вендора.

2. Идут в сторону self service. Под капотом апач линейка. Пытаются решить проблему с гибкими фильтрами, это кстати в качестве большого минуса отметил и клиент-спикер. Фильтры - это задача #1, исходя из объема информации от вендора. Интересно, смогут ли победить болезнь…

3. Будут добавлять новые виджеты, делать дашборды под разные экраны (автоматом не масштабируется сейчас), пользовательские представления и другое.

4. Отдельно рассказали о развитии ETL. Третий вендор который осознал, что нужно делать коннектор к Qvd, формат внутренней хранилки Qlik Sense. Понравилась идея с ETL Store, где можно делать свои блоки и делиться ими. Интересно будет посмотреть на работу отладчика с автоматическим поиском ошибок и выдачей рекомендаций.

5. Не очень выглядел пассаж про работу со 150 млрд записей в неком ритейлере под нагрузочные тесты, как единственный вендор в РФ с такими метриками. Если речь шла про некий direct query, то так и говорите об этом. Дашборд на 150 млрд записей на одной ноде представить не можем!

6. Пицца dashboard win!

Добавили AW к себе в поле зрения.

​​Увеличили производительность облачных баз данных ?

Чтобы вы могли выжать максимум из облачных баз данных, мы прокачали их еще сильнее, а именно: 

? увеличили параметры IOPS в 3,5 раза (до 90 000 IOPS).

? и пропускной способности — в 2,5 раза (до 1 000 МБ/c на нашем железе).

Эти параметры уже доступны в панели управления. Чтобы применить их, запустите БД с нуля или пересоздайте кластер. 

Нужно еще больше?
По запросу через тикет можем увеличить: 

? IOPS — до 120 000.

? пропускную способность — до 1 200 МБ/с.

Создайте облачную базу данных в Selectel, чтобы получить быстро работающее приложение даже в периоды максимальной нагрузки ➡️

Компания «Скала^р» заявила о выпуске новой версии программного обеспечения ПАК «Машина баз данных Скала^р МБД.П». «Машина баз данных Скала^р МБД.П» представляет собой программно‑аппаратный комплекс (ПАК) для обработки и хранения данных, предназначенных для работы СУБД PostgreSQLв высоконагруженных системах. Об этом рассказали информационной службе Хабра в пресс‑службе «Скала^р».

В новой версии ПАК  от «Скала^р»:

• пиковая производительность возросла на 60% и превышает 65 тысяч транзакций в секунду;

• обеспечена работа баз данных ёмкостью до 150 ТБ;

• увеличена в два раза поддержка соединений;

• снижена удельная стоимость транзакции до 35%; 

• обновлена система управления кластерами в составе, что высвобождает до 50% времени администраторов СУБД;

• добавлена улучшенная системы мониторинга для СУБД Postgres Pro Enterprise, с детальными диаграммами и новыми возможностями контроля состояния репликации и отказоустойчивости;

• использованы для повышения уровня кибербезопасности сертифицированные ФСТЭК версии операционных систем AltLinux 8 СП p10 и СУБД Postgres Pro Enterprise 15;

• реализована ролевой модели доступа и интеграции с внешними системами аутентификации.

Мы решили запустить проект по очистке BI игроков от лишнего маркетинга. Мы не будем глубоко расписывать плюсы платформ и наличие фичей, постараемся сосредоточиться на минусах с точки зрения бизнес-пользователя, ИТ сотрудника и безопасника.

Наша цель - акцентировать внимание вендоров на закрытие этих минусов. Рынок должен получать качественный отечественный продукт в понятные рынку сроки.

В наше поле зрение в этом году попадут такие платформы, как: Форсайт, Luxms, Alfa BI, Analytics Workspace, PIX BI, Visiology 3, Insight, Yandex DL, Modus.

Графика выпуска постов у нас не будет, мы постараемся делать один обзор в месяц, может быть чаще. Сейчас в нашей команде есть достаточное количество экспертов, которые знают эти продукты и/или имеют доступ к экспертам, которые очень хорошо знают эти платформы изнутри. Естественно, все это DataBanksy, никаких имен, только выводы и факты.

Как мы будем собирать информацию? Митапы, конференции, вебинары, телеграмм каналы, общение с клиентами, личный опыт, отзывы в интернет, мнения конкурентов, мнения экспертов, рейтинги и т. п. Источников достаточно для того, чтобы сделать определенные выводы. Можно написать нам и прислать свою точку зрения, мы постараемся ее учесть. Ну и контрольная закупка, будте готовы к этому господа вендоры?

Материальное вознаграждение нам не интересно. Наша цель - сделать мир BI прозрачным для Вас! Проведем очистку данных о вендорах 2024!

3, 2, 1 начинаем…

Хабр, привет!

Хотим напомнить, что сегодня в 11:00 МСК у нас пройдет вебинар «Управление базами данных в Greenplum: мониторинг и удаление мусора». Расскажем, как правильно собирать и удалять мусор в реляционных СУБД вообще и в Greenplum в частности.

?‍? Спикеры:

Алексей Пономаревский, ведущий администратор БД ITSumma
Иван Хозяинов, руководитель направления больших данных ITSumma

? О чём:

Вакуумирование данных и для чего оно нужно
Инструменты и специфика вакуумирования в Greenplum
Мониторинг раздутых таблиц и стратегии вакуумирования
Решения и практики, которые минимизируют возможные проблемы

Регистрация: https://clck.ru/38NWH7

В прошлом посте я показывал, один из вариантов бессмысленного усложнения запроса использованием CASE, сегодня - продолжение.

Тут представлена попытка заNULLить значение, если оно равно чему-то.

Но ведь в PostgreSQL есть функция nullif, которая делает ровно то же самое:

NULLIF(значение1, значение2)

Функция NULLIF выдаёт значение NULL, если значение1 равно значение2; в противном случае она возвращает значение1. Это может быть полезно для реализации обратной операции к COALESCE. В частности, для примера, показанного выше:

SELECT NULLIF(value, '(none)') ...

В данном примере если value равно (none), выдаётся null, а иначе возвращается значение value.

То есть в примере выше стоит переписать короче и понятнее:

, nullif(sdate, '1900-01-01') sdate
, nullif(mdate, '1900-01-01') mdate

В своей лекции про "сложные" SELECT я уже рассказывал про возможности оператора CASE, а еще раньше - про возможности оптимизации выполнения запросов с его помощью.

Но иногда он вовсе не нужен! Обратите внимание на картинку сверху...

Посмотрим на использованный тут синтаксис CASE:

CASE
  WHEN условие THEN результат
  [WHEN ...]
  [ELSE результат]
END

Или еще конкретнее:

CASE
  WHEN условие THEN TRUE -- [условие IS TRUE]
  ELSE FALSE             -- [условие IS FALSE, IS NULL]
END

Хм... То есть результат этого CASE эквивалентен значению условия с точностью до NULL!

При обращении условия в NULL такой CASE вернет FALSE, но этого же поведения можно добиться с помощью coalesce:

coalesce(условие, FALSE)

Но если мы говорим о конкретном примере с условием EXISTS, то уж оно-то точно никак не может принимать значение NULL! Значит, coalesce-обертка нам тут не требуется и эту часть запроса можно сократить до одного лишь условия, без всяких CASE:

EXISTS(
  SELECT
    NULL
  FROM
    _inforg20687 t15
  WHERE
    t15._fld1329 = 0::numeric AND
    t15._fld20688rref = t6._idrref AND
    t15._fld20689_type = '\\010'::bytea AND
    t15._fld20689_rtref = '\\000\\000\\001\\010'::bytea AND
    t15._fld20689_rrref = t4._fld6883rref
)

В общем, пишите меньше SQL-кода - и ваши запросы "будут мягкими и шелковистыми"!

Портал DB-Engines обновил рейтинг популярности СУБД и присудил звание СУБД 2023 года проекту PostgreSQL, который за год продемонстрировал наибольших рост популярности из 417 отслеживаемых систем. Второе место досталось облачной платформе Databricks (за год поднялась с 19 на 17 место), а третье место занял движок Google BigQuery (поднялся с 21 на 19 место).

Ранее PostgreSQL уже признавался СУБД года в 2020, 2018 и 2017 годах. В 2022 году и 2021 году это звание было закреплено за СУБД Snowflake, а в 2019 его получило MySQL, в 2016 - Microsoft SQL Server, в 2015 - Oracle, в 2013 и 2014 годах - MongoDB.

По методике расчёта рейтинг СУБД напоминает рейтинг языков программирования TIOBE и учитывает популярность запросов в поисковых системах, число результатов в поисковой выдаче, объём обсуждений на популярных дискуссионных площадках и в соцсетях, число вакансий в агентствах по найму персонала и упоминаний в профилях пользователей.

Что касается распределения СУБД в рейтинге, PostgreSQL продолжает занимать 4 место, несмотря на наибольший во всем рейтинге рост популярности - 34.11 балла. Рост популярности также демонстрирует проект Databricks и Snowflake. C 8 на 7 место поднялось решение Elasticsearch, а с 33 на 29 - СУБД Firebird, c 44 на 37 - ClickHouse, с 62 на 50 - Prometheus, с 48 на 42 - OpenSearch, с 85 на 76 - TimescaleDB.

Значительное снижение популярности в 2023 году наблюдается у MySQL, Microsoft SQL Server, MongoDB, Redis и SQLite.

Источник: OpenNET.

В инфраструктуре компании MongoDB, развивающей одноимённую документо-ориентированную СУБД и облачный сервис MongoDB Atlas, выявлены следы взлома.

Судя по уведомлениям администрации проекта, направленным многим клиентам компании, злоумышленники на некоторое время смогли получить доступ к части корпоративных IT-систем, на которых, среди прочего, были размещены сведения об учётных записях клиентов и контактные данные пользователей. Свидетельств, указывающих на то, что атакующие получили доступ к данным, хранимым пользователями в облачном сервисе MongoDB Atlas, на текущем этапе разбирательства инцидента не было выявлено.

Вредоносная активность была обнаружена вечером 13 декабря, после чего неавторизованный доступ извне был пресечён, а также был начат процесс разбора инцидента ИБ. В течение какого времени атакующие имели доступ к инфраструктуре, не сообщается. Также администрацией проекта не упоминается, насколько атака затронула IT-системы, связанные с разработкой СУБД MongoDB.

Пользователям облачных сервисов MongoDB рекомендуется включить двухфакторную аутентификацию для защиты данных и своих аккаунтов.

Не исключено, что полученные в ходе атаки данные могут использоваться для фишинга и целевых атак с использованием методов социального инжиниринга.

Источники: Bleeping Computer, OpenNET, X (Twitter).

Если вдруг вам понадобилось базу IP2Location перевести из DECIMAL-представления IP-адресов в "родной" для PostgreSQL тип inet, то для IPv4-адресов все будет тривиально:

'0.0.0.0'::inet + ipnum::bigint

А вот для преобразования числа к формату IPv6-адреса придется проявить немного изобретательности:

• "математически" разбиваем число на 8 двухбайтовых сегментов по (2 ^ 16) ^ i

• каждое значение преобразуем в шестнадцатиричную систему счисления и добиваем лидирующими нулями

• склеиваем сегменты через двоеточие и кастуем к inet

array_to_string(ARRAY(
  SELECT
    lpad(to_hex(trunc(
      ipnum % (2::numeric(39,0) ^ ((i + 1) * 16)) / (2::numeric(39,0) ^ (i * 16))
    )::integer), 4, '0')
  FROM
    generate_series(7, 0, -1) i
), ':')::inet

В принципе, после этого мы можем "свернуть" ip_from и ip_to в подсеть, не обращая внимания на исходный формат:

inet_merge(ip_from, ip_to) subnet

А если проиндексируем эти подсети с помощью gist...

CREATE INDEX ON country_inet USING gist(subnet inet_ops);

... то сможем по индексу быстро определять принадлежность произвольного IPv4/IPv6-адреса подсетям с помощью соответствующих операторов примерно таким запросом:

SELECT
  *
FROM
  country_inet
WHERE
  subnet >> '8.8.8.8' AND
  country <> '-'
ORDER BY
  masklen(subnet) DESC
LIMIT 1;

❓100 Вопросов по Машинному обучению (Machine Learning) - Вопрос_10

?Вопрос_10: Что такок Tarantool и как он устроен ? (Часть_3)

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

2. Разрешение конфликтов: Tarantool предоставляет механизм разрешения конфликтов при работе с репликацией и шардингом. Возможности разрешения конфликтов включают автоматическое разрешение конфликтов на основе временных меток и возможность управления конфликтами пользовательским кодом.

t.me/DenoiseLAB (Еесли вы хотите быть в курсе всех последних новостей и знаний в области анализа данных)