Базы данных *

Компания «Скала^р» заявила о выпуске новой версии программного обеспечения ПАК «Машина баз данных Скала^р МБД.П». «Машина баз данных Скала^р МБД.П» представляет собой программно‑аппаратный комплекс (ПАК) для обработки и хранения данных, предназначенных для работы СУБД 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 (Еесли вы хотите быть в курсе всех последних новостей и знаний в области анализа данных)

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

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

✔️Ответ: Tarantool — это база данных с открытым исходным кодом и высокой производительностью, которая сочетает в себе функциональность базы данных и сервера приложений. Tarantool состоит из:

1. In-Memory и Disk Storage: Tarantool предлагает возможность хранения данных как в оперативной памяти (In-Memory), так и на диске (Disk Storage). Это позволяет обеспечить высокую скорость доступа к данным и сохранить данные на долгосрочное хранение.

2. Lua: Tarantool использует язык программирования Lua для создания хранимых процедур (stored procedures), триггеров и бизнес-логики. Lua обеспечивает гибкость и простоту внедрения пользовательского кода в базу данных.

3. NoSQL и Lua Spaces: Tarantool поддерживает гибкую модель данных, известную как Lua Spaces. Lua Spaces предоставляет простой способ хранения и извлечения данных, а также мощные возможности индексирования и поиска.

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

Недавно к нам обратился клиент, у которого потенциально 2 млн пользователей и ему нужно разработать стриминговый сервис, где 10К-20К пользователей могут смотреть медиа-контент в разрешении 4К онлайн.

Фильм 4К весит 5 гб, если 10К пользователей одновременно его смотрят, то это большая нагрузка на хранилище данных. Сложность в том, чтобы сбалансировать трафик на сервис, чтобы система не перегружалась, а пользователи не испытывали дискомфорта.

Чтобы этого добиться, нужно написать ПО таким образом, чтобы плеер или серверная часть отдала контент порционным пользователям. Так мы распределим нагрузку.

Для хранения контента на 2 млн человек, потребуется от 300-400 ТБ устойчивого хранилища. Нужно построить системы хранения данных.

Нужна защита хранилища, если какой-то жесткий диск выйдет из строя, чтобы не потерять лицензионный контент.

Когда 10 тыс. человек запрашивают одно видео или хотя бы два-три видео, это легко решается кешированием. А если эти 10 тыс. смотрит разный контент, то стандартная СХД не справится. Скорость не позволит находить это на жестких дисках.

В реализации нужно:

— Построить архитектуру хранения и обслуживания клиентов СХД с высоким уровнем IOPS — количество запросов, которые приходят к системе хранения данных за секунду. Чем ровнее запросы из разных секторов жестких дисков, тем сложнее и дольше приходится обрабатывать их сервера.

— Построить балансировщики, которые обрабатывают большое количество разного контента на обычных HDD дисках и отказоустойчивых хранилищах.

Компания «Открытая мобильная платформа» заявила о завершении серии испытаний на совместимость системы управления базами данных (СУБД) Jatoba и платформы управления «Аврора Центр».

По результатам тестирования, программное обеспечение работает корректно, и пользователи смогут получать квалифицированную техническую поддержку от производителей. Демонстрация итогов тестирования проводилась в рамках форума GIS DAYS.

«Аврора Центр» — это система управления парком корпоративных мобильных устройств с ОС «Аврора», ОС Android и терминалами сбора данных, ПК и ноутбуков с российскими ОС семейства Linux. Система работает в замкнутом корпоративном контуре заказчика, обеспечивая сервисы управления устройствами, витрину приложений «Аврора Маркет» и корпоративный сервис push‑уведомлений «Аврора СУА». Также благодаря закрытому контуру никакие пользовательские или производственные данные не покидают корпоративный периметр компании‑заказчика.

Jatoba — это СУБД на базе PostgreSQL с функциональностью для реализации кластерных решений по отказоустойчивости, георезервированию, шардированию и производительности.