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

в 16:00, , рубрики: sql, астрономия, базы данных, галактика, движение Млечного пути, движение Солнечной системы, Космология, космос, красное смещение, траектория галактики, траектория Млечного пути, траектория Солнечной системы, физика

В статье приводится метод построения проекции галактической орбиты Солнечной системы через анализ пространственного перепада космологического красного смещения. Кроме известных движений вращения вокруг центра Галактики и смещения вверх-вниз относительно её диска, на результатах ясно просматривается «покачивание» оси.

image

Рис.0. Визуальное представление минимумов (зелёный) перепада красного смещения на воображаемой гелиоцентрической сфере – результат вращения Солнечной системы вокруг центра Млечного Пути. Чёрная ось – X (положительные направо), красная полупрозрачная – Y (положительные вглубь), синяя – Z (положительные наверх). Жёлтый шар – направление движения согласно жёлтой тенденции (RA 10, DEC -30) – движение Солнечной системы под диск Млечного Пути. Чёрный шар – актуальное направление на Стрельца-А (RA 266, DEC -29), центр Млечного Пути.
Читать полностью »

в 16:01, , рубрики: dba, IS DISTINCT FROM, postgresql, sql, sql antipatterns, sql tips and tricks, update, Администрирование баз данных, базы данных, Блог компании Тензор, Программирование

Особенности работы внутренних механизмов PostgreSQL позволяют ему быть очень быстрым в одних ситуация и «не очень» в других. Сегодня остановимся на классическом примере конфликта между тем, как работает СУБД и тем, что делает с ней разработчик — UPDATE vs принципы MVCC.

Кратко сюжет из отличной статьи:

Когда строка изменяется командой UPDATE, фактически выполняются две операции: DELETE и INSERT. В текущей версии строки устанавливается xmax, равный номеру транзакции, выполнившей UPDATE. Затем создается новая версия той же строки; значение xmin у нее совпадает с значением xmax предыдущей версии.

Через какое-то время после завершения этой транзакции старая или новая версии, в зависимости от COMMIT/ROOLBACK, будут признаны «мертвыми» (dead tuples) при проходе VACUUM по таблице и зачищены.

PostgreSQL Antipatterns: сражаемся с ордами «мертвецов» - 1

Но это произойдет далеко не сразу, а вот проблемы с «мертвецами» можно нажить очень быстро — при многократном или массовом обновлении записей в большой таблице, а чуть позже столкнуться с ситуацией, что и VACUUM не сможет помочь.
Читать полностью »

в 5:50, , рубрики: dba, distinct, explain, explain.tensor.ru, GIN, pg_trgm, postgresql, sql, sql antipatterns, sql tips and tricks, union, Администрирование баз данных, базы данных, Блог компании Тензор, высокая производительность, поиск по названию

Тысячи менеджеров из офисов продаж по всей стране фиксируют в нашей CRM-системе ежедневно десятки тысяч контактов — фактов общения с потенциальными или уже работающими с нами клиентами. А для этого клиента надо сначала найти, и желательно очень быстро. И происходит это чаще всего по названию.

Поэтому неудивительно, что, разбирая в очередной раз «тяжелые» запросы на одной из самых нагруженных баз — нашего собственного корпоративного аккаунта СБИС, я обнаружил «в топе» запрос для «быстрого» поиска по названию для карточек организаций.

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

0: чего же хотел пользователь

PostgreSQL Antipatterns: сказ об итеративной доработке поиска по названию, или «Оптимизация туда и обратно» - 1

[КДПВ отсюда]

Что вообще обычно подразумевает пользователь, когда говорит про «быстрый» поиск по названию? Почти никогда это не оказывается «честный» поиск по подстроке типа ... LIKE '%роза%' — ведь тогда в результат попадают не только 'Розалия' и 'Магазин Роза', но и 'Гроза' и даже 'Дом Деда Мороза'.

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

в 15:49, , рубрики: Have I been pwned, Администрирование баз данных, базы данных, бизнес-модели, информационная безопасность, сделки в it, утечки, финансы в IT

image

Основатель сервиса проверки аккаунтов на утечки Have I Been Pwned Трой Хант рассказал, что он решил не продавать проект и управлять им самостоятельно. В своем блоге Хант поделился подробностями прошедших за последний год переговоров. Читать полностью »

в 9:07, , рубрики: api, python, Администрирование баз данных, базы данных, парсинг, парсинг контента, Программирование, хабрахабр, хранилища данных

Добрый день. Прошло уже 2 года с момента написания последней статьи про парсинг Хабра, и некоторые моменты изменились.

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

Читать полностью »

в 5:50, , рубрики: dba, postgresql, sql, sql antipatterns, sql tips and tricks, update, Администрирование баз данных, базы данных, Блог компании Тензор

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

Например, на таблице, в которой вам надо что-то поправить, висит злобный триггер ON UPDATE, переносящий все изменения в какие-нибудь агрегаты. А вам надо все пообновлять (новое поле проинициализировать, например) так аккуратно, чтобы эти агрегаты не затронулись.

Давайте просто отключим триггеры!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
  UPDATE ...; -- тут долго-долго
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

Собственно, тут и все — все уже висит.

Потому что ALTER TABLE накладывает AccessExclusive-блокировку, под которой никто параллельно выполняющийся, даже простой SELECT, ничего из таблицы прочитать не сможет. То есть пока эта транзакция не закончится, все желающие даже «просто почитать» будут ждать. А мы помним, что UPDATE у нас до-о-олгий…
Читать полностью »

в 11:30, , рубрики: AI, big data, data science, retail, базы данных, искусственный интеллект, разработка, риск-менеджмент, хакатон

29 февраля в «Цифровом деловом пространстве» (ЦДП, Москва, улица Покровка 47) состоится конференция X5 Retail Hero, посвященная Data Science и разработке в сфере ритейла. Участие бесплатное, необходима предварительная регистрация.

Конференция приурочена к финалу одноименного соревнования X5 Retail Group. Между выступлениями экспертов организаторы объявят победителей, представивших лучшие решения для цифровизации розничной торговли.

29 февраля в ЦДП состоится X5 RetailHero: как попасть на первую конференцию Х5 по Data Science и разработке - 1
Читать полностью »

в 6:42, , рубрики: big data, mysql, nosql, sql, базы данных, Блог компании Издательский дом «Питер», высокая производительность, Исследования и прогнозы в IT, распределенные системы

Здравствуйте.

Сегодня мы предлагаем вашему вниманию перевод статьи из блога MemSQL, которая исходно является рекламной (посвящена достоинствам MemSQL, обновлена по состоянию на начало января 2020 года). Но мы решили все-таки перевести ее в сокращенном виде, поскольку она подробно объясняет, почему мы пока так и не собрались издавать ничего ни по MongoDB, ни по Cassandra, ни по прочим нереляционным базам данных. Может быть, мы были правы, ограничившись весьма успешной книгой "MySQL по максимуму".
Читать полностью »

в 13:52, , рубрики: .net, C#, linq, linq to sql, Microsoft SQL Server, MS Sql Server, orm, sql, sql server, t-sql, Администрирование баз данных, базы данных

Введение

В этой статье рассматривались некоторые методы оптимизации LINQ-запросов.
Здесь же приведем еще некоторые подходы по оптимизации кода, связанные с LINQ-запросами.
Читать полностью »

в 6:45, , рубрики: btree, dba, postgresql, sql, Администрирование баз данных, базы данных, Блог компании Тензор, высокая производительность, индексы

Регулярно сталкиваюсь с ситуацией, когда многие разработчики искренне полагают, что индекс в PostgreSQL — это такой швейцарский нож, который универсально помогает с любой проблемой производительности запроса. Достаточно добавить какой-нибудь новый индекс на таблицу или включить поле куда-нибудь в уже существующий, а дальше (магия-магия!) все запросы будут эффективно таким индексом пользоваться.
DBA: Находим бесполезные индексы - 1
Во-первых, конечно, или не будут, или не эффективно, или не все. Во-вторых, лишние индексы только добавят проблем с производительностью при записи.

Чаще всего такие ситуации происходят при «долгоиграющей» разработке, когда делается не заказной продукт по модели «написал разово, отдал, забыл», а, как в нашем случае, создается сервис с длинным жизненным циклом.

Доработки происходят итеративно силами множества распределенных команд, которые бывают разнесены не только в пространстве, но и во времени. И тогда, не зная всей истории развития проекта или особенностей прикладного распределения данных в его БД, можно легко «напортачить» с индексами. Но соображения и проверочные запросы под катом позволяют заранее предсказывать и обнаруживать часть проблем:

  • неиспользуемые индексы
  • префиксные «клоны»
  • timestamp «в середине»
  • индексируемый boolean
  • массивы в индексе
  • NULL-мусор

Читать полностью »

1...91011...2030...50
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js