es
Feedback
DATABASE DESIGN

DATABASE DESIGN

Ir al canal en Telegram

Лучшие материалы по работе с хранилищами данных на русском и английском языке Разместить рекламу: @tproger_sales_bot Правила общения: https://tprg.ru/rules Другие каналы: @tproger_channels Другие наши проекты: https://tprg.ru/media

Mostrar más
1 355
Suscriptores
Sin datos24 horas
-47 días
-830 días
Archivo de publicaciones
По следам meetup «Новые возможности PostgreSQL 11» Сегодня мы расскажем о самых главных фичах PostgreSQL 11. Почему только о них — потому что некоторые возможности нужны далеко не всем, поэтому мы остановились на самых востребованных. Содержание * JIT-компиляция * Секционирование * Индексы * Покрывающие индексы * SP GiST * Производительность * WAL * Бэкап и репликация * Для DBA * Параллельное выполнение * Оптимизаторы * Window-функции * Изменения в полнотекстовом поиске * Json(b) и полнотекст * PL/* процедуры * pgbench * Улучшения PSQL Читать: https://habr.com/ru/companies/raiffeisenbank/articles/414031/ #ru @database_design | Другие наши каналы

Дисковое кеширование деревьев ленивых вычислений О концепции ленивых вычислений вряд ли стоит подробно говорить. Идея пореже делать одно и то же, особенно, если оно долгое и тяжелое, стара как мир. Потому сразу к делу. По разумению автора настоящего текста нормальный ленификатор должен: 1. Сохранять вычисления между вызовами программы. 2. Отслеживать изменения в дереве вычисления. 3. Иметь в меру прозрачный синтаксис. Читать: https://habr.com/ru/articles/422937/ #ru @database_design | Другие наши каналы

База данных в коммерческом проекте: как поступить? Всех с окончанием праздников!… Некоторые скажут, что это поздравление — так себе. Но, наверняка, у многих скоро отпуск, так что поднажмите еще немного. Ну а мы не сдаем обороты и в этот теплый день делимся опытом наших партнеров. Речь пойдет об оптимизации работы с базой данных. Подробнее под катом! Читать: https://habr.com/ru/companies/microsoft/articles/413757/ #ru @database_design | Другие наши каналы

Мониторим активные сессии PostgreSQL 10, как в Oracle Данный инструмент написан из спортивного интереса, когда мною было обнаружено, что вьюха pg_stat_activity в PostgreSQL 10 имеет поля wait_event_type и wait_event, очень похожие по сути на оракловые wait_class и event из v$session. Активно работая в данный момент с программой ASH-Viewer от akardapolov мне стало любопытно — насколько сложно переписать этот продукт под Postgres. Учитывая, что я не профессиональный разработчик, было не просто, но очень интересно. По ходу дела даже нашёл, как мне кажется, пару значительных багов, которые проявляются и в оригинальной программе для Oracle, по кр.мере для Standard Edition. Принципы работы PASH-Viewer: Читать: https://habr.com/ru/articles/413411/ #ru @database_design | Другие наши каналы

Как устроены базы данных Нельзя сказать, что в этой статье вас ждут отборные потроха баз данных, но скорее рассказ про базы данных от самого начала, плюс небольшое углубление в некоторые подробности, которые Илье Космодемьянскому (@hydrobiont) кажутся важными. И есть все основания полагать, что так оно и есть. Эта статья родилась не от хорошей жизни. Часто даже не то что начинающие разработчики, но и вполне продвинутые, не знают каких-то базовых вещей — может быть, давно учились в университете и с тех пор забыли, или им не приходилось углубляться в теорию, поскольку и так работалось нормально. Тем не менее, теоретические знания иногда полезно освежить. Этим мы, в том числе, и займемся. О спикере: Илья Космодемьянский CEO и консультант в компании Data Egret, специалист по базам данных PostgreSQL, Oracle, DB2. А кроме того, отвечает за продвижение Postgres-технологий, выступает на конференциях и рассказывает людям, как с ними работать. Ниже материал по докладу Ильи на РИТ++ 2017, который не был связан с какой-то конкретной базой данных, но охватывал многие основные аспекты. Читать: https://habr.com/ru/companies/oleg-bunin/articles/358984/ #ru @database_design | Другие наши каналы

Мир магии PostgreSQL: интервью с Николаем Самохваловым Сегодня мы поговорим с Николаем, «борцом» за продвижение новых технологий в мире БД, членом нашего программного коммитета и активным участником всевозможных конференций. Главные темы — самоуправляемые СУБД, DBA AI, облака, NoSQL, встроенные механизмы контроля БД, доклады на РИТ++ и HighLoad++ Siberia, а также масса дельных советов и примеров, которые могут пригодится в реальной работе как разработчику, так и DBA. Читать: https://habr.com/ru/companies/oleg-bunin/articles/359306/ #ru @database_design | Другие наши каналы

Нефтегазовая дилемма: в поиске альтернативных СУБД Как известно, в начале этого года американская корпорация Oracle в соответствии с требованиями правительства США об ужесточении санкций в отношении российских нефтегазовых компаний изменила условия предоставления им своих продуктов и услуг. Введен запрет как на новые сделки, так и на продление существующих контрактов. Эти ограничения непосредственно касаются многих нефтегазовых структур, включая предприятия «Газпрома», «Роснефти», «Лукойла» и «Сургутнефтегаза». Под санкции попали 283 российских компании. Читать: https://habr.com/ru/companies/tmaxsoft/articles/360491/ #ru @database_design | Другие наши каналы

Как я эволюцию админов в программистов измерял Недавно мой знакомый Karl (имя изменено) проходил собеседование на должность DevOps и обратился ко мне с просьбой проверить его решение. Я почитал условие задачи и решил, что из нее бы вышел неплохой тест, поэтому немного расширил задачу и написал свою реализацию, а заодно попросил коллегу Alex подумать о своей реализации. Когда все три варианта были готовы, я сделал еще две сравнительные версии на C# и сел писать эту статью. Задача довольно проста, а соискатели находятся на неких ступенях эволюции из админов в программисты, которые я и хотел оценить. Кому интересны грязные детали, необъективные тесты и субъективные оценки — прошу под кат. Читать: https://habr.com/ru/articles/359284/ #ru @database_design | Другие наши каналы

noBackend, или Как выжить в эпоху толстеющих клиентов Название статьи не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». Эта статья основана на докладе Николая Самохвалова, который, в свою очередь, обобщил опыт ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму noBackend за счёт PostgreSQL+PostgREST. В конце, вы найдете список must-check-вопросов для работы с noBackend-подходом, а, если ваш Postgres-опыт позволяет, то сразу после прочтения вы можете приступить к разворачиванию безопасного, высокопроизводительного и годного для быстрого развития REST API. О спикере: Николай Самохвалов больше десяти лет работает с PostgreSQL, является со-организатором российского сообщества RuPostgres.org и в данный момент помогает различным компаниям оптимизировать, масштабировать и автоматизировать процессы, связанные с эксплуатацией PostgreSQL. Далее — расшифровка доклада Николая на Backend Conf, рассчитанного и на бэкенд, и на фронтенд разработчиков. Последние годы я много времени провожу в Силиконовой Долине и хочу поделиться с вами трендами, которые я там наблюдаю. Конечно, отсюда вы тоже прекрасно все видите, но там они нагляднее, потому что профессиональные разговоры о передовых технологиях ведутся буквально в каждом кафе. Читать: https://habr.com/ru/companies/oleg-bunin/articles/358502/ #ru @database_design | Другие наши каналы

Настройка мониторинга состояния базы данных Успешные и динамично развивающиеся стартапы часто достигают точки, когда проблемы с базой данных уже есть, а отдельного человека для их решения еще нет. Впрочем, и не всем он нужен. Сервис мониторинга ХостТрекер предлагает возможность автоматически следить за ключевыми показателями жизнедеятельности базы без необходимости каждый день лезть на сервера вручную. Ниже мы расскажем, как ловить популярные ошибки, защититься от внезапного переполнения базы, быть уверенным в том, что всегда есть свежий и успешный бэкап ну и еще по мелочи. Читать: https://habr.com/ru/companies/host-tracker/articles/358472/ #ru @database_design | Другие наши каналы

Нечеткий поиск (fuzzy search) в реляционных базах данных Для поиска нужной информации на веб-сайтах и в мобильных приложениях часто используется поиск по словам или фразам, которые пользователь свободно вводит с клавиатуры (а не выбирает например из списка). Естественно, что пользователь может допускать ошибки и опечатки. В этом случае полнотекстовый поиск, полнотекстовые индексы, которые реализованы в большинстве баз данных не дают ожидаемого результата и практически бесполезны. Такой функционал все чаще реализуют на основе elasticsearch. Решения с использованием elasticsearch имеют один существенный недостаток — очень большая вероятность рассогласования основной базы данных, например PostgreSQL, MySQL, mongodb и elasticsearch, в которой хранятся индексы для поиска. Читать: https://habr.com/ru/articles/354032/ #ru @database_design | Другие наши каналы

Концепция BaselineTopology в Apache Ignite 2.4 На момент появления в Apache Software Foundation проекта Ignite он позиционировался как чистое in-memory-решение: распределенный кэш, поднимающий в память данные из традиционной СУБД, чтобы выиграть во времени доступа. Но уже в релизе 2.1 появился модуль встроенной персистентности (Native Persistence), который позволяет классифицировать Ignite как полноценную распределенную базу данных. С тех пор Ignite перестал зависеть от внешних систем обеспечения персистентного хранения данных, и вязанка граблей конфигурации и администрирования, на которые не раз наступали пользователи, исчезла. Однако persistent-режим порождает свои сценарии и новые вопросы. Как предотвратить неразрешимые конфликты данных в ситуации split-brain? Можем ли мы отказаться от перебалансировки партиций, если выход узла теперь не означает, что данные на нем потеряны? Как автоматизировать дополнительные действия вроде активации кластера? BaselineTopology нам в помощь. Читать: https://habr.com/ru/companies/gridgain/articles/352916/ #ru @database_design | Другие наши каналы

Сравниваем Tarantool с Redis и Memcached Выбираете между Tarantool и Redis или между Tarantool и Memcached? Давайте рассмотрим основные различия, чтобы вам легче было определиться. Читать: https://habr.com/ru/companies/vk/articles/352760/ #ru @database_design | Другие наши каналы

Что нового в DataGrip 2018.1 Привет! В этом релизном цикле некоторые улучшения появились ещё в минорных обновлениях. Но, так как о них на Хабре мы не пишем, я расскажу в этом посте обо всём новом с момента предыдущего релиза. Читать: https://habr.com/ru/companies/JetBrains/articles/352902/ #ru @database_design | Другие наши каналы

Книга «Высоконагруженные приложения. Программирование, масштабирование, поддержка» В этой книге вы найдете ключевые принципы, алгоритмы и компромиссы, без которых не обойтись при разработке высоконагруженных систем для работы с данными. Материал рассматривается на примере внутреннего устройства популярных программных пакетов и фреймворков. В книге три основные части, посвященные, прежде всего, теоретическим аспектам работы с распределенными системами и базами данных. От читателя требуются базовые знания SQL и принципов работы баз данных. В обзорном посте рассматривается раздел «Знание, истина и ложь». Если у вас нет опыта работы с распределенными системами, то последствия этих проблем могут оказаться весьма дезориентирующими. Узел сети ничего не знает наверняка — он способен только делать предположения на основе получаемых (или не получаемых) им по сети сообщений. Один узел в силе узнать состояние другого узла (какие данные на нем хранятся, правильно ли он работает), только обмениваясь с ним сообщениями. Если удаленный узел не отвечает, то нет никакого способа выяснить его состояние, поскольку невозможно отличить сетевые проблемы от проблем в узле. Читать: https://habr.com/ru/companies/piter/articles/352742/ #ru @database_design | Другие наши каналы

Вопросы совместимости Tibero и Oracle. Часть 2. Разработка Java приложений Мы продолжаем цикл статей разработчиков приложений для баз данных — Часть 1. Условная компиляция PL/SQL. Эта статья затронет тему использования Tibero в Java приложениях использующих JDBC и Hibernate, а также фреймворк Spring Roo. Читать: https://habr.com/ru/companies/tmaxsoft/articles/352560/ #ru @database_design | Другие наши каналы

Применение Tarantool: хранимые процедуры Перевод статьи с DZone. Оригинал. Я хочу поделиться своим опытом создания приложений для Tarantool, и сегодня мы поговорим об установке этой СУБД, о хранении данных и об обращении к ним, а также о записи хранимых процедур. Читать: https://habr.com/ru/companies/vk/articles/352430/ #ru @database_design | Другие наши каналы

Terraform: новый подход к Infrastructure as code Привет, коллеги! Пока блистательный Илон Маск вынашивает амбициозные планы терраформирования Марса, мы интересуемся новыми возможностями, связанными с парадигмой "Infrastructure as Code" и хотим предложить вам перевод статьи об одном из представителей «великолепной семерки» — Terraform. Книга Евгения Брикмана по теме неплохая, но ей скоро год, так что просим высказаться — хотите ли увидеть ее на русском языке Слово Камалу Мархуби (Kamal Marhubi) из компании Heap. Читать: https://habr.com/ru/companies/piter/articles/351878/ #ru @database_design | Другие наши каналы

Как я парсил БД C-Tree, разработанную 34 года назад Прилетела мне недавно задача дополнить функционал одной довольно старой програмки (исходного кода программы нет). По сути нужно было просто сканить периодически БД, анализировать информацию и на основе этого совершать рассылки. Вся сложность оказалась в том, что приложение работает с БД c-tree, написанной аж в 1984 году. Порывшись на сайте производителя данной БД нашёл некий odbc драйвер, однако у меня никак не получалось его подключить. Многочисленные гугления так же не помогли нормально сконнектиться с базой и доставать данные. Позже было решено связаться с техподдержкой и попросить помощи у разработчиков данной базы, однако ребята честно признались что уже прошло 34 года, всё поменялось 100500 раз, нормальных драйверов для подключения на такое старьё у них нет и небось уже тех программистов в живых тоже нету, которые писали сие чудо. Порывшись в файлах БД и изучив структуру, я понял, что каждая таблица в БД сохраняется в два файла с расширением *.dat и *.idx. Файл idx хранит информацию по id, индексам и т.д. для более быстрого поиска информации в базе. Файл dat содержит саму информацию, которая хранится в табличках. Решено было парсить эти файлики самостоятельно и как-то добывать эту информацию. В качестве языка использовался Go, т.к. весь остальной проект написан на нём. Читать: https://habr.com/ru/articles/351658/ #ru @database_design | Другие наши каналы

#PostgreSQL. Ускоряем деплой в семь раз с помощью «многопоточки» Всем привет! Мы на проекте ГИС ЖКХ используем PostgreSQL и недавно столкнулись с проблемой долгого выполнения SQL скриптов из-за быстрого увеличения объема данных в БД. В феврале 2018 года на PGConf я рассказал, как мы решали эту проблему. Слайды презентации доступны на сайте конференции. Предлагаю вашему вниманию текст моего выступления. Читать: https://habr.com/ru/companies/lanit/articles/351160/ #ru @database_design | Другие наши каналы