Size: a a a

DBA - русскоговорящее сообщество

2021 January 20

ВТ

Владислав Тюпкин... in DBA - русскоговорящее сообщество
CREATE TABLE tasks(
id INTEGER PRIMARY KEY AUTOINCREMENT,
id_parent INTEGER DEFAULT -1,
num_sub INTEGER DEFAULT -1,
id_data INTEGER NOT NULL,
name_data TEXT NOT NULL,
src_path TEXT DEFAULT '',
dst_path TEXT DEFAULT '',
size INTEGER DEFAULT -1,
is_download INTEGER DEFAULT 1,
id_user INTEGER NOT NULL,
state INTEGER DEFAULT 1,
progress_mask BLOB DEFAULT NULL,
percent INTEGER DEFAULT 0,
eta INTEGER DEFAULT -1,
priority INTEGER DEFAULT 10,
size_complete INTEGER DEFAULT 0,

CONSTRAINT fk_users
FOREIGN KEY (id_user)
REFERENCES users(id_user)
ON DELETE CASCADE,

CONSTRAINT fk_state
FOREIGN KEY (state)
REFERENCES users(id_state)
ON DELETE CASCADE,

UNIQUE(id_data, name_data)
);
источник

IZ

Ilia Zviagin in DBA - русскоговорящее сообщество
Владислав Тюпкин
Да в целом простой триггер написал, но он не работает. Говорит, что отсутствует поле id_parent. Сразу скажу, что оно точно есть, да и все поля на месте) Методом комментирования пришел к тому, что проблема в этой части, но в чем, не могу понять, вроде же все нормально.

CREATE TRIGGER AFTER UPDATE ON tasks
WHEN(NEW.size_complete <> OLD.size_complete)
BEGIN

--some code

SELECT size_complete, size FROM tasks as ParentTask WHERE id = NEW.id_parent;

UPDATE tasks set percent = ParentTask.size_complete * 100 / ParentTask.size
WHERE id = NEW.id_parent;
END;
Странно...
источник

ВТ

Владислав Тюпкин... in DBA - русскоговорящее сообщество
Ilia Zviagin
Странно...
То есть со стороны синтаксиса здесь все правильно?
источник

АМ

Александр Макаров😎... in DBA - русскоговорящее сообщество
Serega Carbon
А всё-таки, как удалить большое количество связанных данных (Таблица Юзер и Посты, у юзера 100К постов например и юзер удаляет аккаунт) ? cascade delete - работает очень медленно да и обычный delete тоже по условию where быстро не отработает. Может кто чё может подсказать, как с этим быть. Спасибо (весь день гуглю и ломаю голову, ничего не могу придумать)
А зачем это удалять?
Если можно пометить на удаление...
А удалить при обслуживании БД, сборщиком мусора.
источник

SC

Serega Carbon in DBA - русскоговорящее сообщество
Александр Макаров😎
А зачем это удалять?
Если можно пометить на удаление...
А удалить при обслуживании БД, сборщиком мусора.
тоже хорошая мысль, спасибо.  А как в постгресе партицировать таблицу по булевому значению: в одну часть обычные юзеры, а в другую - помеченные на удаления?
источник

АМ

Александр Макаров😎... in DBA - русскоговорящее сообщество
Serega Carbon
тоже хорошая мысль, спасибо.  А как в постгресе партицировать таблицу по булевому значению: в одну часть обычные юзеры, а в другую - помеченные на удаления?
Есть ещё хорошая мысль...

Всё зависит от объёма... И как часто удаляются пользователи (со своими данными)

Возможно, имеет смысл иметь (возможно, это будет дешевле) 100 баз по 100гб (условно)
И при "обслуживании" - просто создавать 101 базу - и просто переливать в неё живой контент. А не удалять в старой.
Это решит проблему с фрагментацией и индексами и тд.
источник

SC

Serega Carbon in DBA - русскоговорящее сообщество
Александр Макаров😎
Есть ещё хорошая мысль...

Всё зависит от объёма... И как часто удаляются пользователи (со своими данными)

Возможно, имеет смысл иметь (возможно, это будет дешевле) 100 баз по 100гб (условно)
И при "обслуживании" - просто создавать 101 базу - и просто переливать в неё живой контент. А не удалять в старой.
Это решит проблему с фрагментацией и индексами и тд.
интересно; а шардинг не поможет в этом?
источник

SC

Serega Carbon in DBA - русскоговорящее сообщество
и ещё, есть ли возможность в постгресе навешивать индексы только на реплику для чтения, а другую (ие) оставить без них?
источник

АМ

Александр Макаров😎... in DBA - русскоговорящее сообщество
Serega Carbon
интересно; а шардинг не поможет в этом?
Не знаю.

Идея пришла, когда изучал файловую систему HDFS, для BigData. И Ceph.
источник

SC

Serega Carbon in DBA - русскоговорящее сообщество
Александр Макаров😎
Не знаю.

Идея пришла, когда изучал файловую систему HDFS, для BigData. И Ceph.
спасибо, пойду разбираться )
источник

I

ILYA in DBA - русскоговорящее сообщество
Александр Макаров😎
Есть ещё хорошая мысль...

Всё зависит от объёма... И как часто удаляются пользователи (со своими данными)

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

A

Alexander in DBA - русскоговорящее сообщество
Александр Макаров😎
Есть ещё хорошая мысль...

Всё зависит от объёма... И как часто удаляются пользователи (со своими данными)

Возможно, имеет смысл иметь (возможно, это будет дешевле) 100 баз по 100гб (условно)
И при "обслуживании" - просто создавать 101 базу - и просто переливать в неё живой контент. А не удалять в старой.
Это решит проблему с фрагментацией и индексами и тд.
У тебя тогда будет проблема с ключами шардирования. Проблема-то не в удалении, а в копировании кучи данных, которые должны уехать вместе с ключем.
И, если у тебя 100 баз, то, скорее всего, они у тебя и добавляются тоже часто, а значит и перешардировать тоже часто придётся.
Хотя, тут может быть относительно просто решение в виде мегабайт вместо шардирования по ключу.
источник

SC

Serega Carbon in DBA - русскоговорящее сообщество
Alexander
У тебя тогда будет проблема с ключами шардирования. Проблема-то не в удалении, а в копировании кучи данных, которые должны уехать вместе с ключем.
И, если у тебя 100 баз, то, скорее всего, они у тебя и добавляются тоже часто, а значит и перешардировать тоже часто придётся.
Хотя, тут может быть относительно просто решение в виде мегабайт вместо шардирования по ключу.
ну я так понял, пока объем не большой, беспокоиться сильно не надо? или всё же следует
источник

A

Alexander in DBA - русскоговорящее сообщество
Serega Carbon
ну я так понял, пока объем не большой, беспокоиться сильно не надо? или всё же следует
Если тебе редко нужно добавлять/удалять новые шарды и не лень переливать данные между ними, то не беспокоиться следует
источник

SC

Serega Carbon in DBA - русскоговорящее сообщество
Alexander
Если тебе редко нужно добавлять/удалять новые шарды и не лень переливать данные между ними, то не беспокоиться следует
я вообще этот проект для диплома пишу)) мне до шардов ещё как до луны) я просто так, интересуюсь, на будущее
источник

E

Ellina in DBA - русскоговорящее сообщество
Всем здравствуйте. А куда можно вакансию по теме разместить?
источник

IZ

Ilia Zviagin in DBA - русскоговорящее сообщество
Владислав Тюпкин
То есть со стороны синтаксиса здесь все правильно?
Синтаксис в разных СУБД разный, тебе надо самому смотреть по документации на конкретную СУБД
источник

IZ

Ilia Zviagin in DBA - русскоговорящее сообщество
Ellina
Всем здравствуйте. А куда можно вакансию по теме разместить?
Сюда, только надо оформить как следует.
Примеры оформления можешь найти в этом чате
источник

IZ

Ilia Zviagin in DBA - русскоговорящее сообщество
Александр Макаров😎
А зачем это удалять?
Если можно пометить на удаление...
А удалить при обслуживании БД, сборщиком мусора.
Что-то ты такое невразумительное сказал
источник

E

Ellina in DBA - русскоговорящее сообщество
Ilia Zviagin
Сюда, только надо оформить как следует.
Примеры оформления можешь найти в этом чате
Спасибо!
источник