• Есть ли разница в дисках для NAS?

    Melkij
    @Melkij
    PostgreSQL DBA
    HDD - это расходники. Нет смысла обсуждать "меньше" или "больше" проживут. Сдохнут гарантированно. Если повезёт, то ещё в гарантийный период - бесплатно поменяете.

    Для SOHO разница между линейками по большей части неважна. Вот что стоит уточнить - SMR или CMR диск и готовы ли с этим мириться. Достаточную ли вам предлагают скидку за террабайт, чтобы вляпываться в SMR. В одной и той же линейке дисков могут быть одновременно и SMR и CMR диски, уточнять нужно модели.
    Далее, скорость вращения диска. 7200 чуть быстрее, 5400 медленнее но их попроще охлаждать в среднем. Различие скорости для личной медиатеки скорей всего неважно, но на достаточно хорошем интернет-канале торренты могут заметно озадачить массив количеством IO.

    Зеркало будет надежно или лучше пожертвовать местом и сделать raid5 или 6?

    Звучит как полное непонимание вопроса. Каким местом жертвовать, если именно зеркало даст меньше всего форматируемую ёмкость массивов? Местом придётся жертвовать, если делать как раз зеркало.
    На примере шести 10ТБ дисков для удобства счёта, из 60ТБ RAW ёмкость массива:

    raid0 или JBOD - дадут вам все 60ТБ, выпадение любого диска фатально.
    raid1 - зеркало - даст вам как максимум 3 массива по 10ТБ, до 30ТБ форматируемой ёмкости. В каждом массиве соответственно можно потерять по соседнему диску. То есть хранилка выпадение одного любого диска переживёт, выпадение второго диска - смотря какому из дисков не повезёт. Можно потерять один из массивов полностью. (raid1 на всех 6 дисках вряд ли входит в вопрос, 10ТБ итоговой ёмкости, но чтобы их потерять из-за отказа диска нужно чтобы отказали все 6 дисков)
    raid5 - даст вам 50ТБ форматируемой ёмкости. Переживёт выпадение одного любого диска, выпадение второго диска - фатально для всего массива.
    raid6 - ближайший родственник raid5 - даст вам 40ТБ ёмкости. Но зато гарантированно переживёт выпадение любых двух дисков. Только отказ третьего будет фатален для массива.
    raid10 - даст вам 30ТБ ёмкости как raid1, гарантированно выдержит выпадение одного диска, в идеале может работать на только половине дисков массива но критично зависит от структуры raid10, какие именно номера дисков могут быть потеряны без краха всего массива. Отказ второго диска может оказаться фатален. Используется не когда нужна ёмкость или возможность пережить несколько выпавших дисков, а когда нужна производительность, особенно на запись. То есть вряд ли ваш случай.

    Что ещё надо упомянуть - вот диск из массива умер, сколько времени вам нужно это заметить, купить новый на замену, заменить? Плюс на таких объёмах займёт ещё сутки-двое-трое на восстановление массива. Вот тут причина, почему существует RAID6, хотя он по ёмкости хуже RAID5 и не лучше по производительности - пока у вас массив деградировал до 5/6 дисков, он переживёт выпадение ещё одного из дисков пока вы ставите замену и массив восстанавливается.
    Ответ написан
    Комментировать
  • Как выполнить команды гита для вложенного репозитория?

    yarkov
    @yarkov
    Помог ответ? Отметь решением.
    Удалить папку .git в папке project и не страдать ерундой
    Ответ написан
    1 комментарий
  • Почему не удалось перенести базу zabbix?

    Melkij
    @Melkij
    PostgreSQL DBA
    1. запустили намеренно pg_dump с отказом -O - то есть --no-owner
    2. развернули дамп от супера
    3. все объекты теперь ожидаемо принадлежат суперу, owner'а же не переносили
    4. удивляемся, что постороннему пользователю нет прав чтения

    Что же тут могло пойти не так?

    Самое простое для баз с одним пользователем - импортируйте дамп базы от имени этого самого пользователя. Если в базе есть какие-то extension - то сперва их создать от суперпользователя.
    Ответ написан
    3 комментария
  • Как хранить товары с различными опциями в БД?

    ipatiev
    @ipatiev
    Потомок старинного рода Ипатьевых-Колотитьевых
    В стародавние времена это действительно было проблемой.

    И обычно использовался п.2, который называется EAV, и который в нормальном виде (таблица всех атрибутов, таблица всех значений, и таблица-связка товар-атрибут-значение), хотя и является истинно реляционным решением, служил причиной кровавых слез не одного поколения программистов.

    Эта ситуация послужила одной из причин появления хранилищ для неструктурированных данных, таких как Монго, которые входят в очень широкую категорию NoSQL.
    Но сами по себе "документо-ориентированные базы данных" в качестве основного хранилища - это ад и проклятие, хуже EAV. Если EAV делает адом только работу с атрибутами товаров, то Монга делает проклятием работу со всей БД целиком. Забудьте об этой идее.

    Тем более что в последние годы появилось вполне достойное решение: во всех классических СУБД появилась поддержка JSON полей.
    То есть таблица товаров будет самая обычная, в которой есть общие поля типа цены, названия и прочее. А свойства хранятся в JSON поле. Беря, таким образом, лучшее из двух миров.

    На начальном этапе вы даже сможете делать поиск по атрибутам, используя нативные JSON функции. Но в дальнейшем поиск товаров, а так же фильтрацию по атрибутам на странице категории (так называемый "фасетный поиск") надо будет возложить на специальный поисковый движок (который тоже входит в широкую категорию "NoSQL", хотя ничего общего с документными БД не имеет, и БД, собственно, не является), такой как Эластик или Мантикора.

    Главное при этом хранить (либо в коде, либо в таблице категорий) эталонные структуры таких json полей, которые, во-первых, использовать как справочники для заполнения товаров (тупо чтобы помнить, что частота процессора называется freq, а не frequency), и чтобы собственно делать фасетные фильтры.
    Ответ написан
    5 комментариев
  • Где посмотреть и поучиться правильной постройки баз данных?

    ipatiev
    @ipatiev
    Потомок старинного рода Ипатьевых-Колотитьевых
    Тут всё просто. Про Mongo надо просто забыть. Это вообще не база данных, а бессмысленное хранилище по типу "куча мусора", которое используется исключительно в стильных модных молодёжных стартупах, в которых не нашлось ни одного специалиста по базам данных. Это была тупиковая ветвь, поднявшаяся на отсутствовавшей на тот момент поддержке JSON в базах данных и хайпе.

    И вообще не надо называть "нереляционные хранилища" базами данных. Это специализированные движки - кэширующие(редис, мемкеш), поисковые(мантикора, эластик), аналитические (кликхаус) - которые используются в дополнение к базе данных. или совсем уж какие-то специализированные решения для визуализации или логирования- графана, сентри, кибана, локи - тысячи их. Но все это вещи факультативные, которые понадобятся только на определенном этапе развития проекта (или не понадобятся вовсе).

    А с базой данных и её построением придется столкнуться с самого начала. И вот про это есть великолепная книга Святослава Куликова Реляционные базы данных в примерах. Она очень четко рассказывает именно про постройку базы данных.
    Ответ написан
    2 комментария
  • Как в Postgres записывать слова с символами Moore's?

    rozhnev
    @rozhnev
    Fullstack programmer, DBA, медленно, дорого
    Одинарная кавычка экранируется дополнительной одинарной кавычкой. Пример SQL здесь
    Ответ написан
    1 комментарий
  • Как правильно задать запрос UPDATE где название столбца переменная?

    ipatiev
    @ipatiev Куратор тега PHP
    Потомок старинного рода Ипатьевых-Колотитьевых
    Этот вопрос - прекрасная иллюстрация того факта, что нормализация базы данных - это не блажь оторванных от жизни теоретиков, а насущная необходимость. И её отсутствие приводит к проблемам на ровном месте.

    Уже по наличию нумерованных столбцов сразу видно, что структура БД кривая. А текущая проблема делает это еще более наглядным: собственно, сама постановка вопроса, "как задать имя столбца через переменную", говорит о том, что имя колонки используется в условии. То есть оно должно быть значением в строке.

    Здесь нужна связанная таблица, один ко многим, и она сразу снимет все проблемы, а запросы станут мягкими и шелковистыми:

    UPDATE link_count SET count=count+? WHERE link_id=? and number=?
    Ответ написан
    3 комментария
  • Почему Postgres не завершает IDLE-транзакции?

    Melkij
    @Melkij
    PostgreSQL DBA
    idle != idle in transaction. Это принципиально разные статусы.

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

    В частности, где вызов release()?
    Ответ написан
    2 комментария
  • Как расширить размер дискового пространства в Linux?

    @Zerg89
    Ответ написан
    Комментировать
  • Как гарантировать последовательную запись данных без пропусков id?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Таблицы на основе генераторов или sequences обычно ствавят главной задачей - обеспечить
    уникальность id в первую очередь
    . С эти sequence справляется.

    Гарантировать блокировку или захват sequence они не могут так как Postgres создавался
    как много-пользовательская БД
    . Тоесть много сессий обладают правом в любой момент
    взять из sequence следующее значение
    . Поэтому требование хронологии - это как эксклюзивный
    лок объекта. Слишком жесткое требование. И никому не нужное. Если б так БД работали то
    они теряли бы в производительности и ждали-бы чтоб какая-то главная сессия отпустила таблицу.

    Выход есть - брать ранг записи извне. Тоесть само приложение должно быть поставщиком
    таких номеров. А БД будет просто их вставлять.

    Еще вариант - в уже после загрузки обновить одно полей одной транзакцией как row_number
    сортируя по любому признаку.
    Ответ написан
    6 комментариев
  • Как корректно изменить права во всей системе, чтобы others не могли ничего делать?

    @AlexVWill
    chmod -R 770 / - корректно будет?

    если хочешь всю систему нахрен завалить чтобы она не работала - то да
    а ответ на твой вопрос - не надо ничего делать специально, что ты хочешь - система уже по умолчанию делает, не мешай ей работать
    Ответ написан
    Комментировать
  • Как понять к какой БД относиться таблица из pg_stat_io?

    Melkij
    @Melkij
    PostgreSQL DBA
    Это всегда current_database()
    У каждой БД свой собственный системный каталог со своим собственным pg_class, pg_namespace и так далее (за исключением буквально пары действительно глобальных вроде pg_database и pg_authid).
    Ответ написан
    1 комментарий
  • Как запретить вход на сайт по ip через nginx?

    yarkov
    @yarkov
    Помог ответ? Отметь решением.
    Слушать порт не для 0.0.0.0, а только для localhost
    Ответ написан
    Комментировать
  • Как изменить правило редиректа чтобы только url с цифрами и буквами редиректелись?

    @dodo512
    location ~* "^/(?=.*[a-z])(?=.*\d)[a-z\d]{5}/$" {
    }

    Или
    location ~* "^/(?>[a-z]()|\d()){5}/$\1\2" {
    }
    Ответ написан
    Комментировать
  • Почему вместо сетевой папки открывается браузер?

    paran0id
    @paran0id
    Умный, но ленивый
    Слэши не в ту сторону
    Ответ написан
    Комментировать
  • Какую ошибку я допустил в Dockerfile во время накатывания миграций?

    chupasaurus
    @chupasaurus
    Сею рефлекторное, злое, временное
    ports делает соответствие между портами на хосте и в контейнере соответственно, внутри докерной сети ничего не меняется. Потому в sqlalchemy.url оставляйте 5432
    З.Ы. посмотрите на хелсчек (:
    Ответ написан
    1 комментарий
  • Почему нельзя/можно писать бизнес-логику в sql?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Можно. Весь 20-й век почти так делали. База была главной. Эдакая себе царица. Ее любили. Холили.
    Приложения были двухзвенки. Оконная апликуха коннектилась к базе и все расчеты
    проводились в базе. Апликуха только показывала результаты в гридах и вводила формочки.
    Джобы тоже запускались в базе как процедуры на PL/SQL по скедулеру. Для пуска их клиент
    был тоже не нужен. Плановые задачи БД запускала самостоятельно. Это и было видение
    бизнес логики из 20-го века.

    В 21-м веке с развитием веба появился слой middle. И разработчики вынесли в него максимальную
    часть логики. Это произошло естественным путем. А базе досталась участь быть просто хранилищем
    таблиц. Потому что держать 2 копии логики или поддерживать было уже неудобно. В команде
    должен быть тогда разработчик и Java и PL/SQL одновременно. В современной парадигме
    разработки с ORM база стала просто чем-то вторичным. И на уровне ORM абстракций
    даже заменяемым на другие типы баз.

    Но не все так плохо.

    Фактически, логика современного приложения размазана по 3м слоям. Даже в браузере
    есть какая-то минимальная логика, например при аутентификации или при проверке
    валидности емейла. И какая-то логика агрегации (sum/group by) полюбому есть в базе.
    Потому что агрегировать в приложении все - глупо. Это лишний трафик.

    И нет такого архитектора который говорит "нельзя". Просто есть best-practices современной разработки,
    исходя из развитя железа, сетей и вообще рынка всего остального. Кто знает может в мобилах вернуться
    к двузвенкам. Смотря под каким углом смотреть на современные мобильные приложения? Who knows.
    Ответ написан
    2 комментария