Проверить всё?! Это очень смелое заявление. Я такие делал годов до 37 плюс-минус год, полтора.

Такие четкие временные рамки )))

Просто до переезда в Мск и устройства в СУП я не нюхал нормальной нагрузки. Любая задача - неделя, две максимум, не сильно упираясь.

Сентер Управления Полетами? ))

Неа, СУП, который ЖЖ владел.

Шутка юмора такая )

Проверить всё?! Это очень смелое заявление. Я такие делал годов до 37 плюс-минус год, полтора.

Да, уточню: все варианты, которые были "сгенерированы" на посиделках тех. спецов )))

:)

@Azim_bn_Harith тех.спецы на посиделках такого и столько могут нагенерить... :)

Даже выбрав один путь, запросто можно нарваться на множество вариантов решений.

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

@Azim_bn_Harith тех.спецы на посиделках такого и столько могут нагенерить... :)

Эт, да... Но, есть какие-то итоговые рамки\фильтры, посредством которого(-ых) отсееваются добрая часть...

Да, уточню: все варианты, которые были "сгенерированы" на посиделках тех. спецов )))

Моя религия такова, что на серваке логики быть не должно. Но то мое.

архитектура любого проекта копирует оргструктуру создающей его организации

архитектура любого проекта копирует оргструктуру создающей его организации

в мемориз! )

ох уж этот закон Конвэя

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

Из мемориза

Моя религия такова, что на серваке логики быть не должно. Но то мое.

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

так бекенд или база? :)

так бекенд или база? :)

в данном случае, бакэнд - сервер БД.

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

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

Друзья, что меряет значение tup_inserted из pg_stat_database? Почему это значение имеет огромные значения, однако столько данных в реальности не вставляется?

update - это пометить старое как "к удалению" и вставить новое

привет :) подскажите, плиз, есть ли смысл pgsql_tmp делать tmpfs?

Подскажите хороший туториал по jsonb? Есть поле - массив объектов, одно из свойств - имя. Нужен constraint чтоб все имена были уникальными (в рамках данной записи)

https://www.postgresql.org/docs/9.6/static/functions-json.html

Спасибо большое (на самом деле нет). Я просил не ссылку на доки, а туториал. Доки я уже прочитал, спасибо.

привет :) подскажите, плиз, есть ли смысл pgsql_tmp делать tmpfs?

У тебя столько много памяти? Тогда уж лучше shared увеличить и workmem

Спасибо большое (на самом деле нет). Я просил не ссылку на доки, а туториал. Доки я уже прочитал, спасибо.

для начала, чтобы дать какую-то ссылку на туториал, этот туториал должен существовать :)

для начала, чтобы дать какую-то ссылку на туториал, этот туториал должен существовать :)

Дарова кстати. Какие люди. Это Дима ака shadowjack с ОСМ.

У тебя столько много памяти? Тогда уж лучше shared увеличить и workmem

не совсем понял. shared_buffers, work_mem и темповые файлы от джойнов и сортировок это разые кейсы ведь

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

не совсем понял. shared_buffers, work_mem и темповые файлы от джойнов и сортировок это разые кейсы ведь

я знаю что shared не связан с временными файлами. А вот workmem связан. Если его не хватает, то как раз создаются временные файлы.

да, но он для всех операций по work_mem памяти выделяет т.е. его не увеличить до такого-же размера, что tmpfs директорию (допустим, 10 гигов)

а если темп файлы в память поместить, то такой проблемы не будет ее будут использовать все запросы, которым уже не хватило work_mem, но при этом все равно будут продолжать работать в памяти

Дарова кстати. Какие люди. Это Дима ака shadowjack с ОСМ.

А чего до сих пор не в @ruosm ? ))

Всем привет! Возможно кто знает, можно как то сделать двойной инкремент в постгрес? Чтобы был id sec_id 1 1 1 2 2 1 2 2 2 3

так же как и обычный тока шаг указать

То есть одно поле зависит от другого

а какая зависимость?

Скажем так, вложенная нумерация То есть например есть товары и категории товаров Мне нужно чтобы при добавлении нового товара, товар получал уникальный ID (тут просто serial) и ID в конкретной категории товаров (тут не знаю как)

процедура ?

а что мешает сразу указать категорию ?

Кроме процедуры ничего в голову не приходит, если говорить, только, о базе данных, но так, на сколько я знаю, никто не делает, это уже бизнесовая логика, как мне кажется. Такой подход подойдет для Oracle (PL/SQL), в остальном это делается через ORM (пусть меня поправят, если не прав)

Скажем так, вложенная нумерация То есть например есть товары и категории товаров Мне нужно чтобы при добавлении нового товара, товар получал уникальный ID (тут просто serial) и ID в конкретной категории товаров (тут не знаю как)

on insert триггер?

>>> товар получал уникальный ID (тут просто serial) и ID в конкретной категории товаров (тут не знаю как) так у тебя это автоматически получается - берешь productId:categoryId - это и есть уникальный id товара во всем проекте.

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

Это у вас реально задание такое, или просто хочется с единички везде начинать?

Друзья, что меряет значение tup_inserted из pg_stat_database? Почему это значение имеет огромные значения, однако столько данных в реальности не вставляется?

vacuum на возвращение строк точно

нубский вопрос: можно ли хранить массив байт в jsonb или лучше кодировать в base64? или нет разницы? примерная структура {"a":"b", "c":["byte_arr", "byte_arr", "byte_arr"]}

Как по мне, лучше, по возможности не пихать эти данные туда. Если же нет вариантов, то лучше в base64, с ним будет проще оперировать.

Опять же, какой размер массива байтов

Опять же, какой размер массива байтов

небольшие медиа файлы, грубо говоря до мегабайта

если что, это временная мера, пока не закупятся диски. я знаю что фс быстрее базы)

Я бы порекомендовал хранить отдельно (не в БД). Если это невозможно, то в отдельной таблице, в виде бинарных данных. Если прям нужно в jsonb, то мое мнение выше :)

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

Еще момент, у вас что за ЯП/инструмент, из которого вы работаете?

ORM какая-то?

С БД работаем на go

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

если что, это временная мера, пока не закупятся диски. я знаю что фс быстрее базы)

т.е. в БД вы не на диски писать будете ?

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

понято, спасибо

т.е. в БД вы не на диски писать будете ?

это другие диски

А тот сервер, где вертится приложение - туда нельзя писать?

а потом просто мувнуть на диски

А тот сервер, где вертится приложение - туда нельзя писать?

приложение у клиента крутится, база у нас

медиа тоже будет у нас

То есть в клиентском приложении прописан прямой коннект к вашей базе?

да

А когда будут диски - как вы будете обрабатывать аплоад?

Может как временную меру лучше просто сразу поднять этот сервис для аплоада файлов и складывать пока туда же, где БД, раз уж это временная мера, чем городить костыльную обработку хранения файлов в БД и потом мувать на ФС и переписывать обработку, нет?

напишем утилиту для миграции)

за 9.99

И сервис у вас будет готов, просто путь надо будет сменить и утилит по выгрузке писать не надо - просто переместить файлы

ну да хозяин барин

нубский вопрос: можно ли хранить массив байт в jsonb или лучше кодировать в base64? или нет разницы? примерная структура {"a":"b", "c":["byte_arr", "byte_arr", "byte_arr"]}

Есть вполне себе подходящий datatype https://www.postgresql.org/docs/current/static/datatype-binary.html

Вчера только один знакомый спрашивал совета как NFS работает через интернет )) У них тоже место закончилось. Но изврат с БД это конечно...

индексы слишком много места занимают((

Вчера только один знакомый спрашивал совета как NFS работает через интернет )) У них тоже место закончилось. Но изврат с БД это конечно...

а в чем проблема на амазон какой-нибудь фоточки кидать?

или фликр, на фликре терабайт на бнсплатном аккаунте

а в чем проблема на амазон какой-нибудь фоточки кидать?

у них старые данные нельзя было перемещать

А может все же сделать у себя на сервере службу, которая мету кладёт в базу, а бинари на файловую?

Народ подскажите пожалуйста, а как поставить расширение, например oid2name, если кластер уже поставил?)

господа, а почему при правильно отрабатывающей команде архивирования валов они продолжают лежать в огромном количестве и пухнуть?

в статусе у них done

Насколько я знаю, postgres оставляет только те логи транзакций, которые необходиммы для восстановления БД в случае краха)) Все Валы он тебе не заархивирует

предположим что там лежат логи более чем недельной давности в том числе и в архив попали и они.

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

Ищите неиспользуемый слот репликации либо залипший xid.