Ну если ваш бизнес позволяет Вам сделать отдельный кластер с 2Тб ссд и железом как на проде для отладки одного аналитического запроса - пожалуйста, так и делайте
Расширения создают свои таблицы, функции, типа и прочие объекты И вряд-ли вы захотите, чтобы они мазолили Вам глаза, когда будете открывать дерево объектов Вашей БД.
Для примера - установить postgis в public, где у вас своих 200 функций. А теперь попробуйте глазами найти нужную Вам функцию :)
Ну и опять-же, это нормализация структуры. Каждый объект - на своём месте. Это очень удобно. + Это возможность удобно отключать ненужные объекты в pg_dump-e. ( ведь объекты для расширений ставятся установкой расширений )
То есть разрешить криворуким ребятам запускать что-то прямо на продакшен-базе? Предполагается что у них в это время будет ещё и доступ к реальным таблицам (на чтение?)?. Но.. ведь.. дедлоки.. блокировки.. ресурсы.. безопасность..
Вопрос безапасности данных - да, это понятное дело... Но предполагаю, что доступ не у всех же будет :)
Тут вопрос имнно в том, что могут быть проблемы с планировщиком/ статистикой именно на проде и на продовских данных. Да, можно деанонимизировать данные и сделать копию для тестов ( ну у нас например 2 самых больших проекта сейчас: 2Тб и 670Гб ), не будем же мы делать копии для теста)
Дедлоков тут быть не будет как таковых. На счёт ресурсов - ну выполнишь 1 раз запрос для получения аналайза и всё.
Что касается советов по структуре - тут никогда не будет одного правильного решения.
Поэтому я и назвал рекомендациями. Понятное дело, что универсальных решений нет, универсальных подходов тоже.
В СУБД ты можешь делать не create table mytable(hash text, password text); create index on mytable(hash);
Гораздо круче сделать так: create table mytable(password text); create index on mytable(md5(password));
Получается, что ты хэш будешь хранить только в индексе. Для поиска: `select from mytable where md5(password) = ?`
Предложение 2: Если ты пользуешься всё-же поиском только одного единственного значения ( в том смысле, что не делаешь поиск нескольких хэшей одновременно), то рекомендую посмотреть в сторону хэш-индексов ( `create index on mytable using hash(md5(password))` ) То же самое можешь сделать и на уровне csv.
Поиск по хэшу идёт быстрее, но есть некоторые недостатки ( см ниже)
Предложение 3: А вот если ты вдруг захочешь искать несколько строк ( представим на миг, что ты делаешь сервис по дэхэшированию): Ты приятно удивишься, что поиск N значений разом идёт на много быстрее, чем N поисков по одному ( даже если убрать овертайм на запросы и т.д.) Но при хэш-индексе ( и п.2) такая фигня не прокатит :)
В случае, если подобное захочешь делать с файлами - берёшь входной массив хэшей, сортируешь по возрастанию и делаешь поиск ( когда нашёл первый хэш, то второй 100% будет идти после него, соответственно `lef{i+1}> = mid{i}+1`
UPD: Интересно узнать, а конфиг СУБД был стандартный или ей разрешалось тоже забирать память из системы ?)
Вроде писал:
Нижеприведённые графики будут показывать время добавления ( в мс ) следующих 10.000 данных — по оси Y, кол-во добавленных данных — по оси X.
По Х — количество добавленных данных
По Y — время, за которое добавились последние 10.000 записей
К сожалению, я не видел смысла делать COPY в CSV и текстовом форматах.
Но в разных ситуациях может быть по разному.
К примеру, если вы будете передавать на сервер много 'мелких' данных — есть смысл использовать текстовой формат для того, чтобы снизить размер буфера ( меньше нагрузка на сеть)
Бинарный формат — он же более универсальный и самый точный ( например для double чисел)
Надеюсь, я достаточно развёрнуто дал ответ.
А по поводу графиков и скорости — думаю, это будет в районе +- 5-20% ( в отличии от COPY binary ). Опять же в зависимости от того, что передаём
Ну если ваш бизнес позволяет Вам сделать отдельный кластер с 2Тб ссд и железом как на проде для отладки одного аналитического запроса - пожалуйста, так и делайте
Потому что по ней видно, кто , когда и в какой задаче ( с каким коммитом ) изменял тот или иной объект.
Все скрипты написаны так, чтобы их двойной запуск ничего не ломал + система перепроверки миграций.
Да, все скрипты по объектам распиханы ( типа ./schema_name/type/name/object_name.sql )
о_О, спасибо, будет что на досуге прочитать )
Вот именно для каких-то тестов именно на проде ( и только на проде ) - отдельная схема.
Мы заливаем миграции через liquibase, но и даже у пользователя, под которым выполняются миграции - не админка.
А как-же агрегаты по времени ?
Расширения создают свои таблицы, функции, типа и прочие объекты
И вряд-ли вы захотите, чтобы они мазолили Вам глаза, когда будете открывать дерево объектов Вашей БД.
Для примера - установить postgis в public, где у вас своих 200 функций. А теперь попробуйте глазами найти нужную Вам функцию :)
Ну и опять-же, это нормализация структуры. Каждый объект - на своём месте. Это очень удобно.
+ Это возможность удобно отключать ненужные объекты в pg_dump-e. ( ведь объекты для расширений ставятся установкой расширений )
Вопрос безапасности данных - да, это понятное дело... Но предполагаю, что доступ не у всех же будет :)
Тут вопрос имнно в том, что могут быть проблемы с планировщиком/ статистикой именно на проде и на продовских данных. Да, можно деанонимизировать данные и сделать копию для тестов ( ну у нас например 2 самых больших проекта сейчас: 2Тб и 670Гб ), не будем же мы делать копии для теста)
Дедлоков тут быть не будет как таковых.
На счёт ресурсов - ну выполнишь 1 раз запрос для получения аналайза и всё.
Поэтому я и назвал рекомендациями. Понятное дело, что универсальных решений нет, универсальных подходов тоже.
Самое простое — это модифицировать БД с помощью миграционных скриптов. Тогда буквально будет поэтапная история всех изменений.Именно так мы сейчас и делаем:
храним отдельно файлики со скриптами ( на каждый объект свой файл)
эти файлики - и есть миграции для liquibase
Точнее, мы ещё тестируем весь функционал, потому что он в себя включает много разных аспектов
Так-с. Внесу немного свою лепту:
Предложение 1: Экономим место в СУБД
В СУБД ты можешь делать не
create table mytable(hash text, password text); create index on mytable(hash);Гораздо круче сделать так:
create table mytable(password text); create index on mytable(md5(password));Получается, что ты хэш будешь хранить только в индексе. Для поиска:
`select from mytable where md5(password) = ?`Предложение 2:
Если ты пользуешься всё-же поиском только одного единственного значения ( в том смысле, что не делаешь поиск нескольких хэшей одновременно), то рекомендую посмотреть в сторону хэш-индексов (
`create index on mytable using hash(md5(password))`)То же самое можешь сделать и на уровне csv.
Поиск по хэшу идёт быстрее, но есть некоторые недостатки ( см ниже)
Предложение 3:
А вот если ты вдруг захочешь искать несколько строк ( представим на миг, что ты делаешь сервис по дэхэшированию):
Ты приятно удивишься, что поиск N значений разом идёт на много быстрее, чем N поисков по одному ( даже если убрать овертайм на запросы и т.д.)
Но при хэш-индексе ( и п.2) такая фигня не прокатит :)
В случае, если подобное захочешь делать с файлами - берёшь входной массив хэшей, сортируешь по возрастанию и делаешь поиск ( когда нашёл первый хэш, то второй 100% будет идти после него, соответственно `lef{i+1}> = mid{i}+1`
UPD: Интересно узнать, а конфиг СУБД был стандартный или ей разрешалось тоже забирать память из системы ?)
Поправьте, если ошибаюсь
Разве такая конструкция не подойдёт?
With tt as( delete from messages returning *) insert into mess_history select * from tt
PS пишу с телефона , возможны ошибки
Я тоже срезался на вопросе про нейросети
Вроде писал:
Нижеприведённые графики будут показывать время добавления ( в мс ) следующих 10.000 данных — по оси Y, кол-во добавленных данных — по оси X.
По Х — количество добавленных данных
По Y — время, за которое добавились последние 10.000 записей
Но в разных ситуациях может быть по разному.
К примеру, если вы будете передавать на сервер много 'мелких' данных — есть смысл использовать текстовой формат для того, чтобы снизить размер буфера ( меньше нагрузка на сеть)
Бинарный формат — он же более универсальный и самый точный ( например для double чисел)
Надеюсь, я достаточно развёрнуто дал ответ.
А по поводу графиков и скорости — думаю, это будет в районе +- 5-20% ( в отличии от COPY binary ). Опять же в зависимости от того, что передаём
Я подумаю над тем, чтобы добавить многопоточность. А потом можно будет и сравнить.
Спасибо
Когда я начинал учить SQL — мой 'учитель' сказал, чтобы я начинал с 'постика'. Вот так и прижилось название
Сорь, что не по теме