BG Development


  Reply to this topicStart new topicStart Poll

> Кой начин е по-ефективен
dvader
Публикувано на: 25-08-2021, 08:24
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 4943
Регистриран на: 12.07.05



Въпросът не е свързан с конкретна база, но сценарият е следния:
Има някакво поле в базата, което трябва (редовно) да се обновява.
Кое ще е по-добре:

1) На всяка стъпка DELETE/INSERT
2) На всяка стъпка INSERT OR REPLACE
3) На всяка стъпка INSERT, INSERT, INSERT после SELECT LAST.

Полето има значение на ON/OFF затова имам вариант 1) - ако записът съществува значи е ON, ако не, значи е OFF.
Всъщност на мен най-читав ми изглежда вариант 3) ама не знам до колко е бърз.


--------------------
I find your lack of faith disturbing
PM
Top
thrawn
Публикувано на: 25-08-2021, 17:30
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 3166
Регистриран на: 17.01.17



Ако ти трябват history данните ползваш само insert-и. Ако данните станат много можеш да ползваш партишъни (в зависимост от конкретната база данни). В противен случай insert or update (тука има проблем, трябва ти уникален ключ за да работи схемата а не винаги такъв има наличен от входящите данни). Освен това, при много данни може да се забави заради индексите (ако имаш индекс по полета което ще ъпдейтваш, в тоя случай триеш и добавяше на ново).
PMEmail Poster
Top
DarkOne
Публикувано на: 25-08-2021, 20:57
Quote Post


Group Icon
Име: Александър Петков
Група: Администратор
Ранг: Почетен член

Мнения: 3625
Регистриран на: 30.01.04



Ако имаш индекс по полето, SELECT на последния запис е много бърз, дори при милиони записи можеш да очакваш двуцифрен брой милисекунди. Но ако често променяш, бих заложил на INSERT OR REPLACE, така че да не се трупа излишна информация с времето. Там проблемите са по-скоро с конкуретния достъп, ако е възможно от две места едновременно да се прави заявка и има значение кой от двата записа ще остане последен.

Това мнение е било редактирано от DarkOne на 25-08-2021, 20:58


--------------------
The man who learns only what others know
is as ignorant as if he learns nothing.
The treasures of knowledge are the most rare,
and guarded most harshly.
-- Chronicle of the First Age
PMICQ
Top
Bender++
Публикувано на: 25-08-2021, 22:03
Quote Post



Име:
Група: Потребител
Ранг: Новопостъпил

Мнения: 38
Регистриран на: 18.04.21



Зависи от базата icon_smile.gif

PostgreSQL  ползва MVCC store, така че всеки UPDATE реално прави нов запис. Също е по-ефективно колоните, които често се променят да са в отделна таблица, защото всяко писане инвалидира visibility map-a на страницата, което силно преебва използването на индексите
PMEmail Poster
Top
wqw
Публикувано на: 12-09-2021, 16:11
Quote Post


Group Icon
Име: Владимир Висулчев
Група: VIP
Ранг: Почетен член

Мнения: 6273
Регистриран на: 10.06.04



QUOTE (Bender++ @ 25-08-2021, 22:03)
Зависи от базата icon_smile.gif

PostgreSQL  ползва MVCC store, така че всеки UPDATE реално прави нов запис. Също е по-ефективно колоните, които често се променят да са в отделна таблица, защото всяко писане инвалидира visibility map-a на страницата, което силно преебва използването на индексите

Кой би избрал подобен physical implementation за RDBMS ако при нормално ползване всичко се изпочупва и почва да работи субоптимално. Makes no sense.

Според мен Postgres си работи нормално при INSERT OR REPLACE

На sqlite съм забелязал че трябва да се внимава при таблица с колони (ID, Col1, Col2, Col3) като се прави REPLACE SET Col1 = 42 WHERE ID = 100 без да се указват Col2 и Col3 че дори записът да съществува набива default-и на Col2 и Col3 (примерно NULL) а не запазва старите стойности, но това може да не е релевантно за Postgres.

cheers,
</wqw>


--------------------
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 13-09-2021, 08:42
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 3166
Регистриран на: 17.01.17



Това за индексите е така. И аз съм го срещал на много места като препоръка - при големи индекси (респективно данни) е по-удачно да се изтрие и да се добави записът на ново отколкото да се редактира вече съществуващ такъв и да се ребилднат индексите след това.

А що се отнася до upsert-а в postgres, не затрива колоните които не се ъпдейтват. Ползвам го често за добавяне на данни с on conflict do update key = excluded.key returning id щото при on conflict do nothing returning id не връща нищо.
В mysql има същия "проблем", но там са го решили с last_insert_id(value) където value е стойността която ще получ за генериран ключ.
PMEmail Poster
Top
JanBirdX
Публикувано на: 13-09-2021, 14:53
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1757
Регистриран на: 21.02.05



Индексите сработват само при голяма уникалност. Едва ли индекса ще е по полето със стойност 1/0. Да отговорим може би трябва да знаем колко ще са записите(мин, макс) в таблицата, какви други полета, дали ще има конкурентни заявки и т.н.
PMEmail Poster
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2019 | BG Development | All Rights Reserved
RSS 2.0